thanks
On Mon, May 25, 2015 at 5:38 PM, Marek Olšák <[email protected]> wrote: > Hi Rob, > > I've sent a patch that adds the CAP. > > Marek > > On Mon, May 25, 2015 at 3:17 PM, Rob Clark <[email protected]> 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 <[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
