[Xquartz-dev] 2.3.3-beta1
Jack Howarth
howarth at bromo.med.uc.edu
Fri Feb 27 06:49:37 PST 2009
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 at 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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
More information about the Xquartz-dev
mailing list