Bullet Optimisation

Everything about development and the OpenMW source code.
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: Bullet Optimisation

Post by sirherrbatka »

what about running openmw from console with xinit?

This is not connected to the bullet, but well... ;-)
User avatar
gus
Posts: 390
Joined: 11 Aug 2011, 15:41

Re: Bullet Optimisation

Post by gus »

What you get on windows seems normal to me (you are simply CPU bound, while i'm GPU bound).

I don't really now what to do with this kind of bug :? Maybe some optimisation are disabled by your compiler? Is it possible (i don't know if you can do it on linux) that someone else (without bug) compile it on linux and send it to you so you could try it?

BTW, Do you get the same results with openGL (on windows) ?
K1ll
Posts: 184
Joined: 06 Aug 2011, 21:54

Re: Bullet Optimisation

Post by K1ll »

Yes it is possible to use binaries compiled on a different machine/system as long as the versions of the needed libraries aren't too different (it's the same for windows and all other operating systems). So if Zini could compile versions of ogre, bullet and openmw that work on my system or tell me where he got his versions if not self compiled i could test if the problem is my compiler. system settings etc. . Although i highly doubt it's something like missing compiler optimisation that's pretty far fetched.

With the OpenGL Renderer I only have 10-20 fps less than with the D3D9 Renderer so at least on windows the OpenGL performance of Ogre isn't far behind D3D9.

Also i noticed that i get a huge performance hit of ca 100 fps and a crash in Vivec if i have sound enabled on windows. Turning sound off in Linux doesn't seem to make a difference though.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Bullet Optimisation

Post by Zini »

Just the standard source code from the project's original site (Ogre 1.7.1 and Bullet 2.77). All self-compiled. Nothing special about it, really.
Also i noticed that i get a huge performance hit of ca 100 fps and a crash in Vivec if i have sound enabled on windows.
That is something to investigate. For me OpenMW hasn't crashed in Vivec in ages. Actually I think we pretty much got all the rendering related crash bugs ironed out. With a bit of luck this crash might give us a hint what is wrong. If you can get this crash reliably, run OpenMW under the debugger and get us a stack backtrace.
User avatar
gus
Posts: 390
Joined: 11 Aug 2011, 15:41

Re: Bullet Optimisation

Post by gus »

Do you think that sound is the cause of the perf hit?
Because If i remember correctly, commenting out bullet code made the perf normal again.

Just the standard source code from the project's original site (Ogre 1.7.1 and Bullet 2.77). All self-compiled. Nothing special about it, really.
It's just that his computer is not the cause (it works on windows, and the bug *should not* be related to linux driver stuff), linux is not the cause (it works on your computer), so I don't see what could be behind this bug except compilation stuff (you probably don't have the same bullet version, etc).
If you have any other idea, you are welcome :lol:
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Bullet Optimisation

Post by Zini »

Do you think that sound is the cause of the perf hit?
I don't know. But it is an abnormality and as such worth investigating. In the worst case we will locate a different bug.
If you have any other idea, you are welcome
The only thing I can think of is to quantify the slowdown more precisely. Currently you are running interior cells against exterior cells. If the performance is linear on average you should get 1/9 of the performance in the exteriors. But cells have widely varying numbers of references and geometry (Vivec is rather extreme). Maybe getting numbers for a larger number of varying cells will tell us something.

Another thought: Are we done with the theory that the hardware in question is just not powerful enough? After all we are running the physics system for the whole 3x3 area, while in MW less than a single cell was considered for collision tests (even outdoors).

Anyway, transferring the binaries would be difficult (unless both the source and the destination system are compatible regarding the dependencies).
K1ll
Posts: 184
Joined: 06 Aug 2011, 21:54

Re: Bullet Optimisation

Post by K1ll »

Well i have good news which are also bad news ^^

As i have mentioned somewhere i used ogre 1.7.2 and bullet 2.78 to build openmw.

Now I have compiled ogre 1.7.1 and bullet 2.77 and used them to compile openmw and the performance hit from the physics is a lot smaller. So i guess there is a regression in bullet but to make sure i'll test it with bullet 2.77 and ogre 2.7.2 later.

To make it clear the sound problems are only on windows and probably have nothing to do with linux. The problem is that somehow it can't find/load some wave files although they are in the right directory:

In Beshara the errors are:

Code: Select all

Error loading C:\openmw\data\Sound\Fx\envrn\cave_wind.wav
Error loading C:\openmw\data\Sound\Fx\envrn\cave_drip.wav
The error in Vivec is different:

Code: Select all

Playing C:\openmw\?ata\Music\Explore\mx_explore_4.mp3
    Music Error: OpenAL exception: "Invalid Value" while creating source
Sound: wind trees4 Chance:5

Error OpenAL exception: "Invalid Value" while creating source
The files are there and they work when played with VLC

PS: Even with the new builds the performance of openmw on linux is rather poor compared to the performance on windows which saddens me but i guess that's caused by the librarys it uses rather than by openmw itself.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Bullet Optimisation

Post by Zini »

PS: Even with the new builds the performance of openmw on linux is rather poor compared to the performance on windows which saddens me but i guess that's caused by the librarys it uses rather than by openmw itself.
There shouldn't be much of a difference with the libraries. What can make a huge difference are the video drivers. Your card is somewhat old and I have no idea how good the drivers for it are or when they have been updated last.
User avatar
gus
Posts: 390
Joined: 11 Aug 2011, 15:41

Re: Bullet Optimisation

Post by gus »

Okay, so should we advise people to use Bullet 2.77 instead?

Now that i think of it, can you do one more bench to see the impact of the physic system without bug on your computer? (I had a few idea today which *could' improve bullet perfs).

Anyway, thanks a lot for K1ll!
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Bullet Optimisation

Post by Zini »

Okay, so should we advise people to use Bullet 2.77 instead?
Makes sense. But if this problem is not known to the Bullet development team yet, it should also be reported to them.
Post Reply