So as mentioned yesterday, due to 1.6 not being as stable as I'd like, I've put together another release based on the 1.4 server. I've backported the DRI changes and some other miscellaneous cleanup into our 1.4 branch. Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details: http://xquartz.macosforge.org/trac/wiki/X112.3.3 The dmg for the release is here: http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg Thanks to everyone who was testing the 2.4 alphas and betas. We'll get back to that of that once 2.3.3 ships. Thanks, Jeremy
On Feb 25, 2009, at 9:10 PM, Jeremy Huddleston wrote:
So as mentioned yesterday, due to 1.6 not being as stable as I'd like, I've put together another release based on the 1.4 server. I've backported the DRI changes and some other miscellaneous cleanup into our 1.4 branch.
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
Initial simple tests all good William Davis frstanATbellsouthDOTnet Mac OS X.5.6 Darwin 9.5.0 XQuartz 2.3.3_beta1 (xorg-server 1.4.2-apple35) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
So as mentioned yesterday, due to 1.6 not being as stable as I'd like, I've put together another release based on the 1.4 server. I've backported the DRI changes and some other miscellaneous cleanup into our 1.4 branch.
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
Thanks to everyone who was testing the 2.4 alphas and betas. We'll get back to that of that once 2.3.3 ships.
Thanks, Jeremy
Jeremy, The DRI backport changes look good, and pass the test suite. Good job :) The libX11 or some X extension update seems to be trying to pull in some extension support from 1.6 for GenericEvents. The new GenericEvent code which the xorg-server-1.4-apple branch of the X server doesn't support is producing this error in all clients: Xlib: extension "Generic Event Extension" missing on display "/tmp/launch-tl08VW/:0". Xlib: extension "Generic Event Extension" missing on display "/tmp/launch-tl08VW/:0". George -- http://people.freedesktop.org/~gstaplin/
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies. - Jordan On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
You're just not noticing it rotate. It might look slow, but the reported framerate is right. If the gear rotates 721 degrees per frame, it'll look the same as 1 degree per frame. You can't "see" the framerate in the demo... That's why it's printed ;) --Jeremy On Feb 26, 2009, at 23:57, Jordan K. Hubbard wrote:
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies.
- Jordan
On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
You're just not noticing it rotate. It might look slow, but the reported framerate is right. If the gear rotates 721 degrees per frame, it'll look the same as 1 degree per frame. You can't "see" the framerate in the demo... That's why it's printed ;)
--Jeremy
There is something I've noticed and can't explain. Some of the older glxgears seem to appear faster, even when using the new libGL for the old glxgears, but when I use the testbuilds/glxgears it appears slower. So, there does seem to be some glxgears source code or compilation difference. The glxgears_fbconfig appears fast, but also buggy. I see what appear to be artifacts on the Mac (with an ATI card) and I just tested the same code using an X11 Nvidia card/libGL, and found the same issues there. I can't quite explain why, because the frame rates are equivalent. When I compare the framerate of glxgears_fbconfig it's printing: ~5400 So the glxgears_fbconfig code must have changed something more than just from a visual to a GLXFBConfig. The normal glxgears is: ~5500 and appears much smoother on both the Mac and Ubuntu systems. What version of glxgears are you shipping with XQuartz? Is it from the Mesa demos or some other source? Perhaps we could use diff to see what has changed. Jordan, I have been running the latest code in OpenGL Profiler.app, and the stats seem to be accurate with regard to what the profiler says the frame rate is. I have also made some performance improvements and bugs fixes the past 2 days. The more realistic OpenGL applications seem to be pretty fast, such as Pymol, and the more complex Mesa demos. The glXSwapBuffers() path that calls CGLFlushDrawable seems to be simple and operational. It's what swaps the buffer to redraw a frame in a double-buffered context. I expect we would see a lot of redraw problems if it wasn't working, and the profiler doesn't list any problems there that I have seen.
On Feb 26, 2009, at 23:57, Jordan K. Hubbard wrote:
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies.
- Jordan
On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
George -- http://people.freedesktop.org/~gstaplin/
George, The Mesa and X11 developers have always claimed that glxgears is a horrible tool to benchmark performance against. A much better method is to run SPECviewpref. I used to test Darwin against the 8.1 release using the adaptor code from Marcel Bresink. I am unclear on the current state of building the latest release, 10, on Mac OS X. I certainly would be a much better way to obtain performance metrics for the OpenGL in X11. Jack On Fri, Feb 27, 2009 at 03:36:31AM -0700, George Peter Staplin wrote:
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
You're just not noticing it rotate. It might look slow, but the reported framerate is right. If the gear rotates 721 degrees per frame, it'll look the same as 1 degree per frame. You can't "see" the framerate in the demo... That's why it's printed ;)
--Jeremy
There is something I've noticed and can't explain. Some of the older glxgears seem to appear faster, even when using the new libGL for the old glxgears, but when I use the testbuilds/glxgears it appears slower. So, there does seem to be some glxgears source code or compilation difference.
The glxgears_fbconfig appears fast, but also buggy. I see what appear to be artifacts on the Mac (with an ATI card) and I just tested the same code using an X11 Nvidia card/libGL, and found the same issues there. I can't quite explain why, because the frame rates are equivalent.
When I compare the framerate of glxgears_fbconfig it's printing: ~5400
So the glxgears_fbconfig code must have changed something more than just from a visual to a GLXFBConfig.
The normal glxgears is: ~5500 and appears much smoother on both the Mac and Ubuntu systems.
What version of glxgears are you shipping with XQuartz? Is it from the Mesa demos or some other source? Perhaps we could use diff to see what has changed.
Jordan, I have been running the latest code in OpenGL Profiler.app, and the stats seem to be accurate with regard to what the profiler says the frame rate is. I have also made some performance improvements and bugs fixes the past 2 days. The more realistic OpenGL applications seem to be pretty fast, such as Pymol, and the more complex Mesa demos.
The glXSwapBuffers() path that calls CGLFlushDrawable seems to be simple and operational. It's what swaps the buffer to redraw a frame in a double-buffered context. I expect we would see a lot of redraw problems if it wasn't working, and the profiler doesn't list any problems there that I have seen.
On Feb 26, 2009, at 23:57, Jordan K. Hubbard wrote:
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies.
- Jordan
On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
George -- http://people.freedesktop.org/~gstaplin/ _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
I would also welcome a tool which wasn't nearly so subjective as glxgears (hey, in my own defense, it has been there a *long time* and is how we used to measure actual 3D performance back in the day when 3D was still something only scientists and researchers with large grants got to play with :-), bundled by default. Then we could spot any actual regressions a lot more easily. I'm familiar with x11perf (which no one seems to run regularly anymore, even just to compare against their own baseline performance) but not SPECviewpref. Where does one get it? - Jordan On Feb 27, 2009, at 6:49 AM, Jack Howarth wrote:
George, The Mesa and X11 developers have always claimed that glxgears is a horrible tool to benchmark performance against. A much better method is to run SPECviewpref. I used to test Darwin against the 8.1 release using the adaptor code from Marcel Bresink. I am unclear on the current state of building the latest release, 10, on Mac OS X. I certainly would be a much better way to obtain performance metrics for the OpenGL in X11. Jack
On Fri, Feb 27, 2009 at 03:36:31AM -0700, George Peter Staplin wrote:
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
You're just not noticing it rotate. It might look slow, but the reported framerate is right. If the gear rotates 721 degrees per frame, it'll look the same as 1 degree per frame. You can't "see" the framerate in the demo... That's why it's printed ;)
--Jeremy
There is something I've noticed and can't explain. Some of the older glxgears seem to appear faster, even when using the new libGL for the old glxgears, but when I use the testbuilds/glxgears it appears slower. So, there does seem to be some glxgears source code or compilation difference.
The glxgears_fbconfig appears fast, but also buggy. I see what appear to be artifacts on the Mac (with an ATI card) and I just tested the same code using an X11 Nvidia card/libGL, and found the same issues there. I can't quite explain why, because the frame rates are equivalent.
When I compare the framerate of glxgears_fbconfig it's printing: ~5400
So the glxgears_fbconfig code must have changed something more than just from a visual to a GLXFBConfig.
The normal glxgears is: ~5500 and appears much smoother on both the Mac and Ubuntu systems.
What version of glxgears are you shipping with XQuartz? Is it from the Mesa demos or some other source? Perhaps we could use diff to see what has changed.
Jordan, I have been running the latest code in OpenGL Profiler.app, and the stats seem to be accurate with regard to what the profiler says the frame rate is. I have also made some performance improvements and bugs fixes the past 2 days. The more realistic OpenGL applications seem to be pretty fast, such as Pymol, and the more complex Mesa demos.
The glXSwapBuffers() path that calls CGLFlushDrawable seems to be simple and operational. It's what swaps the buffer to redraw a frame in a double-buffered context. I expect we would see a lot of redraw problems if it wasn't working, and the profiler doesn't list any problems there that I have seen.
On Feb 26, 2009, at 23:57, Jordan K. Hubbard wrote:
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies.
- Jordan
On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
George -- http://people.freedesktop.org/~gstaplin/ _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Do you have another OpenGL demo that actually demonstrates "speed of rendering" then? Because they all look slow in comparison to 2.3.2 now. - Jordan On Feb 27, 2009, at 12:28 AM, Jeremy Huddleston wrote:
You're just not noticing it rotate. It might look slow, but the reported framerate is right. If the gear rotates 721 degrees per frame, it'll look the same as 1 degree per frame. You can't "see" the framerate in the demo... That's why it's printed ;)
--Jeremy
On Feb 26, 2009, at 23:57, Jordan K. Hubbard wrote:
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies.
- Jordan
On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jordan, A nice visual check on the presence of hardware accelerated gl support is the Representations demo in pymol. That renders eight rotating molecules which spread away from each other at startup. This demo is clearly slow if you don't have hardware acceleration (ie it should only take a couple of seconds for the molecules to spread out to their final positions). Jack On Fri, Feb 27, 2009 at 09:40:47AM -0800, Jordan K. Hubbard wrote:
Do you have another OpenGL demo that actually demonstrates "speed of rendering" then? Because they all look slow in comparison to 2.3.2 now.
- Jordan
On Feb 27, 2009, at 12:28 AM, Jeremy Huddleston wrote:
You're just not noticing it rotate. It might look slow, but the reported framerate is right. If the gear rotates 721 degrees per frame, it'll look the same as 1 degree per frame. You can't "see" the framerate in the demo... That's why it's printed ;)
--Jeremy
On Feb 26, 2009, at 23:57, Jordan K. Hubbard wrote:
So, I've just confirmed this problem on a MacPro with an 8800GT card as well as a MacBook Pro with built-in 8600GT. The symptom is that glxgears claims high frame rates but does not actually animate with any speed at all (maybe 1-2 FPS). With the shipping Leopard version of the X server, the same demo flies.
- Jordan
On Feb 25, 2009, at 6:10 PM, Jeremy Huddleston wrote:
Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details:
http://xquartz.macosforge.org/trac/wiki/X112.3.3
The dmg for the release is here:
http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (5)
-
George Peter Staplin
-
Jack Howarth
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
William Davis