2011/6/17 Stéphane Marchesin <stephane.marche...@gmail.com>:
> 2011/6/17 Brian Paul <bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
