On 09/30/2014 04:31 PM, Eric Anholt wrote:
Brian Paul <bri...@vmware.com> writes:
On 09/30/2014 03:38 PM, Rob Clark wrote:
From: Rob Clark <robcl...@freedesktop.org>
TGSI->TGSI pass, extracted from freedreno. Currently provides the
following lower support, to help drivers emulate unsupported opcodes
or features:
Individual opcodes:
DST, XPD, SCS, LRP, FRC, POW, LIT, EXP, LOG, DP4, DP3, DPH,
DP2, DP2A
Also supported, although it is up to the driver to manage it's own
shader variants:
+ two-sided-color
+ texture coord saturate (ie. to emulate GL_CLAMP)
All of the lowering operations are opt-in so a driver can pick and
choose what it wants.
Signed-off-by: Rob Clark <robcl...@freedesktop.org>
Hi Rob, a few thoughts:
How about moving this into the src/gallium/auxiliary/tgsi/ directory
since this is a very TGSI-specific thing?
I happened to be writing a series in parallel with Rob to do the same
thing, and I chose tgsi/. I've rebased my changes on his freedreno fix,
and I'm going to send them out in this thread now. I don't really care
which location wins, having good history is all I care about (Also,
reviewing his changes, I found style improvements that I propagated to
mine. So duplicated work ended up having some value).
I think some of my recent changes to the tgsi_transform code would be
helpful, like emit_epilog/prolog() and the various
tgsi_transform_opX_inst() helpers.
There's a lot of tricky code trying to determine the exact size of the
new shader token buffer. Why not just use a 2x buffer and then realloc
to the exact size at the end?
2x isn't nearly the lowest growth factor, right? How massively
overallocated do you go?
2x was just a random shot in the dark.
All this calculation of array sizes up front is pretty awful, though --
it seems like token buffers ought to be just growing as you append
tokens. But I guess that would be a change to do to tgsi_transform in
general.
That would be the best solution. I'd do it, but I don't think I'll have
time right away.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
