Re: [Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?
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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?
Hi again, Actually, "util_format_translate" seems to fit our needs. It could probably be optimised better (8unorm fitting format->ARGB could avoid using tmp buffer for example), but that should be ok for our needs. Yours, Axel Davy On 09/02/2016 20: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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?
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 argb, and then convert in place to the dst format - of course restricting with 32 bits formats -). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?
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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
