Keith Packard wrote:
On Mon, 2008-05-19 at 20:11 +0100, Keith Whitwell wrote:
I'm still confused by your test setup... Stepping back from cache
metaphysics, why doesn't classic pin the hardware, if it's still got
60% cpu to burn?
glxgears under classic is definitely not pinning
So possibilities are:
- batchbuffer starvation -- has
I was going to say 'has this changed significantly' -- and the answer
is that it has of course, with the bufmgr_fake changes... I can't
tell by quick inspection if these are a likely culprit, but it's
certainly a signifcant set of changes
* Classic is apparently doing suboptimal syncs that limits its
performance in some cases (gears, teapot and perhaps openarena),
one should not benchmark framerates against classic in those cases.
As I said elsewhere, I'd like to get to the bottom of this -- it
wasn't always this way.
Keith Whitwell wrote:
* Classic is apparently doing suboptimal syncs that limits its
performance in some cases (gears, teapot and perhaps openarena),
one should not benchmark framerates against classic in those cases.
As I said elsewhere, I'd like to get to the bottom of this
So possibilities are:
- batchbuffer starvation -- has
- over-throttling in swapbuffers -- I think we used to let it get
two frames ahead - has this changed?
I would suspect this broke somehow at some point..
Dave.
Hi, everyone,
I wonder how you got any OpenGL-app running using Keith's GEM tree. For
me even glxgears turns the screen black although AFAIK not necessarily
crashing the Xserver.
I will further investigate on that.
Best regards, Johannes
Johannes Engel schrieb:
Hi, everyone,
I wonder how you got any OpenGL-app running using Keith's GEM tree.
For me even glxgears turns the screen black although AFAIK not
necessarily crashing the Xserver.
I will further investigate on that.
OK, at least that seems not to be reproducible,
Johannes Engel wrote:
Hi, everyone,
I wonder how you got any OpenGL-app running using Keith's GEM tree. For
me even glxgears turns the screen black although AFAIK not necessarily
crashing the Xserver.
I will further investigate on that.
Best regards, Johannes
Johannes,
Double-check
Thomas Hellström schrieb:
Johannes Engel wrote:
Hi, everyone,
I wonder how you got any OpenGL-app running using Keith's GEM tree.
For me even glxgears turns the screen black although AFAIK not
necessarily crashing the Xserver.
I will further investigate on that.
Best regards, Johannes
Keith Whitwell wrote:
Texdown
1327MB/s (i915tex)
551MB/s (master, ttm)
572MB/s (master, no-ttm)
Texdown, subimage
1014MB/s (i915tex)
134MB/s (master, ttm)
148MB/s (master, no-ttm)
Gem on this machine (kernel 2.6.24) is hitting
Texdown 342MB/s
Texdown, subimage
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
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
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
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
On Mon, 2008-05-19 at 20:11 +0100, Keith Whitwell wrote:
I'm still confused by your test setup... Stepping back from cache
metaphysics, why doesn't classic pin the hardware, if it's still got
60% cpu to burn?
glxgears under classic is definitely not pinning the hardware -- the
'intel_idle'
15 matches
Mail list logo
