[Mesa-dev] [RFC PATCH 0/26] Implement ARB_texture_multisample

[Marek Olšák]

On Tue, Jan 15, 2013 at 9:30 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 01/14/2013 04:59 PM, Marek Olšák wrote:
>>
>> On Mon, Jan 14, 2013 at 11:35 PM, Ian Romanick <idr at freedesktop.org>
>> wrote:
>>>
>>> On 01/13/2013 06:20 AM, Marek Olšák wrote:
>>>>
>>>>
>>>> Hi Dave, here's a preliminary review.
>>>>
>>>> 1) The depth and integer texture sample limits should be set according
>>>> to driver support, we probably don't have good queries for that.
>>>>
>>>> - R6xx cannot do depth MSAA textures.
>>>> - R6xx and R7xx cannot do integer MSAA textures.
>>>> - Color resolve with R11G11B10_FLOAT is buggy on R6xx, so we don't
>>>> support the format with a sample count > 1. This limitation might be
>>>> tricky to report with ARB_texture_multisample.
>>>
>>>
>>> GL_ARB_internalformat_query2 allows queries of all these sorts of things.
>>> Mesa doesn't support it yet, but we could probably use some internal
>>> infrastructure in this area first.
>>
>>
>> We do have some internal infrastructure in Mesa, well Gallium
>> actually, but it's pretty much Mesa for some of us:
>> pipe_screen::is_format_supported is very flexible and r600g does
>
>
> I had forgotten about that.  That should handle all the limitations Dave
> mentioned.
>
>
>> expose all its limits through that function already. I saw your
>> ARB_internalformat_query series and I wondered why you had added a
>
>
> I did look at that interface, but I didn't think it was a good fit for a
> couple reasons.  To use that interface to implement the GL_SAMPLES query, I
> would have to:
>
>     for (i = some arbitrary maximum; i > 0; i--) {
>         if (ctx->is_format_supported(..., i))
>             counts[idx++] = i;
>     }
>
> I would also have to do the same thing for GL_NUM_SAMPLE_COUNTS.  That
> seemed like a pretty awful way to implement these queries.  Presumably the
> driver knows what it can do, so having to ask "mother may I" for every
> possible value is just silly.

Alright, the GL_NUM_SAMPLE_COUNTS query isn't very nice with gallium,
but the looping is not a big deal, these queries won't be used very
often anyway.

I guess the best way to represent the list of sample counts is through
a bit mask. If the bit i is set, then (i+1) samples are supported.
GL_NUM_SAMPLE_COUNTS would the count of 1s, looping can be done with
ffs, etc.

>
> It's worth pointing out that applications could do the same thing without
> the GL_ARB_internalformat_query extension.  Application developers thought
> that interface was so horrible, they asked us to invent a new one. :)
>
> The other reason was a misunderstanding I had about how the samples
> parameter was treated.  After looking at the r600 code, I've managed to
> clear that up.  The documentation in p_screen.h could be better.
>
>
>> pretty limited query for the sample count to dd_function_table -
>> QuerySamplesForFormat. It was obvious that it would have to go away
>> and be replaced by something more useful for
>> ARB_internalformat_query2. If you copied is_format_supported from
>> gallium, you'd be internally almost done with
>> ARB_internalformat_query2. I don't think we need greater flexibility
>> than that, well maybe for pre-r600 we do.
>
>
> There are a lot of aspects of ARB_internalformat_query2 that I don't see
> mapping to is_format_supported or any other existing internal interface that
> I'm aware of.  Excluding GL_INTERNALFORMAT_SUPPORTED, I don't see how any of
> the GL_INTERNALFORMAT_* queries would be implemented.  I don't see how any
> of the GL_MAX_* queries would be implemented.  I don't see how any of the
> GL_{VERTEX,GEOMETRY, etc.}_TEXTURE queries would be implemented.  etc.
>
> It seemed pretty clear that the existing Gallium interface couldn't do
> everything, and it wasn't a good fit for the specific thing I was trying to
> do.  Given that, it didn't make very much sense for me to use it.  I don't
> know what the "ultimate" interface will look like (or even need to do,
> really), so it didn't make sense for me to try to invent that either.

ARB_internalformat_query2 has a lot of queries which don't seem to be
very useful or would return the same values as the old glGet queries
(e.g. GL_TEXTURE_WIDTH). Maybe we don't need as many queries in the
internal interfaces.

In any case, we'll probably have to make some changes to the gallium
interface if we want the queries to be accurate.

Marek