Re: i915 performance, master, i915tex & gem
[Posted May 27, 2008 by corbet]
| From: |
| Keith Packard <keithp-AT-keithp.com> |
| To: |
| Keith Whitwell <keith-AT-tungstengraphics.com> |
| Subject: |
| Re: i915 performance, master, i915tex & gem |
| Date: |
| Mon, 19 May 2008 11:00:50 -0700 |
| Message-ID: |
| <1211220050.27447.367.camel@koto.keithp.com> |
| Cc: |
| Dave Airlie <airlied-AT-linux.ie>, Ian Romanick <idr-AT-us.ibm.com>,
DRI <dri-devel-AT-lists.sourceforge.net> |
| Archive-link: |
| Article,
Thread
|
On Mon, 2008-05-19 at 05:09 -0700, Keith Whitwell wrote:
> I
> think the latter is the significant result -- none of these experiments
> in memory management significantly change the command stream the
> hardware has to operate on, so what we're varying essentially is the
> CPU behaviour to acheive that command stream. And it is in CPU usage
> where GEM (and Keith/Eric's now-abandoned TTM driver) do significantly
> dissapoint.
Your GEM results do not match mine; perhaps we're running different
kernels? Anything older than 2.6.24 won't be using clflush and will
instead use wbinvd, a significant performance impact. Profiling would
show whether this is the case.
I did some fairly simple measurements using openarena and enemy
territory. Kernel version 2.6.25, CPU 1.3GHz Pentium M, 915GMS with the
slowest possible memory. I'm afraid I don't have a working TTM
environment at present; I will try to get that working so I can do more
complete comparisons.
fps real user kernel
glxgears classic: 665
glxgears GEM: 889
openareana classic: 17.1 59.19 37.13 1.80
openarena GEM: 24.6 44.06 25.52 5.29
enemy territory classic: 9.0 382.13 226.38 11.51
enemy territory GEM: 15.7 212.80 121.72 40.50
> Or to put it another way, GEM & master/TTM seem to burn huge
> amounts
> of CPU just running the memory manager.
I'm not seeing that in these demos; actual allocation is costing about
3% of the CPU time. Of course, for this hardware, the obvious solution
of re-using batch buffers would eliminate that cost entirely.
It would be nice to see the kernel time reduced further, but it's not
terrible so far.
--
keith.packard@intel.com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
(
Log in to post comments)