XITH3D_USE_VERTEX_BUFFER_CACHING

Engines, Libraries and Tools Xith3D Forums
#1

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)

#2

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.

#3

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 :wink:

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! :slight_smile:

Kev

#4

[quote]See, I never see the problems! :slight_smile:
[/quote]
Try looking in the mirror :stuck_out_tongue:

Thats for this comment :slight_smile:

Endolf

#5

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

#6

[quote]My tests included running 10 instances of my app [very texture/geometry intensive] on 10 different screens simultaneously in resolution of 800x600.
[/quote]
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.

#7

Hi
See my modified post above for new results

Endolf.

#8

[quote]I’m not really sure if more complex applications are more likely to be affected by this bug.
[/quote]
Yes, I know - that’s why I wrote that I did not test this really…

Yuri

#9

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

#10

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. ;D Kev, do you have all the third-party-libs which come with Xith3D in your JRE? Or are you using other libs?

#11

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

#12

Hi,
I described some tests here

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

Bye

#13

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

#14

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.

#15

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

#16

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.

#17

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

#18

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

#19

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

#20

[quote]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.
[/quote]
Sorry, I thought you use a Jogl port of lesson 45, which is available for download somewhere.