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.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
