<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><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#c21">Comment # 21</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 <span class="vcard"><a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> <span class="fn">Jason Ekstrand</span></a>
</span></b>
<pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=84566#c19">comment #19</a>)
<span class="quote">> 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?</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>