On Wed, Aug 24, 2016 at 3:44 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 24.08.2016 um 11:26 schrieb Marek Olšák: >> On Wed, Aug 24, 2016 at 2:10 AM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> Am 22.08.2016 um 23:13 schrieb Marek Olšák: >>>> On Mon, Aug 22, 2016 at 10:18 PM, Dave Airlie <airl...@gmail.com> wrote: >>>>> On 23 August 2016 at 06:14, Marek Olšák <mar...@gmail.com> wrote: >>>>>> On Mon, Aug 22, 2016 at 7:05 PM, Brian Paul <bri...@vmware.com> wrote: >>>>>>> On 08/22/2016 08:38 AM, Marek Olšák wrote: >>>>>>>> >>>>>>>> From: Marek Olšák <marek.ol...@amd.com> >>>>>>>> >>>>>>>> Sampler view declarations have return types, but that doesn't work with >>>>>>>> variable indexing (e.g. SAMP[-1+i]). >>>>>>>> >>>>>>>> Adding the return type to the instruction is simpler. >>>>>>>> >>>>>>>> All sampler view declaration flags might have to be removed since >>>>>>>> variable >>>>>>>> indexing makes them inaccessible. >>>>>>> >>>>>>> >>>>>>> Do you want to get rid of sampler view declarations entirely? >>>>>> >>>>>> No, they have their place and I think the sampler view declarations >>>>>> should stay, but the flags that are attached to them are basically >>>>>> inaccessible with variable indexing. Since I have no reason to add >>>>>> array support for sampler view declarations (unlike IN,OUT,TEMP, where >>>>>> we needed array support due to other reasons), I prefer moving the >>>>>> flags to instructions. >>>>> >>>>> It should be illegal in all APIs I thought to do mixed arrays. >>>>> >>>>> So if you have 1+x, then the bits on 1 should be the same as the >>>>> bits on all the other sampler views in the array (even though there is >>>>> no array). >>>>> >>>>> Is there a real world problem being solved? >>>> >>>> No, it's just for TGSI robustness (not to be confused with GL robustness). >>>> >>> >>> I guess I replied to the wrong thread... >>> >>> In any case, I'd much prefer array support for sampler view dcls >>> instead. Mixed arrays are illegal everywhere, and it's nice to see that >>> in the translated shaders. And, even if you might not care on your hw, >>> someone might benefit from separate arrays (I'm near certain a proper >>> llvmpipe implementation of variable indexing would). >> >> Array support is a lot more work than this. I already did that for IN >> and OUTs. I'm really not into it. I'm also not really into >> DX10-anything as that's a deprecated API in the industry at this point >> (if I ignore it's not even in Mesa). >> > > I't nost so much about dx10 really. There's a reason noone allows mixed > arrays. Using multiple arrays is a much more direct translation of glsl too. > I'm sorry if properly fixing it is more work than a hack, but from my > point of view interface cleanlyness wins by a long shot, so I'd still > say NAK.
OK. No problem (really). I'll just do virgl does and rely on glsl_to_tgsi behavior (which Dave wants to preserve anyway). Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
