If we have a reliable ARB shader to glsl ir coverter, we could just eliminate mesa ir from this chain.
So we should get either glsl->tgsi or arb->glsl->tgsi. -- Lucas Am Donnerstag, den 13.01.2011, 17:40 +0100 schrieb Roland Scheidegger: > Am 12.01.2011 23:04, schrieb Eric Anholt: > > This is a work-in-progress patch series to switch texenvprogram.c from > > generating ARB_fp style Mesa IR to generating GLSL IR as its product. > > For drivers without native GLSL codegen, that is then turned into the > > Mesa IR that can be consumed. However, for 965 we don't use the Mesa > > IR product and just use the GLSL output, producing much better code > > thanks to the new backend. This is part of a long term goal to get > > Mesa drivers off of Mesa IR and producing their instruction stream > > directly from the GLSL IR. > > > > I'm not planning on committing this series immediately, as I've still > > got a regression in the 965 driver with texrect-many on the last > > commit. > > > > As a comparison, here's one of the shaders from openarena before: > > So what's the code looking like after conversion to mesa IR? As long as > it's not worse than the original I guess this should be ok, though for > those drivers consuming mesa IR I guess it's just more cpu time without > any real benefit? For gallium we should probably address this some way > or another, it seems quite backward to do ff->glsl->mesa ir->tgsi. > > Roland > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
