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

[Roland Scheidegger]

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

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.

Roland