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

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84566

--- Comment #38 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Samuel Iglesias from comment #36)
> (In reply to Jason Ekstrand from comment #32)
> > (In reply to Iago Toral from comment #31)
> > > Jason, there is an had-hoc path to deal with MESA_FORMAT_YCBCR* in
> > > texstore.c. Seems that this path only allows conversion between these
> > > formats, which is mostly a memcpy with some byte swapping when necessary.
> > > Should we also keep this one as a special case to be handled outside the
> > > master function?
> > 
> > Yes, there's code for that in texstore.c and in format_unpack.c.  We should
> > make that consisten either by movint the code from texstore.c to
> > format_pack.c or move it from format_unpack.c to readpixels.  I'm ok with
> > moving everything into the packing/unpacking functions and letting the
> > conversion function handle it.  It is a MESA_FORMAT after all.
> 
> Looking at _mesa_texstore_ycbcr() inside texstore.c, it is just a memcpy
> without any RGB to YCBCR conversion.
> 
> Do we need to implement RGB to YCBCR conversion in format_pack? Or we just
> need to use a special case for that format in _mesa_format_convert (so that
> it uses the function that memcopies instead of pack/unpack)? The second
> option would be more efficient.

Right... I incorrectly remembered that function doing more than it does.  In
that case, let's go ahead and leave it more-or-less as is.  Keep handling it in
texstore.  If we leave the unpacking function in there, then GetTexImage and
swrast sampling will work, and that should be all we need.

-- 
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/1898b7c9/attachment.html>