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.
> There's no mesa format that matches PIPE_FORMAT_R8G8B8X8_UNORM at this time.
>
>
>> {
>> { GL_RGB12, GL_RGB16, GL_RGBA12, GL_RGBA16, 0 },
>> @@ -1108,7 +1108,7 @@ static struct format_mapping format_map[] = {
>> * Return first supported format from the given list.
>> */
>> static enum pipe_format
>> -find_supported_format(struct pipe_screen *screen,
>> +find_supported_format(struct pipe_screen *screen,
>> const enum pipe_format formats[],
>> enum pipe_texture_target target,
>> unsigned sample_count,
>> @@ -1210,14 +1210,23 @@ st_ChooseTextureFormat_renderable(struct
>> gl_context *ctx, GLint internalFormat,
>> if (_mesa_is_depth_format(internalFormat) ||
>> _mesa_is_depth_or_stencil_format(internalFormat))
>> bindings |= PIPE_BIND_DEPTH_STENCIL;
>> - else
>> + else
>> bindings |= PIPE_BIND_RENDER_TARGET;
>> }
>
> I'll take care of the trailing whitespace in a separate commit.
>
>
>> - pFormat = st_choose_format(screen, internalFormat,
>> + /* First try a format which matches the format provided by the app
>> + * This heuristic avoids potentially costly texture format conversions
>> + * and gets us much faster texture transfers. */
>> + pFormat = st_choose_format(screen, format,
>> PIPE_TEXTURE_2D, 0, bindings);
>>
>> if (pFormat == PIPE_FORMAT_NONE) {
>> + /* Now try the internal format */
>> + pFormat = st_choose_format(screen, internalFormat,
>> + PIPE_TEXTURE_2D, 0, bindings);
>> + }
>> +
>> + if (pFormat == PIPE_FORMAT_NONE) {
>> /* try choosing format again, this time without render target
>> bindings */
>> pFormat = st_choose_format(screen, internalFormat,
>> PIPE_TEXTURE_2D, 0,
>> PIPE_BIND_SAMPLER_VIEW);
>
> 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.
Stéphane
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
