Multicore CPU utilization

[Shadow]

Not the most urgent thing at the moment I suppose, but it will become one when jlv starts implementing more modern eye candy to the game me thinks. The game's single core restriction is one serious bottleneck that hampers performance quite a bit. Pretty much every pc has multiple cores nowadays, might as well put them to actual use.

[DJD]

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Pumaxcs]

Group video cards into that as well.

[jbrandmx85]

yea my laptop might actually be able to play mxsim decently with this. haha (:

[haydugjr]

+1 to this. Until then I just put everything else on three cores and put MXS on the last core.

[yzmxer608]

I'd like this, I thought jlv said something pretty recent about sli/crossfire but I can't find it now.

[jlv]

I probably will get around to that at some point, but don't expect any magic. The game spends around half of its time in the OpenGL driver so even if you eliminated the time spent on other stuff it would only double the speed. The routines that can be easily parallelized are more like 10% though.

LOD's for the models would make a much bigger difference. At a minimum I need to make some wheels that look good and get down to a couple hundred triangles at a distance. That would save around 4000 triangles per bike.

[haydugjr]

would only double the speed.

[jbrandmx85]

would only double the speed.

haha i was thinking the same thing...

[jlv]

As a "speed of light" maximum possible improvement, 2x is pretty bad.

As an example, imagine a scene with DJ's new trees, only without the LOD's. A alternate frame dual GPU setup would double the FPS on that scene in the best possible case. Putting the LOD's in would reduce the geometry by something like 500 times, making it run 500 times faster in the best possible case. Generally the real world improvement won't be near the upper limit, but 2 times is a pretty bad as an upper limit.

And that's not to say that it's never worth chasing something with a low upper limit. But you want to attack the stuff with potential order of magnitude improvements first.

[Shadow]

How about all the cpu stuff like physics calculations etc? I imagine getting those to work on multiple cores would let people run 20-40 rider races a little smoother.

[jlv]

Sure, it could potentially help. I suspect a fast but inaccurate wheel/ground test for checking roost would help more though. There are a lot of corner cases that are extremely slow to check but critical to good handling when used for collision response. But for roost it doesn't matter if the test is occasionally wrong or has an incorrect normal, so a cheaper test would work fine there. After I did that I'd look into parallelizing it if there were still performance problems.

[socalmx]

As a "speed of light" maximum possible improvement, 2x is pretty bad.

As an example, imagine a scene with DJ's new trees, only without the LOD's. A alternate frame dual GPU setup would double the FPS on that scene in the best possible case. Putting the LOD's in would reduce the geometry by something like 500 times, making it run 500 times faster in the best possible case. Generally the real world improvement won't be near the upper limit, but 2 times is a pretty bad as an upper limit.

And that's not to say that it's never worth chasing something with a low upper limit. But you want to attack the stuff with potential order of magnitude improvements first.

is it just me or does anyone understand that?

[Shadow]

So most of the performance problems comes from usermade content not having LODs? Huh... I didn't think that'd be such a big issue.

[yzmxer608]

Found it.

There isn't much I can do about it. SLI systems currently have some bad restrictions of what you can do with generated textures when running in alternate frame rendering mode. Basically, you have to render, use and discard the generated texture all in one frame, otherwise the texture will be on the wrong card for the next frame and it will have to be copied to the other card. So you can do things like post processing effects or shadow buffers, but for something like MX Sim's terrain cache you need the generated textures for multiple frames, so you get stuck copying the textures over to the other card. If the drivers were really clever they'd notice this and render on both cards when rendering into a texture that's used that way, but so far nothing does that.

I was thinking I could try keeping two copies of the terrain texture cache, one that would only be used on odd frames and the other for even frames. That way it would never access a texture that was on the wrong card. (Unless it got out of sync. Then all hell breaks loose...) The only thing is it would be a fair amount of work with no guarantee that it would actually increase performance. And it would probably make the ATI drivers leak memory twice as fast!

On top of that, anything you'd put in an SLI configuration can run MX Sim pretty easily on a single GPU anyway. So it's not a high priority right now.

You might find that running in split frame mode will work well too. You won't get the same geometry processing speedups as in AFR mode, but it will double your fill rate without the alternate frame rendering issues.