On 05/23/2012 08:51 AM, Jerome Glisse wrote:
On Wed, May 23, 2012 at 5:27 AM, Dave Airlie<airlied@xxxxxxxxx> wrote:On Thu, May 17, 2012 at 7:28 PM,<j.glisse@xxxxxxxxx> wrote:So here is improved patchset, where i splited ground work necessary for the dumping into their own patch. The debugfs improvement could probably be usefull to intel instead of having i915 have it's own debugfs file stuff. The lockup dumping public api have been move into radeon_drm.h Stressing the fact again that dump are self contained ie they have all the data needed to be replayed (vertex, indices, shader, texture, ...). Would really like to get this into 3.5, the new API is pretty much straightforward and userspace tools can easily be made to convert it to other format. The change to the driver is self contained.I really don't like introducing this at this stage into 3.5, I'd really like a good review of the API and what information we provide along with how extensible it is. I'm still not convinced replay is what we want in the field, I know its what *you* want, but I think apitrace stuff in userspace pretty much covers the replaying situation. So I'd have to look at this and see how easy it makes disecting command streams etc. Dave.It store pciid and allow to dump all ib per ring, and all associated bo object. It also have a bunch of flags to help the userspace tools (like does userspace need to clear offset (vm vs no vm) ... What more do you want to know ?
Another useful thing might be current register states. We've been doing dumping (we call it snapshot) in the Qualcomm driver for a little bit now and between registers, rings, command buffers and various buffers we've been able to get a reasonably good picture of the state suitable for playback on emulators and other silly userspace tricks. We have structs for registers and index/data register pairs because we also dump lots of debug registers and queues and other various HW sources. The implementation is way different for obvious reasons but I would love to consolidate on a single format. Its easy for us to do since we share similar architectures, but if least two GPUs support the same format it can be a catalyst for others to join. https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/gpu/msm/kgsl_snapshot.h;hb=refs/heads/msm-3.0 Jordan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel