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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #27 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Iago Toral from comment #23)
> (In reply to Jason Ekstrand from comment #21)
> > (In reply to Iago Toral from comment #19)
> > > Jason, for conversions where we cannot use a fast path in the master
> > > converter (that is, where we need to unpack the src to rgba and then pack
> > > from rgba to dst) you differentiate between 3 paths: uint (integer), float
> > > (is_signed || bits > 8) and ubyte (otherwise).
> > > 
> > > While the last two paths seem to be always valid (I think we have pack and
> > > unpack functions for all relevant formats for these types), I am hitting an
> > > assertion in the first path because there are no uint unpack functions for
> > > some types. Indeed, _mesa_unpack_uint_rgba_row only supports unpacking from
> > > a limited set of uint formats. I am hitting this path in cases where dst is
> > > an integer type but src is not. The code will choose the integer even though
> > > the implementation requires that both src and dst are integer, since we need
> > > an uint unpack function for the src in this case.
> > > 
> > > A solution for this would be to forget about the uint path and always go
> > > with the float path or the ubyte path, but I imagine that the uint path has
> > > benefits when it can be used... I guess because we could avoid
> > > uint->{float,byte} transformations.
> > > 
> > > So, I think we have two options:
> > > 1) Auto-generate uint unpack/pack functions for all required mesa formats.
> > > 2) Only use the integer path if both src and dst are integer types.
> > > 
> > > I think 1) is only useful when src is not an integer type (so we would be
> > > doing a type conversion anyway), so maybe 2) is the most sensible approach
> > > in this case. What do you think?
> > 
> > 2 sounds like the better plan.  Can you give an example of when we are
> > hitting that assertion?  I thought the GL spec forbid you from doing
> > normalized -> integer conversions so I'm not seeing how this happens.
> 
> Sure, at least this conversion is hitting that:
> 
> src: MESA_FORMAT_B10G10R10A2_UNORM (GL_UNSIGNED_NORMALIZED)
> dst: MESA_FORMAT_R10G10B10A2_UINT (GL_UNSIGNED_INT)
> 
> This comes from this piglit test:
> bin/ext_texture_integer-texture_integer_glsl130
> 
> I think what is going on is that the src argument here is defined as
> GL_RGBA_INTEGER and GL_UNSIGNED_INT_10_10_10_2, which I map to
> MESA_FORMAT_A2B10G10R10_UNORM instead of MESA_FORMAT_A2B10G10R10_UINT (we
> don't have MESA_FORMAT_A2B10G10R10_UINT, so that's why). This works because
> they have the same pixel layout, so the conversion is the same, but then we
> hit this situation.
> 
> Should we add the mesa_formats for MESA_FORMAT_A2B10G10R10_UINT and
> MESA_FORMAT_A2R10G10B10_UINT too? (currently we only have
> MESA_FORMAT_B10G10R10A2_UINT and MESA_FORMAT_R10G10B10A2_UINT).

Yeah, I think adding UINT versions of those is reasonable.  That's bee
bothering me for a while.

-- 
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/20141016/5794cc7c/attachment.html>