XITH3D_USE_VERTEX_BUFFER_CACHING

[Jens]

The vertex buffer caching problem causes a lot of trouble for people who are new to Xith3D on Linux (app exits after short time). It's time we collect some data, to find out what causes this bug. I'd like everyone who reads this posts and runs Linux to write down the following:

• Which system are you running?
  
• Which graphics card do you have?
  
• Which drivers do you have?
  
• Which OpenGL version do you have?
  
• Are you affected by this bug? If yes, please test the apps listed below.
  

I'll start myself. To run the apps change to the demo directory of  Xith3D. They are all part of com.xith3d.test.

System: Debian GNU/Linux
Graphics card: GeForce4 Ti4200
Drivers: NVidia 44.96
OpenGL version: 1.4
Affected by bug: yes, sometimes

CubeTest: yes
MultitextureTest: no
Xith3DSwitchNodeTest: no
Xith3DAmbientLightingTest: no
Xith3DLineAttributesTest: yes
Xith3DTexCoordGenerationTest: no

(yes = Bug exists/app exits, no = no problem with this app)

[endolf]

Hi
 The bug description isn't the sympom I see, but the flag fixes it. The symptom I see is that the whole of X quickly grinds to a halt, if I hit alt-f4 fast enough then the app will eventually close and I gain control back, leave it too long and to reboot is the only option, that or find every X/kde process and kill em.

Specs

System: Gentoo
Kernel: 2.6.0-beta9
Drivers: NVidia 44.96
OpenGL version: 1.4
X: XFree 4.3.0
WM: KDE 3.1.4

Graphics card: GeForce 256 Pro
CPU: Athlon 1ghz, 100mhz FSB
RAM: 512mb

Affected by bug: Yes, not always though.

CubeTest: Yes
MultitextureTest: No (if you mean TextureBlendTest)
Xith3DSwitchNodeTest: No
Xith3DAmbientLightingTest: No
Xith3DLineAttributesTest: Yes
Xith3DTexCoordGenerationTest: No
Xith3DTextureTransformTest: Yes
Xith3DDirectLightingTest: Yes
Martian Madness (before the flag was set): yes

Cheers

Endolf

Edit: Reran the test with the flag not set (doh ) and got those results. Interestingly unlike with Martian Madness, I had the symptoms Jens described. All were run with scripts copied from the runcubelinux, except where log4j was needed on the cp.

[kevglass]

Specs

System: Gentoo
Kernel: 2.4.1
Drivers: NVidia 44.96  
OpenGL version: 1.4  
X: XFree 4.3.0
WM: KDE 3.1.4

Graphics card: GeForce4 Ti4200
CPU: Athlon XP2000
RAM: 512mb

Affected by bug: Nope, which is damn annoying cause I can't test anyone elses problems
 
CubeTest: no
MultitextureTest: no
Xith3DSwitchNodeTest: no
Xith3DAmbientLightingTest: no
Xith3DLineAttributesTest: no
Xith3DTexCoordGenerationTest: no
Xith3DTextureTransformTest: no
Xith3DDirectLightingTest: no
Martian Madness (before the flag was set): no

See, I never see the problems!

Kev

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

[endolf]

See, I never see the problems!

Try looking in the mirror

Thats for this comment

Endolf

[Yuri Vl. Gushchin]

Hi,

... I remember I also promised to test this... sorry I didn't...

But on the following configuration it ran flawlessly:

OS: Linux RedHat 9, Kernel & X default version.
CPU: Athlon 1.8GHz
Graphic cards: 2 x NVidia Quattro4 NVS 400 + 2 on-board heads of nForce2 chipset (total of 10 heads)
Drivers: NVidia 44.96
OpenGL version: 1.4
Affected by bug: no, but no special tests have been made.

My tests included running 10 instances of my app [very texture/geometry intensive] on 10 different screens simultaneously in resolution of 800x600.

Yuri

[Jens]

My tests included running 10 instances of my app [very texture/geometry intensive] on 10 different screens simultaneously in resolution of 800x600.

