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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
