On 2016-03-21 21:06, Marek Olšák wrote:
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.
Same. I fixed this in the up-coming series.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