I'm not really sure if more complex applications are more likely to be affected by this bug. HelloXith3D is affected, too, although it is very simple. First we have to find out, if always the same apps are affected or if this is machine dependant.

[endolf]

Hi
 See my modified post above for new results

Endolf.

[Yuri Vl. Gushchin]

I'm not really sure if more complex applications are more likely to be affected by this bug.

Yes, I know - that's why I wrote that I did not test this really...

Yuri

[winkman]

Sorry i'm a little late

System:  SuSE 9.0 Pro Kernel: 2.4.? KDE
Card:    Geforce 2 TI (Inno3D)
Driver:  Nvidia 44.96 (built Kernelinterface on Install)
OpenGL:  1.4.0 - Nvidia 44.96

Tests:
CubeTest:  yes
Multitexture: no
SwitchNode: no
AmbientLighting: no
LineAttributes: yes
TexCoordGen: no

[Jens]

We can (probably) draw one conclusion: If a machine is affected by the bug, then always the same apps are affected. Some more testcases would be good to prove this.

My setup is very similar to Kev's. I have a machine Athlon XP 2000, 512 MB RAM, GeForce4 Ti 4200, KDE 3.1.4., NVidia 44.96, OpenGL 1.4 . Only difference is XFree 4.2.1 instead of 4.3, Kernel 2.4.22 instead of 2.6.0-test9 and Debian instead of Gentoo. On the other hand the three latter things are exactly what endolf has in his setup. It doesn't seem to be hardware/software dependant or Kev is doing some magic to avoid the bug.   Kev, do you have all the third-party-libs which come with Xith3D in your JRE? Or are you using other libs?

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

[kevglass]

Well, a use a bit of fairy dust.. a touch a Xmas cheer..

Actually, no, I just used what I pulled out of CVS.

Kev

[trz]

Hi,
I described some tests here

https://xith3d.dev.java.net/issues/show_bug.cgi?id=41

Bye

[Yuri Vl. Gushchin]

Hello,

Finally it's time to check and fix this problem. I got my test Linux box up and running again, and finally was able to reproduce this bug with Xith3DLineAttributesTest.

Even more, I discovered at least one strange situation (wrong behavior) on Windows platform, which disappeared after disabling caching.

Yuri

[Jens]

HelloXith3D is the simplest application which is affected. One of the most interesting affects can be found in SimpleGeometry.java (Getting Started Guide). You have 4 Shape3D's there. If you remove one (read: don't add as a child to the scene), the app is affected by the bug, although it usually works. Hope this helps.

[Yuri Vl. Gushchin]

Hello,

After playing some tome with VBOs on Linux, I figured out some strange behavior: looks like VBOs are slower than usual Vertex Arrays under Linux...

I tested this using JOGL port of NeHe Lesson 45, and perf difference is quite visible.

Can somebody try this on Linux to ensure that this is not system-secific issue?

Yuri

[abies]

VBOs are slower even under windows in many cases. For Nvidia cards, v50+ drivers claim to improve the speed, it was a common observation that under v4x, VBO were slower in almost all cases.

[Yuri Vl. Gushchin]

Well, then, because of it does not provide serious performance benefit, I think it can be moved again back to low-priority issues. And in this case the proposal [of as I recall William Denniss] for making the option XITH3D_USE_VERTEX_BUFFER_CACHING false by default makes sense.

I remember I was voting against that proposal, but I assumed this will give serious performance boost.

Also, I still did not figure out why this does not work under Linux. The exact sympthoms of this problem are [assuming LineAttributes test]:

Scene renders OK first 10 frames - this is because of no VBOs are in use, and vertex arrays used for rendering (cache mode set to AUTO, and renderer waits for 10 frames to decide that geom has not been changed).

11th frame renders OK - VBO cache buffers created and geometry rendered OK from VBOs (when it made directly after call to glBufferDataARB(...)).

12th frame - problems start. VBOs are in use, but geometry is not shown, and OpenGL does not report any errors. Queries for sizes of VBOs show that sizes are OK.

13th..NNNth frame - same as frame 12.

NNN+1 frame - application crashes with single "Aborted" message.

