Drivers that only use tgsi_shader_info won't break. Drivers that process tgsi_full_declaration manually and interpret Range.First .. Range.Last correctly won't break either.
A driver can only break if it doesn't handle Range.Last correctly. If that's the case, the driver should be fixed, because this is a basic TGSI feature that has always been there. Marek On Sun, May 24, 2015 at 5:45 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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
