<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Unify the format conversion code" href="https://bugs.freedesktop.org/show_bug.cgi?id=84566#c27">Comment # 27</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Unify the format conversion code" href="https://bugs.freedesktop.org/show_bug.cgi?id=84566">bug 84566</a> from <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=84566#c23">comment #23</a>) > (In reply to Jason Ekstrand from <a href="show_bug.cgi?id=84566#c21">comment #21</a>) > > (In reply to Iago Toral from <a href="show_bug.cgi?id=84566#c19">comment #19</a>) > > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>