[Mesa-dev] rgtc signed format and u_format: some open questions

[Jose Fonseca]

If we implement, we should follow the normal conversion rules.

Imagine that user is doing a screen aligned textured quad blit from a snorm texture to a bgra_unorm8 rendertarget. And imagine inside llvmpipe/softpipe we detect blits and optimize this case by calling util_format_translate. It's far fetched, but it should still work as expected.

There may be other more useful examples, or actual use cases. Point being that (un)pack_rgba_8unorm  that it should do what's specified, not what looks better.

It's perfectly fine if (un)pack_rgba_8unorm is not optimized -- one could just call internally rgtc's (un)pack_float_8norm if that helps.

Thinking more about this, I agree it makes sense to make (un)pack_rgba_8unorm optional for formats that don't fit in there, and always use the (un)pack_rgba_float in those cases. It will be a bit of work to change the places that expect (un)pack_rgba_8unorm to be always there, but it will save code in the long term.

Jose

________________________________________
From: Brian Paul [brianp at vmware.com]
Sent: Thursday, March 03, 2011 23:58
To: Dave Airlie
Cc: Jose Fonseca; mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] rgtc signed format and u_format: some open questions

On 03/03/2011 02:40 PM, Dave Airlie wrote:
> On Fri, Mar 4, 2011 at 8:17 AM, Jose Fonseca<jfonseca at vmware.com>  wrote:
>> About a), one day we should have this in a library shared by mesa/gallium, but until then anywhere is fine by me.
>>
>> About b) please provide unorm8 support for all formats. It's useful for debugging/displaying, e.g., writing to BMP files, or visualizing on a window. There is already a helper function called util_format_fits_rgba8unorm (or something like that) to determine whether a format can be faithfully represented in unorm8 or not.
>>
>
> I don't understand how it can be useful though, if I have an image
> internally represented at -128..127, and I dump it as unorm 0.255 it
> is going to actually me less useful I would guess as I'd try and
> interpret it. Though I've no idea what negative color looks like, the
> hooks are pretty easy to add in, but I'd like to add something to warn
> if they ever get used.

You could either clamp the signed values to [0,127] or bias them by
128 I guess.  It's not a huge deal.

-Brian