On Mon, 2008-05-19 at 20:32 +0200, Thomas Hellström wrote: > Keith Packard wrote: > > 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 > > > > > Keith, > > The GEM timings were done with 2.6.25, except on the i915 system texdown > timings which used 2.6.24. > Indeed, Michel reported much worse GEM figures with 2.6.23.
We clearly need to find a way to generate reproducible benchmark data.
Here's what I'm running:
kernel:
commit 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed Apr 16 19:49:44 2008 -0700
Linux 2.6.25
(there's a patch to export shmem_file_setup on top of this)
mesa (from git://people.freedesktop.org/~keithp/mesa):
commit 8b49cc104dd556218fc769178b96f4a8a428d057
Author: Keith Packard <[EMAIL PROTECTED]>
Date: Sat May 17 23:34:47 2008 -0700
[intel-gem] Don't calloc reloc buffers
Only a few relocations are typically used, so don't clear
the
whole thing.
drm (from git://people.freedesktop.org/~keithp/drm):
commit 6e46a3c762919af05fcc6a08542faa7d185487a1
Author: Eric Anholt <[EMAIL PROTECTED]>
Date: Mon May 12 15:42:20 2008 -0700
[GEM] Update testcases for new API.
xf86-video-intel (from git://people.freedesktop.org/~keithp/xf86-video-intel):
commit c81050c0058e32098259b5078515807038beb7d6
Merge: 9c9a5d0... e9532f3...
Author: Keith Packard <[EMAIL PROTECTED]>
Date: Sat May 17 23:26:14 2008 -0700
Merge commit 'origin/master' into drm-gem
> Your figures look a bit odd. Is glxgears classic CPU-bound? If not, why
> does it give a significantly slower framerate than
> glxgears GEM?
glxgears uses 40% of the CPU in both classic and gem. Note that the gem
version takes about 20 seconds to reach a steady state -- the gem driver
isn't clearing the gtt actively and so glxgears gets far ahead of the
gpu.
My theory is that this shows that using cache-aware copies from a single
static batch buffer (as gem does now) improves cache performance and
write bandwidth.
--
[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
