WebStart / Performance test

[Rob Nugent]

Ken,

I just tried JDK 1.5.0 update 01 ( 1.5.0_01-b08 )  and it works fine.  Mustang 1.6.0 (1.6.0-ea-b16) fails reliably even with -Xint which would seem to eliminate any Hotspot funnies.  It even fails in the same way on Linux (Fedora Core 3)

If there any chance that you were running with Mustang ?

Rob

[Ken Russell]

If there any chance that you were running with Mustang ?

No, I was running 1.5.0_02-ea-b03 (one of the internal builds of the forthcoming 1.5.0 Update 2). I just tried with 1.5.0 and your demo works properly on my Quadro FX Go700 with that release. What functionality of the core JDK are you using in your demo? Maybe Image I/O? Can you help narrow down where the problem is so we can file a bug?

[Rob Nugent]

Ken,

I'm using imageio but this is working OK - I have a debug mode that displays all the mipmap levels of each loaded texture in a JFrame and they all look OK, so it appears that something is going wrong converting these BufferedImages to OpenGL textures.

I'll investigate further tomorrow using 1.6.0-ea and keep you posted,

Thanks for your continued attention on this.

Rob

Games published by our own members! Check 'em out!

[Rob Nugent]

Ken,

I'm pretty proud of having tracked this down.

Here's my code for calculating my number of mipmap levels

1   2   3   4   5   6   7   8   9   10

public class Test {     public static void main(String[] args) {         int w = 64;         int levels = (int)(Math.log(w) / Math.log(2.0)) + 1;         System.out.println("Width " + w + " gives " +                 levels + " mipmap levels");     } }

And the output:

1   2   3   4   5   6   7

P:\temp>java -version java version "1.5.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08) Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing) P:\temp>java Test Width 64 gives 7 mipmap levels

1   2   3   4   5   6   7

P:\temp>java -version java version "1.6.0-ea" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b16) Java HotSpot(TM) Client VM (build 1.6.0-ea-b16, mixed mode, sharing) P:\temp>java Test Width 64 gives 6 mipmap levels

If 1.5.0_02 is the same, I'd call it a stop-ship :-)

And so to bed,

Rob

[Ken Russell]

I'm pretty proud of having tracked this down.

You should be; thanks for tracking this down. I was wrong; the change in behavior is only in 1.6 (I had a 1.6 development JVM in my 1.5.0_02 JDK). Math.log() was made into a JVM intrinsic in 1.6 on x86 CPUs and the behavior seems to have changed very slightly, enough to perturb the result of your division. We're investigating the change in behavior; see bug ID 6213988 in the bug database on java.sun.com (when it becomes visible -- probably within 24 hours).

For general robustness, you should probably use

1	int levels = (int)Math.rint(Math.log(w) / Math.log(2.0)) + 1;

or

1	int levels = (int)Math.floor((Math.log(w) / Math.log(2.0)) + 0.5) + 1;

to compute log_2(w).

[Vorax]

Just incase no one solves my vsync problem (another question on the board)....   Are you going to try disabling vsync for the test?  (maybe you will have more luck and post how you did it )

It doesn't make much sense to just be testing against the video refresh speed anyways, unless it is something that is really going to push the video hard anyways.

On my Geoforce 4MX I get 84.7 fps....my video is at 85 Mhz.  If I set to 75...I get 74.8 or so.  What I would like to see is comparisons against a real video card that should be getting 500+ fps with this test

[Rob Nugent]

Ken,

see bug ID 6213988 in the bug database on java.sun.com (when it becomes visible -- probably within 24 hours).

I can't yet see this bug, but since my code is relying on getting the result 6.0 rather than 5.999999 I suspect that the bug might get rejected because I should be using StrictMath.log() rather than Math.log() if I want that level of accuracy.

I've put in a fix similar to the one you suggested so that the WebStart version should now work (v0.03 in window title bar). However it's entirely arguable that my code is stupid to go int->float>int to work out what power of two 64 is, rather than just shifting right.

I'm a *lot* happier if this really is only a change for 1.6.0 by the way - even if this is regarded as a coding 'bug', it seems a major change for an _XX revision to the JVM.

Thanks again for your time on this.

Rob

[Rob Nugent]

Vorax,

I've replied to your other thread.  In short VSYNC disabling works for me and is now in the kit2 WebStart.

What I would like to see is comparisons against a real video card that should be getting 500+ fps with this test

This level of performance is unlikely for my code for several reasons:

1) There is *lots* of geometry being rendered in each frame this is mainly due to the far clip plane being quite distant
2) The culling of geometry outside the view frustum, collision detection etc  takes about 20% of each frame's cycle time. This is of course dependant on the CPU.
3) There are lots of lights in scope
4) Just swappng the buffers is quite expensive

Rob

[Vorax]

I just ran it all the way through with the addition of vsync off and hit 200.2 FPS near the end with a final score of 103.1 FPS.

Not bad for a crappy Geo 4MX

Some other nice additions (requests) to the perf test:

- Show how many tris you are rendering per frame
- Total tris rendered
- Total tris rendered divided by total time
- Option to turn off all textures
- option to run test in full screen mode

[Rob Nugent]

Vorax,

I can't trivially add any of these, although I have added a WebStart option that coerces all the textures to my 1metre measure.

See:

http://abraded.co.uk/jogl/

Rob

Games published by our own members! Check 'em out!

[Azeem Jiva]

Ken,

I'm a *lot* happier if this really is only a change for 1.6.0 by the way - even if this is regarded as a coding 'bug', it seems a major change for an _XX revision to the JVM.

Thanks again for your time on this.

Rob

Actually this bug only happens in 6.0.  I'm the responsible engineer for this bug, and I think I know what the problem is.  Basically I didn't code the Log intrinsics the same way for both the interpreter and the compiler.  Since the Log intrinsic is only 6.0, the fix will be 6.0 only as well

[Rob Nugent]

Azeem,

Thanks for the update - nice to know that you are on the case.

Rob

[elam]

Hi Rob,

GeForce 3, Linux, AMD 2500+, 512M, latest drivers got me 83 fps.

[Azeem Jiva]

Azeem,

Thanks for the update - nice to know that you are on the case.

Rob

The bug is fixed, and should be in Java 6.0 build 19

[girvine]

Gotta love those sneaky bugs in "minor" changes.  Nice work anyway.  

As for the performance.
Dell Inspiron 9200 - 2.1GHz Centrino + Mobile ATI 9700 = 104fps with standard Dell drivers.

I guess the DNA and Omega drivers would improve this a little.

ps. what's this about jdk 6.0, etc?  

[Rob Nugent]

Girvine (and Elam and others),

Thanks for the feedback figures.

Java 6.0  (Mustang) very early snapshot releases are available here:

https://j2se.dev.java.net/index.html

Rob

[mustang]

I get about 120fps on my nVidia.

[Azeem Jiva]

The bug is fixed, and should be in Java 6.0 build 19

Whoops, missed the build 19 cutoff, its in build 20

[Rob Nugent]

Azeem,

Thanks - I'll keep an eye out for it.

Rob

[emarcotte]

Hi,

Not sure if you're still looking for results, but I just ran it and get anywhere from 80-110 fps on athlon 3000+, geforce 4 ti something, fedora core 3...

[Azeem Jiva]

I got 136fps on my Athlon XP 3200+, Nvidia FX5700.  

[Rob Nugent]

emarcotte, Azeem,

Thanks for the feedback.

Azeem - you're the winner of the 'highest frame rate' competition so far !

Rob

[MasterDirk]

WinXP SP1, nVidia GeForce 3 ti200

82fps