[Mesa-dev] [Bug 84566] Unify the format conversion code

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Oct 24 10:17:04 PDT 2014


--- Comment #42 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Iago Toral from comment #40)
> Jason, I think we may want to be a bit more conservative with the
> pack/unpack fast paths when we consider the internal base format.
> Right now, if the src or dst formats are RGBA we will try the pack/unpack
> fast paths. However, these paths do not consider the internal base format
> and we can run into cases where simply packing or unpacking is not enough.
> Consider this example: the client executes a texture upload of RGBA data and
> selects a Luminance format for the texture. The driver does not support the
> luminance format, so decides to use BGRA instead. Since the source format is
> RGBA, we will directly pack to BGRA, but since the internal base format is
> luminance, that won't match the semantics we expect (luminance requires to
> copy R on all components).
> I could try to add conditions to protect these paths in situations like
> this. For example, in this particular case, I could check if the base format
> of the destination matches the base internal format provided by the client,
> and if they don't and the internal base format is luminance or intensity,
> then avoid the fast path. However, I think this might hit other formats too,
> since the problem, in general, is that pack/unpack fast paths do not
> consider that the dst format and the dst base internal format might be
> different and that might involve more than a simples pack or unpack to dst,
> so I am thinking that maybe we want to simply avoid the pack/unpack paths
> completely when the dst format is not the same as the dst base internal
> format.
> What do you think?

That seems reasonable.  We can add code to enable the fast path in the special
cases where it makes sense later.  Just disabling it unless we're sure it works
seems like the right thing to do.

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141024/ce92189e/attachment.html>

More information about the mesa-dev mailing list