On Sat, Mar 19, 2016 at 5:09 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Mar 19, 2016 at 12:02 PM, Bas Nieuwenhuizen > <b...@basnieuwenhuizen.nl> wrote: >> 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]. > > OK. I still think it's crazy, but it is what it is :)
It's called EQAA (similar to CSAA). The hardware can do 16 unique depth samples, but only 8 unique color samples can be stored. Other than that, the rasterization hw supports 16x MSAA fully. > >> >> 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. > > Actually my earlier criticism about it only doing POT levels is a bit > off -- after reading some more of the code, I just think that the > settings to drivers were off - it should have been (1 << 8) | (1 << > 4), etc. This works up to 32x MSAA, which is not supported by anyone > (for real, although NVIDIA blob drivers do fake it). R300 can do 6x MSAA, but granted it won't support this extension. > > I do still prefer to avoid having separate places where this info is > encoded... so I maintain my vote for using PIPE_FORMAT_NONE in > is_format_supported. Same here. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
