[Mesa-dev] [PATCH] gallium: add st_api feature mask to prevent advertising MS visuals
sroland at vmware.com
Tue May 22 14:04:09 PDT 2012
Am 22.05.2012 18:12, schrieb Christoph Bumiller:
> On 05/22/2012 05:58 PM, Brian Paul wrote:
>> On 05/22/2012 08:37 AM, Christoph Bumiller wrote:
>>> On 05/22/2012 04:23 PM, Brian Paul wrote:
>>>> On 05/21/2012 03:46 PM, Christoph Bumiller wrote:
>>>>> src/gallium/include/state_tracker/st_api.h | 16
>>>>> src/gallium/state_trackers/dri/common/dri_screen.c | 23
>>>>> src/gallium/state_trackers/vega/vg_manager.c | 1 +
>>>>> src/mesa/state_tracker/st_manager.c | 1 +
>>>>> 4 files changed, 31 insertions(+), 10 deletions(-)
>>>> Hi Christopher, could you give a bit more background on this? I'm not
>>>> sure I understand the problem you're trying to solve here.
>>> If gallium drivers advertise support for multisampled surfaces via
>>> is_format_supported (so EXT_framebuffer_multisample works properly), the
>>> dri state tracker sees that and advertises multisample visuals. But
>>> since they aren't actually implemented, applications that try to use
>>> them will crash or worse.
>> So the driver supports MS user FBOs/Renderbuffer but not MS
>> windows/pbuffers? What would it take to fully support MS visuals? Is
>> it just a driver issue or is there some DRI/infrastructure that's missing?
> The driver being st/mesa, gallium drivers don't care about any of that.
> Core mesa and st/mesa apparently do not support MS visuals.
> I'm not sure how much effort it will be to implement them, it involves
> implicitly resolving (parts of) the MS buffer at various points (like
> I don't really care much about supporting visuals though, they seem like
> an ugly hack to me.
>>>> Where does 8 come from? The old value, below, was 4. I don't know
>>>>> where that came from either.
>>> The old value was 8 as well (i * 2 -> i), it's the maximum number of
>>> samples any current hardware supports.
>> There should be a comment for that then. And, we should probably use a
>> #define MAX_SAMPLES instead of '8'. There's also a few arrays in that
>> function which should be fixed:
>> uint8_t depth_bits_array;
>> uint8_t stencil_bits_array;
>> uint8_t msaa_samples_array;
>> to be:
>> uint8_t depth_bits_array[MAX_SAMPLES];
>> uint8_t stencil_bits_array[MAX_SAMPLES];
>> uint8_t msaa_samples_array[MAX_SAMPLES];
>> BTW, doesn't NVIDIA have a 5-sample MS mode? Maybe the loop should also
>> just try odd numbers of samples.
> No, but I think r300 supports 3. Just testing all odd values as well
> would be fine with me.
r300 (unlike newer hw) supported 6 but afaik not 3. I don't know of any
hw supporting odd number of samples (nvidia quincunx was also 2
subsamples per pixel just the resolve step was using samples from
neighboring pixels). I guess though technically it should be possible.
More information about the mesa-dev