While I'm all for doing this, won't this break every driver if it no longer has all the decl's? It'll take special logic to convert
DECL IN[0..5], GENERIC[0] into DECL IN[0], GENERIC[0] DECL IN[1], GENERIC[1] etc Perhaps this should be guarded by a cap? Or an audit of all drivers should be done? On Sun, May 24, 2015 at 7:19 AM, Marek Olšák <mar...@gmail.com> wrote: > Hi, > > The reason I add this is that TGSI doesn't allow indirect indexing of inputs > and outputs. Consider this: > > MOV OUT[ADDR[0]-1000], IMM[0] > > There is no way to know where the output array starts here. It could be for > example OUT[6]=GENERIC4 or anything else. The problem is some outputs are > physically stored in a different memory domain than others. Per-patch > (tessellation) outputs are one such example. Does the MOV instruction write a > per-vertex or per-patch output? There is no way to know. > > The problem can be avoided by using carefully-generated unoptimized TGSI > where the relative index is the same as the base of the array, which is > OUT[6] here: > > UADD TEMP[0].x, TEMP[0].x, -1006 > UARL ADDR[0], TEMP[0].x > MOV OUT[ADDR[0]+6], IMM[0] > > This hack helps for this case, but the drivers which do move outputs to temps > are still unable to allocate registers efficiently, because there is no way > to know the actual array size. > > This patch series adds proper TGSI support for IN/OUT arrays. It works in the > same way as temp arrays and it's a requirement for tessellation. > > Please review. > > Marek > _______________________________________________ > 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
