Wait a moment, how did it fail with si_shader_io_get_unique_index? The function shouldn't be called for ES with the viewport index, because ES can't pass the output to GS. If it was called, ignoring the viewport index in si_llvm_emit_es_epilogue should fix it.
Marek On Thu, Jun 25, 2015 at 10:29 PM, Marek Olšák <mar...@gmail.com> wrote: > In that case, feel free to push. > > Reviewed-by: Marek Olšák <marek.ol...@amd.com> > > Marek > > On Thu, Jun 25, 2015 at 10:25 PM, Dave Airlie <airl...@gmail.com> wrote: >> On 26 June 2015 at 00:26, Marek Olšák <mar...@gmail.com> wrote: >>> Hi Dave, >>> >>> The change in si_shader_io_get_unique_index can be dropped. The >>> function is only used for shaders before GS. >>> >> Ok okay I was hitting the assert in there for the layer/viewport index cases, >> but if the patch you pushed to master helps I'll drop it. >> >>> This looks good, but I've had a different plan for this feature: >> >> Yeah I thought you might, I just wanted to hack something up to see it >> working >> since it seems new Dota 2 uses this feature. >> >>> I'd like the states to be converted into 2 atoms: >>> >>> 1 r600_atom for all 16 viewports >>> 1 r600_atom for all 16 scissors >>> >>> Each atom should have a bitmask saying which "slots" are dirty. (the same >>> idea as resource slots) >>> >>> The "emit" functions should only emit dirty viewports/scissors. >>> >>> Also, the "emit" functions shouldn't emit non-zero viewports/scissors >>> if the viewport index isn't written by the hardware VS stage >>> (si_get_vs_info(sctx)->...). This should keep the same level of >>> effectiveness as before. When a shader that writes the viewport index >>> is bound *and* there are any dirty viewports or scissors, that's the >>> right time to mark the atoms as dirty again, so that non-zero dirty >>> viewports/scissors are finally emitted. >> >> I'm not sure if I'll get to doing more of it, I just had a day at home, >> and wanted to get up to speed on radeonsi a bit, so I can just leave >> that here, in case anyone wants to pick it up, >> >> Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev