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.
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
