radeondb capturing & replaying GPU command stream

radeondb capturing & replaying GPU command stream

[Jerome Glisse]

Hi all,

So i pushed a new dump facility in libdrm, it will dump
everything needed to replay a command stream you just need
to set CS_BOF_DUMP to 1 but be aware that any application
that you launch will than create a new file for each cs
it sends and file can be several M or maybe even G if you
try dumping a program with hugue number of big texture.

The dump file format is inefficiant and dump everythings
and don't try to take advantages of buffer being the same
from one cs to the other but i wasted a couple of week trying
to be clever and i don't think it's worth the trouble it
only makes things more complex and more buggy. So i am
now quite happy with the current design after all it's
intended only to be use as a debug helper while writting
driver or trying to fix a driver bug.

Of course this would be pretty useless without a way to
replay those file so i did hackup a quick tools radeondb
that i wish to grow to swiss knife for radeon debugging.
Some of its function needs to be run outside X with KMS
enabled and as root (replaying cs needs that).

So to replay a command stream simply do :
radeondb -p mycsfile.bof
You shall see the content of the rendered buffer before
the cs get executed, press a key and you shall see the
content of the rendered buffer once the cs is executed.
I was able to replay openarena cs so i am pretty confident
that it should work well. The program also check that
you are replaying a command stream on a valid gpu ie
don't try to replay cs of r3xx hw on r5xx hw.

I intend to do an X friendly version of the tools at
one point. In the meantime i will be adding r5xx,r3xx
support over the weekend and latter r1xx,r2xx (most
of what is needed is autogenerated file see r600_states.h).

I am also working on adding the same dump format to
kernel to capture cs responsible of GPU lockup.

Idea/comments are welcome

Cheers,
Jerome

radeondb should show up at:
http://cgit.freedesktop.org/~glisse/radeondb

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: radeondb capturing & replaying GPU command stream

[Pauli Nieminen]

On Thu, Apr 8, 2010 at 7:10 PM, Jerome Glisse <glisse@freedesktop.org> wrote:
> Hi all,
>
> So i pushed a new dump facility in libdrm, it will dump
> everything needed to replay a command stream you just need
> to set CS_BOF_DUMP to 1 but be aware that any application
> that you launch will than create a new file for each cs
> it sends and file can be several M or maybe even G if you
> try dumping a program with hugue number of big texture.
>
> The dump file format is inefficiant and dump everythings
> and don't try to take advantages of buffer being the same
> from one cs to the other but i wasted a couple of week trying
> to be clever and i don't think it's worth the trouble it
> only makes things more complex and more buggy. So i am
> now quite happy with the current design after all it's
> intended only to be use as a debug helper while writting
> driver or trying to fix a driver bug.
>

How about some zlib compression? That should reduce the size of dump
quite nicely when there is a lot of duplicate data.

> Of course this would be pretty useless without a way to
> replay those file so i did hackup a quick tools radeondb
> that i wish to grow to swiss knife for radeon debugging.
> Some of its function needs to be run outside X with KMS
> enabled and as root (replaying cs needs that).
>
> So to replay a command stream simply do :
> radeondb -p mycsfile.bof
> You shall see the content of the rendered buffer before
> the cs get executed, press a key and you shall see the
> content of the rendered buffer once the cs is executed.
> I was able to replay openarena cs so i am pretty confident
> that it should work well. The program also check that
> you are replaying a command stream on a valid gpu ie
> don't try to replay cs of r3xx hw on r5xx hw.
>
> I intend to do an X friendly version of the tools at
> one point. In the meantime i will be adding r5xx,r3xx
> support over the weekend and latter r1xx,r2xx (most
> of what is needed is autogenerated file see r600_states.h).
>
> I am also working on adding the same dump format to
> kernel to capture cs responsible of GPU lockup.
>
> Idea/comments are welcome
>
> Cheers,
> Jerome
>
> radeondb should show up at:
> http://cgit.freedesktop.org/~glisse/radeondb

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: radeondb capturing & replaying GPU command stream

[Jerome Glisse]

On Thu, Apr 08, 2010 at 11:09:33PM +0300, Pauli Nieminen wrote:
> On Thu, Apr 8, 2010 at 7:10 PM, Jerome Glisse <glisse@freedesktop.org> wrote:
> > Hi all,
> >
> > So i pushed a new dump facility in libdrm, it will dump
> > everything needed to replay a command stream you just need
> > to set CS_BOF_DUMP to 1 but be aware that any application
> > that you launch will than create a new file for each cs
> > it sends and file can be several M or maybe even G if you
> > try dumping a program with hugue number of big texture.
> >
> > The dump file format is inefficiant and dump everythings
> > and don't try to take advantages of buffer being the same
> > from one cs to the other but i wasted a couple of week trying
> > to be clever and i don't think it's worth the trouble it
> > only makes things more complex and more buggy. So i am
> > now quite happy with the current design after all it's
> > intended only to be use as a debug helper while writting
> > driver or trying to fix a driver bug.
> >
> 
> How about some zlib compression? That should reduce the size of dump
> quite nicely when there is a lot of duplicate data.

It could save space but it's could become too cpu intensive,
i really think that the size should be that much of an issue
at capture time. We can always compress the file latter for
sending.

Cheers,
Jerome

> > Of course this would be pretty useless without a way to
> > replay those file so i did hackup a quick tools radeondb
> > that i wish to grow to swiss knife for radeon debugging.
> > Some of its function needs to be run outside X with KMS
> > enabled and as root (replaying cs needs that).
> >
> > So to replay a command stream simply do :
> > radeondb -p mycsfile.bof
> > You shall see the content of the rendered buffer before
> > the cs get executed, press a key and you shall see the
> > content of the rendered buffer once the cs is executed.
> > I was able to replay openarena cs so i am pretty confident
> > that it should work well. The program also check that
> > you are replaying a command stream on a valid gpu ie
> > don't try to replay cs of r3xx hw on r5xx hw.
> >
> > I intend to do an X friendly version of the tools at
> > one point. In the meantime i will be adding r5xx,r3xx
> > support over the weekend and latter r1xx,r2xx (most
> > of what is needed is autogenerated file see r600_states.h).
> >
> > I am also working on adding the same dump format to
> > kernel to capture cs responsible of GPU lockup.
> >
> > Idea/comments are welcome
> >
> > Cheers,
> > Jerome
> >
> > radeondb should show up at:
> > http://cgit.freedesktop.org/~glisse/radeondb
> 

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--