Brian Paul <[email protected]> writes: > On 09/30/2014 03:38 PM, Rob Clark wrote: >> From: Rob Clark <[email protected]> >> >> 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 <[email protected]> > > 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? 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. > I think the big if/switch statements could be replaced by some kind of > table-driven system.
pgpHr_xZioEba.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
