[Mesa-dev] [PATCH] st/mesa: try the app's texture format first before using the internal format.

[Brian Paul]

2011/6/17 Stéphane Marchesin <stephane.marchesin at gmail.com>:
> 2011/6/17 Brian Paul <brianp at vmware.com>:
>> On 06/17/2011 12:34 PM, Stéphane Marchesin wrote:
>>>
>>> If we can find it, that means we don't need to do texture format
>>> conversion
>>> and therefore we get fast texture uploads for natively supported formats.
>>> ---
>>>  src/mesa/state_tracker/st_format.c |   25 +++++++++++++++++--------
>>>  1 files changed, 17 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_format.c
>>> b/src/mesa/state_tracker/st_format.c
>>> index 3583571..e39d835 100644
>>> --- a/src/mesa/state_tracker/st_format.c
>>> +++ b/src/mesa/state_tracker/st_format.c
>>> @@ -615,16 +615,16 @@ static struct format_mapping format_map[] = {
>>>        { PIPE_FORMAT_B10G10R10A2_UNORM, DEFAULT_RGBA_FORMATS }
>>>     },
>>>     {
>>> -      { 4, GL_RGBA, GL_RGBA8, 0 },
>>> -      { DEFAULT_RGBA_FORMATS, 0 }
>>> -   },
>>> -   {
>>>        { GL_BGRA, 0 },
>>>        { PIPE_FORMAT_B8G8R8A8_UNORM, DEFAULT_RGBA_FORMATS }
>>>     },
>>>     {
>>> +      { 4, GL_RGBA, GL_RGBA8, 0 },
>>> +      { PIPE_FORMAT_R8G8B8A8_UNORM, DEFAULT_RGBA_FORMATS }
>>> +   },
>>> +   {
>>>        { 3, GL_RGB, GL_RGB8, 0 },
>>> -      { DEFAULT_RGB_FORMATS, 0 }
>>> +      { PIPE_FORMAT_R8G8B8X8_UNORM, DEFAULT_RGB_FORMATS }
>>>     },
>>
>> We should just add PIPE_FORMAT_R8G8B8A8_UNORM to DEFAULT_RGBA_FORMATS.
>>
>
> Well, if we do that, we have RGBA8 taking precedence in the BGRA case
> also, which now makes BGRA transfers slow because there is format
> conversion going on...
> I guess what I want is the following: implement RGBA8 and BGRA8 in the
> driver, and when apps request a texture we try to use a format that
> require no conversion.

Right.  IIRC, a number of the legacy DRI drivers have code that looks
at the user's glTexImage format and type and try to choose a hardware
format to avoid swizzling, etc (when there's a choice in hw formats).
We've never had that in the gallium state tracker.  Looks like
st_choose_format() needs to be a bit smarter.  Off-hand, I guess we
could have another table that exactly maps particular
format/type/internalFormat combinations to PIPE_FORMATs.  Or maybe
just some hard-wired code for the common cases.  More below...


>> I don't think this is right.  The internalFormat is more important the
>> format parameter.
>>
>> Suppose the user called glTexImage(internalFormat=GL_RGBA32F_ARB,
>> format=GL_RGBA, type=GL_FLOAT).  We can't choose the hw format based on
>> format=GL_RGBA since we won't get the float format the user wants.
>>
>
> Hmm you're right. So the reason is that I implemented native RGBA
> support in i915g (it currently only has BGRA), but it doesn't get used
> because BGRA gets used instead in all cases. I guess right now I'd
> like to see the BGRA driver format used when the user gives us
> RGBA/BGRA and the RGBA format used when the user gives us RGBA/RGBA
> (that would avoid conversion in both cases). Should I just add a
> heuristic for that or do we want to be more generic? Can you think of
> other cases we want to handle? I just want to avoid the conversion
> overhead for those basic formats.

Take a look at the legacy DRI drivers.  I think radeon_texture.c has
code that examines format/type/internalFormat to choose the hw format.
 Maybe you can re-use that or make something nicer that does the same
thing.

-Brian