Testing is really easy. Just run all piglit variable-indexing tests. Also, drivers don't have to do anything for outputs yet, because those are always moved to temps by lower_output_reads.
Marek On Sun, May 24, 2015 at 6:22 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > Right, but you're changing what the driver receives, so we should make > sure they all handle it correctly. Or let the major driver authors > know what's going on so they can test it out and fix their driver > accordingly. Perhaps find a couple of piglit tests that exercise the > functionality. On that note, I should probably check what nouveau > does, esp on nv30... > > On Sun, May 24, 2015 at 12:15 PM, Marek Olšák <mar...@gmail.com> wrote: >> 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
