All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Crouse <jcrouse@codeaurora.org>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: GPU lockup dumping
Date: Wed, 23 May 2012 13:33:39 -0600	[thread overview]
Message-ID: <4FBD3B93.9030201@codeaurora.org> (raw)
In-Reply-To: <CAH3drwbi1Z2zGX+P=QmYV9buRN0Yok05PV_+397NYfeCnUW1Lw@mail.gmail.com>

On 05/23/2012 08:51 AM, Jerome Glisse wrote:
> On Wed, May 23, 2012 at 5:27 AM, Dave Airlie<airlied@gmail.com>  wrote:
>> On Thu, May 17, 2012 at 7:28 PM,<j.glisse@gmail.com>  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

  reply	other threads:[~2012-05-23 19:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-17 18:28 GPU lockup dumping j.glisse
2012-05-17 18:28 ` [PATCH 1/5] drm/debugfs: allow driver to provide a custom read callback j.glisse
2012-05-17 18:28 ` [PATCH 2/5] drm/radeon: allow radeon debugfs helper to provide custom read j.glisse
2012-05-17 18:28 ` [PATCH 3/5] drm/radeon: allow radeon_vm_bo_update_pte caller to get bo virtual offset j.glisse
2012-05-17 18:28 ` [PATCH 4/5] drm/radeon: add lockup faulty command recording v2 j.glisse
2012-05-17 18:28 ` [PATCH 5/5] drm/radeon: restore consistant whitespace & indentation j.glisse
2012-05-23  9:27 ` GPU lockup dumping Dave Airlie
2012-05-23 12:34   ` Christian König
2012-05-23 14:48     ` Jerome Glisse
2012-05-23 16:08       ` Dave Airlie
2012-05-23 16:26         ` Jerome Glisse
2012-05-23 16:41           ` Dave Airlie
2012-05-23 17:02             ` Jerome Glisse
2012-05-24  7:58               ` Christian König
2012-05-23 16:04     ` Alex Deucher
2012-05-23 16:26       ` Jerome Glisse
2012-05-23 14:51   ` Jerome Glisse
2012-05-23 19:33     ` Jordan Crouse [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-05-17 19:53 j.glisse
2012-05-17 22:07 j.glisse
2012-05-22 21:08 ` Jerome Glisse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBD3B93.9030201@codeaurora.org \
    --to=jcrouse@codeaurora.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.