GPU lockup dumping

[Christian König]

On 23.05.2012 11:27, Dave Airlie wrote:
> On Thu, May 17, 2012 at 7:28 PM,<j.glisse at 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.

I agree that it might not be a good idea to push that into 3.5, since at 
least I (and I also think Alex) didn't had time to look into it yet. On 
the other hand the patches look quite reasonable.

But I still wanted to throw in a requirement from my day to day work, 
maybe that helps finding a more general solution:
When we start to work with more parts of the chip it might be necessary 
to dump everything that is currently "in the fly". For example I had a 
whole bunch of problems where copying data around with a 3D Blit and 
then missing a sync between this job and a job on another rings causes a 
"hiccup" in the hardware.

I know that this isn't your focus and that is absolutely ok with me, 
cause the format you are introducing is just used in debugfs and so not 
part of any stable API (at least not in my understanding), but you 
should still keep in mind that we might need to extend it into that 
direction in the future.

Christian.