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

[Brian Paul]

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?


>> 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.

-Brian