[Mesa-dev] [PATCH 01/17] gallium: Add PIPE_CAP_MSAA_MODES

[Bas Nieuwenhuizen]

On Sat, Mar 19, 2016 at 4:25 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Sat, Mar 19, 2016 at 11:14 AM, Bas Nieuwenhuizen
> <bas at basnieuwenhuizen.nl> wrote:
>> That would limit us to supporting sample counts for which we have
>> texture formats.
>>
>> As far as I understand with radeonsi we can support 16 samples without
>> any attachments, but all formats are limited to <= 8 samples.
>
> So you're going to end up with a situation where GL_MAX_SAMPLES is
> less than GL_MAX_FRAMEBUFFER_SAMPLES? I don't know that that's a
> useful thing to have. This implementation still has the problem of
> only supporting POT MSAA levels (although tbh I'm not 100% sure
> there's hw out there that supports NPOT MSAA levels). If people really
> want this, I think the way to go would be to make
> is_format_supported() work with PIPE_FORMAT_NONE and do it that way.
>
> Also, are you *sure* that's the case on radeonsi? I find it very odd
> that the rasterizer would support a higher MSAA level than the highest
> attachment would...

I am pretty confident that this is the case. I just tested 16 samples
(although this series seems to miss changing MaxFramebufferSamples),
and the driver disallows any texture format with > 8 samples [1].
Furthermore the proprietary driver on Windows seems to have
GL_MAX_SAMPLES=8 and GL_MAX_FRAMEBUFFER_SAMPLES=16 [2].

Using PIPE_FORMAT_NONE to query the driver would probably be a bit
less error prone than the current code that sets the masks, so that
would be fine with me.

- Bas

[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_state.c#n2003
[2] http://opengl.gpuinfo.org/gl_generatereport.php?reportID=1240