Re: GPU lockup dumping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 23, 2012 at 12:04 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
> On Wed, May 23, 2012 at 8:34 AM, Christian König
> <deathsimple@xxxxxxxxxxx> wrote:
>> On 23.05.2012 11:27, Dave Airlie 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.
>>
>>
>> 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.
>>
>
> I'm ok with it as long as we have a path to implement support for the
> internal dump format so I can have the hw guys play them back on the
> simulators and such.
>
> Alex

>From what i see of the internal dump format, it's way more complex and
i don't think kernel is the right place for it, for instance you need
to set the primary surface thing, i don't want to parse cmd stream in
kernel to figure that out. I would rather have userspace tool that
postprocess thing and convert it to proper AMD dump format.

Cheers,
Jerome
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux