On Sat, Mar 19, 2016 at 4:25 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Mar 19, 2016 at 11:14 AM, Bas Nieuwenhuizen > <b...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
