From: Roland Scheidegger srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify
Roland,
I just sent the exact same patch.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Wed, Aug 13, 2014 at 10:33 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still
Ha one minute faster :-).
FWIW interestingly this one also fixes the other conform failures I was
seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
texstore_swizzle so I guess the results of the swizzle path aren't quite
identical to the fallback one, which is a bit worrying.
Oh and forgot to mention, on a quick looked it seemed to me like the
texstore_swizzle path could potentially forget about transfer ops, or
can't this happen? Of course at least the state tracker would not be
affected by this (as it implements the transfer ops on its own).
Roland
Am 13.08.2014
Yeah, I think you're right about that. I'll send out a quick fix-up
patch. I guess we don't have piglit tests for that either.
--Jason
On Wed, Aug 13, 2014 at 10:56 AM, Roland Scheidegger srol...@vmware.com
wrote:
Oh and forgot to mention, on a quick looked it seemed to me like the