NNN is system-dependent.

I will spend some more time investigating this problem, and it would be great to check perf boost/decrease on latest NVidia drivers on Windows (say, basing on NeHe Lesson 45 code) and Linux, as well as with non-NVidia cards that support VBOs on both Windows and Linux.

Yuri

[Jens]

Can you post a link to a test case here, so we can run it (and everyone tests exactly the same)?

[Yuri Vl. Gushchin]

You mean performance test?

If yes, I need some short time to make it as JAR. You can try with NeHe lesson 45 - this is exactly the test I used.

Yuri

[Jens]

You mean performance test?

If yes, I need some short time to make it as JAR. You can try with NeHe lesson 45 - this is exactly the test I used.

Sorry, I thought you use a Jogl port of lesson 45, which is available for download somewhere.

[DavidYazel]

We see significant increases in speed using the vertex buffer caching on window, so I am not sure about the claims that it is slower.

[DavidYazel]

I appreciate you guys helping out with this one.  I don't work on Linux, so it is hard for me to tie this down.

Some threads on opengl.org on this issue:

http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009156.html

http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009521.html

Info on VBO from NVidia.  I didn't know about this paper when I wrote the VBO support for Xith3d, so there is always a possibility that I made a mistake that is causing it to crash on Linux.


http://developer.nvidia.com/object/using_VBOs.html

[abies]

It was slower for me in jogl test programs.

Some extra info
http://groups.yahoo.com/group/opengl-gamedev-l/message/23108
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010483.html
http://www.delphi3d.net/forums/viewtopic.php?t=154

Generally - 4x nvidia drivers have problems with VBO, which are fixed in 5x version.

As far as VBO is concerned, I wonder how many people were able to discover difference between STREAMING and DYNAMIC modes for VBO reading only ARB spec... Week or two ago nvidia has created a document which explains it in more detail (http://developer.nvidia.com/object/using_VBOs.html)

[William Denniss]

Due to the fact that there are some bugs in the linux implementation, I still think having it off by default would be best.  Now that there is confusion as to the benifits and possibly bugs in the third-party driver implementations, there's more reason to turn it off by default until all these issues have been resolved.

Don't forget that it is only one line of java code to turn it back on for your application:

1   2

// cp is your CanvasPeer cp.getRenderOptions().setOption(Option.USE_VERTEX_BUFFER_CACHING, true);

ref: http://xith.org/tutes/GettingStarted/html/using_renderoptions.html

Will.

[winkman]

All demos work for me now on linux with the new 53.28 nvidia linux drivers and XITH3D_USE_VERTEX_BUFFER_CHACHING enabled.
...unless someone turned vertex buffers off in xith the hard way

regards
Martin

[William Denniss]

I too have downloaded the latest drivers and they seem to solve the problem.

good stuff.

Will.

[Yuri Vl. Gushchin]

Yes, I also can confirm that 53.28 drivers fix this issue on Linux.

So, what should be the action on this? Shouls we enable VBOs by default now (I mean in jnlp files) or we will wait a bit while majority will upgrade? Does it make sense to recommend to test driver version before enabling VBOs? Should we add such test (read: NVidia bug workaround) in core Xith3D renderer?

Yuri

[Jens]

+1 for adding such a test to the Xith3D core renderer.

[William Denniss]

defiantly wait a bit for the JNLP, especially since none of the demo's really _need_ it turned on.

In a few months we may as well turn it back on however.

When you say a driver check do you mean it would just print out "Warning you are using old, incompatable drivers" or somthing like that?.  If so, +1

Will.

[Yuri Vl. Gushchin]

When you say a driver check do you mean it would just print out "Warning you are using old, incompatable drivers" or somthing like that?.

Action above plus disable VBOs if not EXPLICITLY enabled - we know one combination (Linux+NVidia drvs < 53.28) where it does not work. This is to-be-added to CanvasPeerImpl. This is how I see this.

Suggested check implementation: check GL's class name if it contains substring .x11. - then we are on *nix, then check renderer string for NVIDIA, then extract version, and if < 53.28 - check passes.

Yuri