[Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?

Axel Davy axel.davy at ens.fr
Tue Feb 9 20:49:05 UTC 2016


On 09/02/2016 20:30, Jose Fonseca wrote:
> On 09/02/16 19:17, Axel Davy wrote:
>> Hi,
>>
>> We'd need to do some formats conversion in gallium nine, and if possible
>> we would like to do them in-place.
>>
>> unpack_rgba_8unorm/pack_rgba_8unorm doesn't seem to explicitly allow
>> in-place conversion,
>> but the generated code seems to be fine with that.
>>
>> Can we rely on these functions to be safe for in-place conversion ?
>> Could we add that somewhere as requirement ?
>>
>> CC-ing vmware guys, as they probably know.
>>
>> Yours,
>>
>> Axel Davy
>
> It might work in practice now, but I don't think this is same it 
> should be dependent upon.
>
> Take BGRA <-> RGBA: currently we read the dword, swizzle, and write 
> dword back, but it's an implementation detail.  One could imagine at 
> some point the implementation be changed to read/write bytes at a 
> time, which would break if done in place.
>
>
> My recommendation is, if you want to do this things in place: malloc a 
> temp with the size of a row of pixels, convert into temp row then 
> memcpy into src.
>
> You can even add util_convert_format_inplace() helper if you want.
>
> And if there's any hot-path (e.g., BGRA<->RGBA) just add a special 
> code path to this new util_convert_format_inplace that avoids the temp 
> copy.
>
> Jose
>
Thanks for the answer !

I decided to use util_format_translate, which solves my problem (I had 
thought of
doing about the same thing by converting to argb8888, and then convert 
in place to the dst format - of course
restricting with 32 bits formats -).


More information about the mesa-dev mailing list