On Wed, Dec 6, 2017 at 3:31 PM, Ian Romanick <i...@freedesktop.org> wrote: > On 12/05/2017 08:25 AM, Ilia Mirkin wrote: >> On Tue, Dec 5, 2017 at 8:18 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> Hi Rob, >>> >>> On 5 December 2017 at 12:54, Rob Clark <robdcl...@gmail.com> wrote: >>>> This is a bit sad/annoying. But with current GPU firmware (at least on >>>> a5xx) we can support both draw-indirect and base-instance. But we can't >>>> support draw-indirect with a non-zero base-instance specified. So add a >>>> driconf option to hide the extension from games that are known to use >>>> both. >>>> >>>> Signed-off-by: Rob Clark <robdcl...@gmail.com> >>>> --- >>>> Tbh, I'm also not really sure what to do when/if we got updated firmware >>>> which handled draw-indirect with base-instance, since we'd need to make >>>> this option conditional on fw version. For STK that probably isn't a >>>> big deal since it doesn't use draw-indirect in a particularly useful way >>>> (the indirect buffer is generated on CPU). >>>> >>> Couldn't freedreno just return 0 for PIPE_CAP_DRAW_INDIRECT (aka >>> disable the extension) as it detects buggy FW? >>> This is what radeons have been doing as they encounter iffy firmware or >>> LLVM. >>> >>> AFAICT freedreno doesn't do GL 4.0 or GLES 3.1 so one should be safe. >> >> Rob is this -><- close to ES 3.1, so that's not a great option. > > And I don't suppose there's a way to get updated firmware? i965 has > similar sorts of cases where higher versions are disabled due to missing > kernel features. >
so after r/e the instruction set for the CP microcontrollers and writing a disassembler and assembler[1], and figuring out how the fw handles CP_DRAW_INDIRECT and CP_DRAW_INDX_INDIRECT packets, I've come to the conclusion that the issue isn't actually with draw-indirect vs base-instance (at least not w/ the fw from my pixel2 which md5sum claims is the same as what is in linux-firmware.. it is possible that I was using an earlier version of the fw before when I came to this conclusion). On the plus side, the PFP/ME microcontrollers that parse the cmdstream are pretty neat and I learned some useful stuff along the way. But thinking a bit about how stk is using GL_MAP_PERSISTENT_BIT to map and update the draw-indirect buffers, it seems to me there are plenty of ways this can go wrong w/ tilers (and even more when you throw re-ordering into the mix). Possibly I should disable reordering when the indirect buffer is mapped w/ PERSISTENT bit, although for games like stk this is probably counter-productive vs just hiding the draw-indirect extension.. for games that actually use the GPU to write the draw-indirect buffer it shouldn't be a problem. So I think a driconf patch like this probably still ends up being useful in the end. BR, -R [1] https://github.com/freedreno/envytools/tree/afuc/afuc _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
