On Thu, May 17, 2012 at 10:41 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: > On Wed, May 16, 2012 at 10:22 PM, <j.glisse@xxxxxxxxx> wrote: >> From: Jerome Glisse <jglisse@xxxxxxxxxx> >> >> This try to identify the faulty user command stream that caused >> lockup. If it finds one it create big blob that contains all >> information needed to replay the faulty command stream. > > Can you state what exactly is going to end up in the dump? > > ring? IB? what about vertex buffers or index buffers, the thing is > should we be concentrating on replay > or just disecting the contents of the ring/IB for stupid things. > > I know the Intel guys do the latter mostly and they seem to be quite > adept at finding bugs in > mesa/ddx from it, when its the obviously reproducible type of hang, as > opposed to the this GPU needs a really messed up workaround. > > Otherwise I dislike the making of implicit ABI from the family and > flags, if we ever have to reorder these it will become painful, > > and the whitespace cleanups should be in another patch, they make it > harder to see what is different, also pointless enum->defines. > > Dave. It dumps ib + all bo relocated with the ib. So everything you need to fully replay the ib. The way to use it is pick the dump turn draw packet into nop. Enable draw packet one by one until you lockup. Once you have the draw packet that triger the lockup, replace the fragment shader it use by a dumb nop frag shader and see if it lockup. If it doesn't lockup than it's fragment shader issue, if it does still lockup than it's either vertex/indices issue or vertex shader issue. You try replacing the vertex shader by something dumb but it's more complex to do than replacing frag shader. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
