Hi Rob, I've sent a patch that adds the CAP.
Marek On Mon, May 25, 2015 at 3:17 PM, Rob Clark <robdcl...@gmail.com> wrote: > Ignoring the compiler for a moment, I think this would probably break > my varying linking (where I match up VS out and FS in).. (and I > wouldn't be surprised if somewhere between tgsi_to_nir and my > compiler, it also caused breakage) > > Unless you have a setup where you can test/fix all the drivers, I > think a shader cap is needed > > BR, > -R > > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
