[Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?
Ian Romanick
idr at freedesktop.org
Tue Feb 9 19:48:33 UTC 2016
On 02/09/2016 11:30 AM, 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.
The other option is to make this explicit and add a unit test to enforce
the behavior.
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list