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

[Ian Romanick]

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.

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.