Re: i915 performance, master, i915tex gem
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 the hardware -- the 'intel_idle' tool shows that it's only using about 70% of the GPU. GEM is pinning the hardware. Usually this means there's some synchronization between the CPU and GPU causing each to wait part of the time while the other executes. I haven't really looked at the non-gem case though; the numbers seem similar enough to what I've seen in the past. I think getting reproducible results makes a lot of sense. What hardware are you actually using -- ie. what is this laptop? This is a Panasonic CF-R4. So we were actually using a slightly stale version of GEM from Eric's repos, Michel rerun his tests with the indicated versions without any significant changes. I've rebuilt on a HP (Compaq) nx 7300 laptop, 1GB single-channel i945G, Celeron M [EMAIL PROTECTED] GHz. Kernel 2.6.25rc4. This is the third system we test. I've added the teapot demo, since it should be completely CPU-bound, even on this machine. After the tests, I must say Keith Whitwell's conclusions seem to hold: * Intel's TTM and GEM's approaches to buffer management translate to a lot extra CPU usage and worse performance * With that approach, GEM might improve over TTM, but it's not seen here. * 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. And furtermore * GEM's tex(sub)image (map and copy to device) performance really sucks. It would be good to see some benchmarks using pwrite here. Gears: Classic845fps @ 35% Intel TTM 942fps @ 61% GEM902fps @ 61% i915tex (TTM) 977fps @ 40% Openarena + exec anholt @ 640x480 Classic49.8fps 12.3u 1.1s Intel TTM 54.0fps 12.9u 4.6s GEM50.3fps 12.0u 4.8s i915tex (TTM) 61.0fps 12.6u 1.7s Ipers without help screen Classic333000 pps Intel TTM 254000 pps GEMGPU lockup i915tex (TTM) 325000 pps Teapot Classic65.5 fps (CPU at 77%) Intel TTM 70.3 fps GEMGPU lockup i915tex (TTM) 77.0 fps Texdown + subimage Classic452 + 510 MB/s Intel TTM 537 + 158 MB/s GEM385 + 86 MB/s i915tex (TTM) 1185 + 1664 MB/s - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10709] 2.6.26-rc2 hosed X?
http://bugzilla.kernel.org/show_bug.cgi?id=10709 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|NEW |CLOSED Resolution||CODE_FIX --- Comment #3 from [EMAIL PROTECTED] 2008-05-20 02:31 --- fixed by commit af6061af0d9f84a4665f88186dc1ff9e4fb78330 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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 relative to the classic version of classic... - over-throttling in swapbuffers -- I think we used to let it get two frames ahead - has this changed? - something else... Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
* 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. Otherwise we should abandon 'classic' off the trunk and use one of the ye olde 7.0 versions. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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 -- it wasn't always this way. Otherwise we should abandon 'classic' off the trunk and use one of the ye olde 7.0 versions. I agree. I did some benchmarks on TTM vs classic then and they were quite similar back then with TTM generally using slightly more CPU, as we would expect. TTM of course would do better on apps with certain texture functionality due to it's single texture copy. Keith /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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, since it does not occur at the moment one restart later. On my 945GM GEM lets kwin4 with composite feel much smoother. But that's only subjective. glxgears does not pin the CPU but returns values similar to those with TTM. Greetings, Johannes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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 that you're not enabling AIGLX. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GEM discussion questions
Keith Packard wrote: On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote: The obvious overhead I was referring to is the extra malloc / free. That's why I went on to say So, now I have to go back and spend time caching the buffer allocations and doing other things to make it fast. ~ In that context, I is idr as an app developer. :) You'd be wrong then -- the cost of the malloc/write/copy/free is cheaper than the cost of map/write/unmap. One problem that we have here is that none of the benchmarks currently being used hit any of these paths. OpenArena, Enemy Territory (I assume this is the older Quake 3 engine game), and gears don't use MapBuffer at all. Unfortunately, any apps that would hit these paths are so fill-rate bound on i965 that they're useless for measuring CPU overhead. The only place we see significant map/write/unmap vs malloc/write/copy/free is with batch buffers, and so far the measurements that I've taken which appear to show a benefit haven't been reproduced by others... We could certainly use texdown to test this out, if the GEM i915 driver implemented a pwrite-enabled struct dd_function_table::TextureMemCpy() /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GEM discussion questions
On Tue, May 20, 2008 at 1:29 PM, Thomas Hellström [EMAIL PROTECTED] wrote: Keith Packard wrote: On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote: The obvious overhead I was referring to is the extra malloc / free. That's why I went on to say So, now I have to go back and spend time caching the buffer allocations and doing other things to make it fast. ~ In that context, I is idr as an app developer. :) You'd be wrong then -- the cost of the malloc/write/copy/free is cheaper than the cost of map/write/unmap. One problem that we have here is that none of the benchmarks currently being used hit any of these paths. OpenArena, Enemy Territory (I assume this is the older Quake 3 engine game), and gears don't use MapBuffer at all. Unfortunately, any apps that would hit these paths are so fill-rate bound on i965 that they're useless for measuring CPU overhead. The only place we see significant map/write/unmap vs malloc/write/copy/free is with batch buffers, and so far the measurements that I've taken which appear to show a benefit haven't been reproduced by others... We could certainly use texdown to test this out, if the GEM i915 driver implemented a pwrite-enabled struct dd_function_table::TextureMemCpy() Double-copy texture uploads have been 'tested' in the past -- and their poor performance was one of the motivating factors for creating a single-copy scheme. The double-copy upload path isn't *that* bad, as long as the entire texture fits into cache... As soon as it exceeds the cache dimensions, it falls off a cliff. FWIW, Intel are making some cpus with pretty small caches these days, and teaming them up with i945 gpus, so this isn't completely theoretical. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 performance, master, i915tex gem
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 Johannes, Double-check that you're not enabling AIGLX. /Thomas Without AIGLX it does not even run, since I cannot compile the glcore driver since the source file seems to miss any include. :) Greetings, Johannes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15955] mesa build failed.
http://bugs.freedesktop.org/show_bug.cgi?id=15955 liuhaien [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Dodji Seketeli [EMAIL PROTECTED] 2008-05-16 02:18:32 PST --- Hello, I think I hit this as well. I am adding a slightly more helpful log to this bug, hopping this could help. gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/home/dodji/prefix/xorg/include -I/home/dodji/prefix/xorg/include/drm-g -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGLX_DIRECT_RENDERING -I../intel -I../intel/server brw_wm_glsl.c -o brw_wm_glsl.o brw_wm_fp.c: In function ‘emit_fb_write’: brw_wm_fp.c:885: error: ‘struct prog_instruction’ has no member named ‘Sampler’ brw_wm_fp.c:890: error: ‘struct prog_instruction’ has no member named ‘Sampler’ brw_wm_fp.c:893: error: ‘struct prog_instruction’ has no member named ‘Sampler’ brw_wm_fp.c:897: error: ‘struct prog_instruction’ has no member named ‘Sampler’ make[5]: *** [brw_wm_fp.o] Erreur 1 make[5]: *** Attente des tâches non terminées brw_wm_glsl.c: In function ‘emit_fb_write’: brw_wm_glsl.c:342: error: ‘struct prog_instruction’ has no member named ‘Sampler’ brw_wm_glsl.c:343: error: ‘struct prog_instruction’ has no member named ‘Sampler’ make[5]: *** [brw_wm_glsl.o] Erreur 1 make[5]: quittant le répertoire « /home/dodji/devel/git/xorg-jhbuild/mesa/src/mesa/drivers/dri/i965 » make[4]: *** [subdirs] Erreur 1 make[4]: quittant le répertoire « /home/dodji/devel/git/xorg-jhbuild/mesa/src/mesa/drivers/dri » make[3]: *** [linux-solo] Erreur 2 make[3]: quittant le répertoire « /home/dodji/devel/git/xorg-jhbuild/mesa/src/mesa » make[2]: *** [default] Erreur 1 make[2]: quittant le répertoire « /home/dodji/devel/git/xorg-jhbuild/mesa/src/mesa » make[1]: *** [subdirs] Erreur 1 make[1]: quittant le répertoire « /home/dodji/devel/git/xorg-jhbuild/mesa/src » make: *** [default] Erreur 1 Cheers. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15955] mesa build failed.
http://bugs.freedesktop.org/show_bug.cgi?id=15955 liuhaien [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
