[Mesa-dev] [PATCH] gallium: add st_api feature mask to prevent advertising MS visuals

[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
ReadPixels).
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[5];
>    uint8_t stencil_bits_array[5];
>    uint8_t msaa_samples_array[5];
> 
> 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.

> -Brian