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

[eocallaghan at alterapraxis.com]

On 2016-03-21 21:06, Marek Olšák wrote:
> On Sat, Mar 19, 2016 at 5:09 PM, Ilia Mirkin <imirkin at alum.mit.edu> 
> wrote:
>> On Sat, Mar 19, 2016 at 12:02 PM, Bas Nieuwenhuizen
>> <bas at basnieuwenhuizen.nl> wrote:
>>> 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].
>> 
>> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev