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. 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? 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. 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. 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 -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
