[Xquartz-dev] 2.3.3-beta1

[Jack Howarth]

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