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
