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
