[quote] Just ran it at the office to see what it does here. The results are not pretty:
Win2003, P4 2.4GHz, Intel Extreme driver version 6.13.1.3259, 3.1fps
[/quote]
puf - thanks for that. I understand the poor performance, as the infrastructure wil drop back to naive rendering if VBOs are not available. When you say things were ‘not pretty’ does this mean that the image quality looked like if was corrupted also, or was it just the speed that was the issue ?
Rob
[quote] It doesn’t run fullscreen, only windowed, is that normal?
[/quote]
Yes - personally I don’t much like full screen exclusive mode for the applications I’m playing with.
Thanks for the figures,
Rob
Rob, I actually meant that the performance was not pretty. The rendering result itself looks ok.
Yesterday I did some further investigation as to why performance would be this bad and found out that on Windows 2003 Server it uses software rendering by default. That probably explain the crappy performance I’ve been getting.
I switched video rendering to using full hardware acceleration and most apps now perform much better.
With your kit2 app however, I only see the initial frame being rendered. After that the image remains static, even though the status bar keeps getting updated. The figures in the status bar now actually show more reasonable performance (26fps). But it would be nice if I could actually see some of those frames being rendered. :-/
puf,
Thanks for the update - unfortunately I’m baffled by the lack of anything other than the first frame. The fact that the status bar is getting updated indicates that I’m in my normal rendering loop, and think that I’m rendering frames OK.
Puzzled,
Rob
Ken Russell wrote:
[quote] Demo runs smoothly on an NVidia Quadro FX Go700 (mobile chip) with 67.42 drivers. However, it looks like none of the textures are showing up. The polygons are smoothly shaded in shades of white, gray, and some tan areas for the lawns.
[/quote]
Ken - I’m hoping that I might have fixed this problem. I was checking GL_ARB_texture_compression but using GL_COMPRESSED_RGB_S3TC_DXT1_EXT. I’m now checking both GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc and hopefully setting the texture internal format appropriately. If you’ve got time to give this another go, I’d appreciate it.
You should now see a number of printlns on the Java console saying which iformat is being used.
Rob
[quote]unfortunately I’m baffled by the lack of anything other than the first frame. The fact that the status bar is getting updated indicates that I’m in my normal rendering loop, and think that I’m rendering frames OK.
[/quote]
Well, there’s a pretty good chance that it is something in my local settings. Running on a server edition of Windows is guaranteed to take you through all kinds of interesting option dialogs before you get you 3d apps working with any kind of frame rate. 
[quote]I was checking GL_ARB_texture_compression but using GL_COMPRESSED_RGB_S3TC_DXT1_EXT. I’m now checking both GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc and hopefully setting the texture internal format appropriately.
[/quote]
Unfortunately still no textures on my Quadro FX Go700. The new printlns report that GL_COMPRESSED_RGB_S3TC_DXT1_EXT compression is being used. The demo runs with textures on my Radeon 9800 (Catalyst version 4.9; I should upgrade) though slowly – about 10 FPS when all of the geometry (in particular the houses) is in view, though it speeds up considerably if the camera is pointed up at the lights or down at the road.
Ken,
Thanks for the info. It leaves me puzzled I’m afraid, as I don’t understand why your Quadro FX Go700 is behaving differently to my FX5200. I’m now pretty confident in my texture / texture compression code.
I also don’t quite understand why things are so slow on your Radeon unless it is the drivers, given that chman reported 70fps on a similar card. I’ve enabled anisotropic filtering since this figure was reported, but I wouldn’t expect that to account for such a difference.
Anyhow, this all just goes to prove that it’s non-trivial to write an infrastructure that works well on more than one hardware configuration, which is what the point of starting this thread was, so it’s all good information.
Thanks again,
Rob
Win2K, C455, 128m, Voodoo 3 3000
net.java.games.jogl.GLException: Unable to enumerate pixel formats of window using wglGetPixelFormatAttribivARB: 0
at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:412)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:211)
at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:250)
at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:112)
at java.awt.Component.setBounds(Unknown Source)
at java.awt.BorderLayout.layoutContainer(Unknown Source)
at java.awt.Container.layout(Unknown Source)
at java.awt.Container.doLayout(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at java.awt.Container.validate(Unknown Source)
at java.awt.Window.pack(Unknown Source)
at rob.kit2.Start.go(Start.java:169)
at rob.kit2.Start.main(Start.java:719)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
:-/
Ken Russell wrote:
[quote] Unfortunately still no textures on my Quadro FX Go700
[/quote]
Ken - I just tried running with Mustang (1.6.0-ea-b16) and get very similar symtoms to those you describe - grey houses, very little colour except in the lawns. My previous Mustang build was OK.
I’ve been running with 1.5.0-b64 which is OK - I’m about to try 1.5.0 update 1 - maybe that’s what’s causing it.
Rob
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
[quote]If there any chance that you were running with Mustang ?
[/quote]
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?
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
Ken,
I’m pretty proud of having tracked this down.
Here’s my code for calculating my number of mipmap levels
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:
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
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
[quote]I’m pretty proud of having tracked this down.
[/quote]
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
int levels = (int)Math.rint(Math.log(w) / Math.log(2.0)) + 1;
or
int levels = (int)Math.floor((Math.log(w) / Math.log(2.0)) + 0.5) + 1;
to compute log_2(w).
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
Ken,
[quote]see bug ID 6213988 in the bug database on java.sun.com (when it becomes visible – probably within 24 hours).
[/quote]
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
Vorax,
I’ve replied to your other thread. In short VSYNC disabling works for me and is now in the kit2 WebStart.
[quote]What I would like to see is comparisons against a real video card that should be getting 500+ fps with this test
[/quote]
This level of performance is unlikely for my code for several reasons:
Rob
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:
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:
Rob