On Fri, 2010-03-19 at 17:11 +0100, Brice Goglin wrote: > The whole point is that glxgears reports something that is meaningless > and we're trying to fight about it by hiding as much as possible all > reports that show glxgears in big. Some distributions even hide the > glxgears fps output by default because of this meaningless output. glxgears is showing the same problem (very poor performance) as every other application I've tested. How is that meaningless? > The reason is: KMS sometimes synchronizes the commands it sends to the > GPU with the vertical refresh rate. In this case, it just becomes > impossible to see more fps than the refresh rate (ie 60fps for > instance). Getting 8000fps from glxgears may just be impossible in the > future. Measuring real FPS is a matter of using an application that uses > the GPU so much that it will be slower than the refresh rate. So people > use Quake or other complex 3D games to benchmark these. AisleRiot gets ~15-30 FPS, which is terrible considering it's just a solitaire game. armagetronad locks up the entire X display for seconds at a time, leaving only a split second between lock-ups where the mouse cursor can be moved. > AisleRiot is probably a matter of 2D acceleration, which is another > problem (likely related to DRM and EXA, but not related to OpenGL). > x11perf might measure this properly, not sure how. I am not sure about > ZSNES. AisleRiot uses libclutter (and, therefore, OpenGL) for drawing. ZSNES uses OpenGL as well. Both show very poor performance.
Attachment:
signature.asc
Description: This is a digitally signed message part