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

[Jerome Glisse]

On Wed, Dec 15, 2010 at 2:42 PM, Christoph Bumiller
<e0425955 at student.tuwien.ac.at> wrote:
> 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).

Question is should it trigger GL error ?

Cheers,
Jerome

> 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.
>