Overall, this looks like a good idea to me. Probably needs some changes in our internal code but the idea is quite sane.
Roland Am 24.05.2015 um 13:19 schrieb Marek Olšák: > 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 > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=dS0ucK9FuuSdcbnt4s0qhRBgFja_cLvjtixh9CaYjPc&s=ta_2hl9KvbY_ta-8iuUigKSHVWY1HsYcyPczQmh_c8s&e= > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
