[Intel-gfx] [PATCH] Use buffer objects for binding table and surface-state objects.

[Carl Worth]

On Tue, 2008-11-04 at 10:08 +0100, Clemens Eisserer wrote:
> Is that the patch you talked about when I reported a performance
> regression as bug 18075?
> Should I re-try, or are there other fixes planned, and will this fox
> also improve performance in non-GEM mode?

Hi Clemens,

On that bug Lukas said he suspected that the original revert of my first
"use buffer-object for vertex buffers" patch was a cause of the original
slowdown. The commit I just created restores that functionality, so this
recent work might have been something I mentioned at some point.

The funny thing is that it's not really obvious to me why that original
revert would cause any big performance regressions. I had misunderstood
it as reverting the larger vertex buffer, but that was still in place
and the only change was that the driver was using a chunk of static
memory rather than a buffer object for the vb.

Anyway, it's always a good idea to try the latest code and see how we're
doing. But I should also explain exactly what we're working on here.

The work I'm doing now is to use GEM buffer objects for all dynamic data
within the driver. I did the vertex buffer first, then the binding
tables and the surface state objects. So that's all done now. All that
remains is to now user buffer objects for the pixmaps as well.

Some of that happened to increase performance, but that was pretty much
accidental. This could have slowed things down and it still would have
been working. What we're doing is completely rewriting the driver to be
able to sit on top of GEM for all of its buffer management. Then, once
that's done we have the opportunity to do some *real* performance
improvments.

For example, in the current driver there's still a one-time allocation
of memory up front into two regions---one for 3D and one for 2D. The
percentage given to each is configurable in your xorg.conf file, but you
only get one number to control the upfront allocation. So what happens
is if one of these is too small and gets full then performance starts
suffering very badly. But with GEM we'll be able to dynamically adapt to
circumstances as needed. So that will be a big win.

Also, in general, with several performance problems that have been
reported in the last few months, I just haven't looked closely at them.
That is, I haven't been replicating them and profiling to find the exact
problems, etc. That's because I knew that the details would all be
changing with the GEM rework. That has been taking longer than I've
wanted of course, but it's really close with the things I just pushed,
so soon I hope to be able to take a serious look at all reported
performance issues for EXA. (Which is why I've been asking people to
provide detailed reports rather than just "EXA is slower".)

Like I said, the next step is buffer objects for pixmaps. And there are
two routes for testing that that have already been coded: Keith's work
on UXA, (which is very interesting since it rips out all the migration
code from EXA which has long been a source of performance problems), or
Jesse's recent working adding pixmap buffer objects to EXA. I'll be
looking at those now, but if anyone else wants to join in and help, that
would be great too!

Feel free to ask any further questions here or in #intel-gfx.

Thanks for your patience while we rebuild the world of our driver here.

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20081104/dec2b19e/attachment.sig>