[Mesa-dev] Uploading PIPE_FORMAT_B8G8R8A8_UNORM to pixmap texture in PIPE_FORMAT_B8G8R8X8_UNORM

[Christoph Bumiller]

On 12/15/2010 08:25 PM, Jerome Glisse wrote:
> On Wed, Dec 15, 2010 at 2:20 PM, Christoph Bumiller
> <e0425955 at student.tuwien.ac.at> wrote:
>> On 12/15/2010 07:55 PM, Jerome Glisse wrote:
>>> Hi,
>>>
>>> I am facing an issue which i am not sure what is the proper things to
>>> do about. piglit tfp test try to upload PIPE_FORMAT_B8G8R8A8_UNORM to
>>> texture pixmap which is  PIPE_FORMAT_B8G8R8X8_UNORM r600g assert in
>>> blitter util because format are not compatible. Should all pixmap
>>> texture considered with A8 ? Should i just disable the assert in case
>>> of A->X convertion ? Other answer ?
>>>
>>
>> 1. The assertion is in the wrong place, since util_blitter_copy_region's
>> description reads:
>> "You can copy from any color format to any other color format provided
>> the former can be sampled and the latter can be rendered to. Otherwise,
>> a software fallback path is taken and both surfaces must be of the same
>> format."
>>
>> 2. The arguments to util_is_format_compatible in the assertion are
>> reversed:
>> "Whether the src format can be blitted to destation format with a simple
>> memcpy." - this is true for A8 -> X8, only X8 -> A8 cannot be done with
>> memcpy.
>>
>> assert(util_is_format_compatible(util_format_description(dst->format),
>> util_format_description(src->format)));
>>
>> boolean util_is_format_compatible(const struct util_format_description
>> *src_desc, const struct util_format_description *dst_desc);
>>
>> Christoph
>>
> 
> I agree with that but the root issue remain, what is the expected
> result of X8 pixmap when uploading A8 channel.
> 
It is irrelevant/unspecified because the X8 byte will (should) never be
interpreted (if there is no way around doing that, thank your hw designer).

The inverse operation (copying from X8 to A8) however is specified to
set A8 to 1 (0xff), see the bottom of tgsi.rst - if you can't swizzle
the X8 to 1 on/after texturing, you might want to employ the workaround
of setting the X8 byte to 0xff.

> Cheers,
> Jerome