On Thu, Mar 30, 2017 at 1:38 PM, Lionel Landwerlin <lionel.g.landwer...@intel.com> wrote: > On 30/03/17 20:09, Chris Wilson wrote: >> >> On Thu, Mar 30, 2017 at 11:27:26AM -0700, Matt Turner wrote: >>> >>> I think we should figure out how to make this not just a fork of >>> intel_error_decode. Should intel_error_decode do away? >>> >>> There are various tools in i-g-t that I'm definitely in favor of >>> moving into Mesa (like the assembler and disassembler, and aubdump). >>> Should this one move too? Do we have buy-in from Chris? >> >> Sure, if it means that we do get an actively maintained decoder - just >> hope that gen2-3 is forthcoming, and perhaps some inferred type >> decoding. > > > I guess that depends on whether we can get somebody to write genxml for > them. > Not sure it's a big priority for us :/ > Maybe a rainy weekend project? > >> >> What's more important is that it is fairly flexible in error-state file >> format - mostly the lists and order of registers change, different >> amount of detail in the kernel state trackers etc. I was thinking that >> maybe we wanted a more parseable format like json (error.json), >> something a bit more flexible? > > > That would be great. > >> What I also want is a use-case for EXEC_OBJECT_CAPTURE. Aside from >> plain listing in the error state, it would be nice if the decoder could >> parse 3DSTATE_BASE to work out which buffer was, for example, the >> instruction buffer and then decode the relevant kernels from 3DSTATE_PS. > > > If I understood things right, I think that's what Matt's working on.
aubinator already does this. >> Decoding vertex buffers is perhaps less interesting in general that it >> was for me, but similarly if they could be found within the error state, >> dumping the vertices for each PRIMITIVE -- though with GS/HS/TS that >> again is probably useless -- so really just an example of being >> flexible, if the data is there in the error state, decode it inline. > > > That's something I'm also interested in. > I would really like to be able to inspect the state of the GPU for each draw > call in aubinator for example. > Lines of text aren't the best way to inspect though. > > A few months back, I started to write an aubinator.py script in the hope of > having some UI on top. > I think we need a slightly better genxml description to have that completely > automatic though, as it stands we miss a some relationships between > offsets/address & STATE_BASE_ADDRESS for example. Be careful, before you know it you'll be writing a simulator. It happened to me. Kristian >> >> I was won over at having pager support. I was getting close to moving >> the decoder to mesa myself, though it would have been a much less >> refined effort! >> -Chris >> > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
