Page 1 of 2
Multicore CPU utilization
Posted: Sun Dec 11, 2011 11:23 pm
by 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.
Re: Multicore CPU utilization
Posted: Sun Dec 11, 2011 11:52 pm
by DJD
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 12:05 am
by Pumaxcs
Group video cards into that as well.
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 12:10 am
by jbrandmx85
yea my laptop might actually be able to play mxsim decently with this. haha (:
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 1:24 am
by haydugjr
+1 to this. Until then I just put everything else on three cores and put MXS on the last core.
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 4:00 am
by yzmxer608
I'd like this, I thought jlv said something pretty recent about sli/crossfire but I can't find it now.
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 5:56 am
by 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.
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 11:46 am
by haydugjr
jlv wrote:would only double the speed.
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 10:39 pm
by jbrandmx85
haydugjr wrote:jlv wrote:would only double the speed.
haha i was thinking the same thing...
Re: Multicore CPU utilization
Posted: Mon Dec 12, 2011 11:55 pm
by 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.
Re: Multicore CPU utilization
Posted: Tue Dec 13, 2011 12:37 am
by 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.
Re: Multicore CPU utilization
Posted: Tue Dec 13, 2011 5:31 am
by 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.
Re: Multicore CPU utilization
Posted: Tue Dec 13, 2011 12:07 pm
by socalmx
jlv wrote: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?
Re: Multicore CPU utilization
Posted: Tue Dec 13, 2011 12:55 pm
by 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.
Re: Multicore CPU utilization
Posted: Tue Dec 13, 2011 5:49 pm
by yzmxer608
Found it.
jlv wrote: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.