Extreme Physics Lag in Portal 2 explained (a "multicore rendering" bug!)

[RoutedScripter]

[NOTE: My posts always begin with only "half-idea" at start and i get better findings when you read down to the end so ... i don't really do all the stuff and then type it, it's all "live, as it goes" ... that's my exp. in which case i know im correct , if i found myself to be incorrect while typing the last sentence of a wall of text, then i wouldn't even post this thread]

The internet already found this is a common problem:

They called it:
Problem #21 - Portal 2 Lag Physics Blob Fix

Possible Solution: Set r_threaded_blobulator 0 using console.



Well so it's a common thing, not surprising me.

I was going to post this just secs ago before i found more info:

Portal 2 has extreme fluid physics lag when MULTICORE RENDERING option in Advanced Video is enabled on an single-GPU-Core system (Physics supposed to be still CPU, and i have a Intel Quad Q9300 3.0mhz, it's confusing why the option is in video settings, it doesn't really show what exactly is being done/used)

Looks like the command here disables only the buggy fluid physics and the rest is still multi-thread enabled, im not sure on this yet , nobody made it clear if that's really the whole option or just a part of many commands that the "Multicore Rendering" sets.

Ah "rendering" part should signal that this is a GPU option , but still , this is a BUG and im glad it's been booked as. Because GPU has nothing to do with physics unless it configred that way or you have PhysX.

The sense of it is also to LAG less , but this is clearly counterproductive from what i see , the lag is so immense it makes the sound pop , ... are you thinking what im thinking , exactly it's the CPU bottlenecking so hard, so it's definitely not "multicore rendering" alone , it's chaning other commands too which have nothing to do with rendering. (the command has "threaded" which is (not yet) deifintely not GPU-centric stuff ... in term of distinguishing task operations)

And if i used the simple program maybe i can catch and probably record what happens to CPU / GPU when this is on. [will do this later, not in this post yet]

http://forums.steampowered.com/forums/showthread.php?p=22161321&posted=1#post22161321

http://gamecrashfixed.com/2011/04/f...uncher-spinning-bug-steam-cloud-save-problem/



BUT:
Nobody has yet talked/linked about multicore rendering to be the cause of the Portal 2 lag-bug. [only 3 things currently,

EDIT:
Apparently it has, but surprisingly it's not about Portal 2, it goes farther back to ... Left 4 Dead and Team Fortress 2.





Yeah, turning off multi-core rendering fixed everything for me, you should try. With it enabled, both cores would launch to 100% and the game would freeze for 5-10 seconds at a time, every 10 seconds or so. It was terrible. Now the game runs perfect maxed, at about 50% load.

AMD Athlon X2 6400+
GeForce 8800GTS 640MB
4GB Corsair XMS2 DDR2 800MHZ[/QUOTE]

Source:
http://www.gamespot.com/pc/action/left4dead/show_msgs.php?pid=937406&topic_id=m-1-47839801





-------------------------------------------------------------------------
Now i screenshoted this:

After ... all

See TEH grandz confuzionz! [EDIT: ]

We should be like:

Let's find out what this screenshot really means.

Back to square one ... the label about "rendering" is surely misleading , it is what is supposed to be.

Back to square none? There's also a chance that CPUs label is wrong and it should be saying GPUs ... we can only guess at this , it's really weird.


Not to say square, but back to the original assumption , it cannot be called "rendering" if it's about CPU, but if it's about GPU, it cannot (should not) influence CPU-bound technical options of the game.



What we can gather(okay speculation ) : - Valve developed portal 2 with a second or third team that is a bit nooby
-multi-platform games get much less attention to detail

They're so lazy they didn't even fixed this from L4D ... and this Portal2 engine isn't exactly anything special at all.

Plus im a bit disatisified with the game, textures are a bit lame for 2011 , i still can't ... see what it's written on, the little detail text on walls and equipment , this is so annoying to see a blured out text.






-------------------------------------------------------------------
This adds more questions than answers, example of similar feature in another game:

Team Fortress 2 Update Adds Multicore Rendering
Mar 18, 2009

When it works properly, Multicore Rendering accelerates your framerate by rendering with multiple cores... simultaneously!

Added Multicore Rendering:

# This initial release is aimed at testing compatibility, so the option is OFF by default
# To turn it on, go to the Options->Video->Advanced dialog, and check the "Multicore Rendering" option

Thanks for nothing

When does it work properly ? What it takes for it to work properly ? Valve didn't say anything about it (or we didn't notice), and certainly Valve didn't warned us about experimental status either.



---------------------------------------------------------------------
More: It doesn't add any big answers , certainly not here:

Multicore Rendering accelerates your framerate by rendering with multiple cores... simultaneously!

This ^(upper itallic text)^ is total and utter nonsene. (ofcourse VE3D = IGN , what else to expect )

-CPU can only accelerate framerate by better physics calculations and overall speed/tech/instructions/using-more-cores , lifting it's bottleneck for the GPU to perform better , if GPU is already maxed out , this won't help framerate at all.**certain circumstances

-"rendering with multiple cores" -> knowingly talking about CPUs , this has to be most ignorant and shittiest statement ever. CPUs don't render anything.

-"simultaneously!" > this tells you solidly they're talking about CPU in mind (makes sense, it's the central talk about CPU cores and games using more cores) , but using a TERM and EXPLANATION from GPUs, they apparently don't have a clue and just reported about it, so i won't blame IGN again, but that's some pretty crappy explanations from valve in the first place.

It's all about CPUs , what's this option even doing in video settings, Dual-Core GPUs are not mainstream(totally not the center of "MULTITHREADING / MULTICORE" terms and talks yet) and totally not apparently in need of any software support as CPUs (GPU driver controls how a multicore gpu will perform, what games and programs do is simply to apply more code to make it work even better, but it's definitely not "using only one GPU core" as it's the case with CPUs) In other words , multi-core GPUs already do it "simultaneously!" , but all depends on GPU driver.


It's not about SLI or Crossfire either, again, it's all GPU driver bound, ATI releases game profiles for each games for them to perform better/at all on such configurations. That's no-brainer, but just to clear out any doubts by newcomers/newbies/whoever.


Basically, if companies can't supply correct information because they give this job to some stupid guy there or what, but the journalism has no clue either, being (unjustifiably) criticized all the time (those that don't know the truth) George broussard from 3DR said once: "...piss poor gaming journalism..." ... he's still correct to this day.


-----------------------------------Conclusion:


The clue is, there's no other posts on the web about "portal 2 connecting with multicore-rendering producing extreme lag"

but i found one last bit which is ... only to further explain a few things.

It's a guy with an iMac, but he can't disable multicore-rendering he's claiming it's causing him a lot of lag.



A reply:

Your iMac has an Intel Core 2 Duo, meaning it has two cores. It isn't possible to get a decrease in performance, as your computer is dividing the workload in half. You may be gaining frames due to external factors.

-That's the theory, it is impossible to claim that in practise (check mate )


Another one:

The only reason to disable multicore is to improve stability...

Multicore has been proven to improve frame-rates substantially, especially when it was introduced in TF2.

The first part is -> that's really rough, only in certain circumstances, if your CPU is crappy or you have crappy settings definitely but not in optimal conditions, althought apparently sometimes(manytimes) it can be used to fix huge stuttering and frame drop

The second part is not in my area of knowledge.




This iMac guy who is the OP is apparently correct (surprise surprise)

Ehm, I know, that i have a Dual-Core Processor.
But the fact is, that i've tested numerous Source Games such as Half Life 2, Portal, TF 2 and Left 4 Dead with and without Multicore Rendering. And the Games were slower with Multicore Rendering enabled. I believe, that MR is still a bit buggy, but IDK. All I can say is, that it swallows FPS.

-That's why this is booked as a bug (which makes lag), it's not doing what it should.
It's definitely not a problem with PC or anything "external" or whatever else.


Now rbarris from Valve team posted this:

You're welcome to experiment; "multi core rendering" on the Mac client just engages the Apple multi threaded driver without too much new code executing on the game engine side. It's a little different from the MCR mode on the Windows client.

In all of it , it's true, but it's a funny excuse, it doesn't work on windows either.

Yet that was not Portal 2, but still, it ain't worken before it doesn't now.


Source:
http://forums.steampowered.com/forums/showthread.php?t=1283479


------------------------------------------------------------
This just more confirms that this option is severely bugged, "stuttering" is most popularly CPU lag (also HDD/pagefile lag, but not in this case) , so basically CPU is reaching bottleneck ... framerate drop/rise violently, temp-freezes(kind of lines can be seen on screen, but no corruption or gfx errors) , sound pops ...

http://www.gamespot.com/forums/topic/26869192





Basic Inexperienced Thread ---
http://forums.heroesofnewerth.com/showthread.php?t=250129
Talks how"multicore rendering would enable better experience for low GPUs" - IF something, all you would get is framerate, so it's performance thing not "better [visual..etc] experience", and on a bad GPU doesn't make a whole lot of a change at all, ... good GPUS already push it over 100, once you're over 100 ... at least me, don't care about FPS anymore.

Would you say people are stupid? No it's not their fault

There's a lot of confusion going around.

It's valves fault, "Multicore Rendering" is a misleading term.

 

[RoutedScripter]

Can you please enable topic title editing mods ... (like a limit of 2 times ... or within 1 day since posted).

EDIT:

Can you please enable topic title editing mods ... (like a limit of 2 times ... or within 1 day since posted).

Apparently now it worked , it didn't a week ago ... or is it really some 15 minute limit ?

 

[cadaveca]

or is it really some 15 minute limit

Seems that way.

As to the wall of text, I suggest you do some research into game engines and how graphics are drawn, and the multicore rendering option will make sense.

Here is comes again:


DEFFERED RENDERING.

http://blogs.unity3d.com/2010/09/09/unity-3-feature-preview-deferred-rendering/

http://research.scea.com/ps3_deferred_shading.pdf

the term "MULTICORE RENDERING" is NOT misleading, at all.

 

[theJesus]

I skimmed about half of the OP and now I'm somewhat confused by the wall of text. What exactly are you getting at? Just that the multicore rendering option can cause physics-related lag?

 

[Jstn7477]

Multicore rendering actually offers benefits in Team Fortress 2 (which uses a ton of CPU even today, and you pretty much need an i7 or a fast 4-6 core AMD with a 5770 or greater to maintain 60+ FPS with decent settings). I don't really see the usefulness of it in Portal 2 unless you have a slow-clocked multi-core processor.

The Source engine really needs a successor, because DX9 wasn't designed for multithreading and stuff like that.

 

[RoutedScripter]

It's a more broader explanation, but im still on the same findings as before, it's about using more CPU cores for additional processing, either the game or only using additional cores for physics calculation like it should be doing. They definitely not assing CPU to do some calculations what should be GPUs job, unless you have PHYSX or another dedicated physic card , then physics will be done by CPU, with the option enabled they're threading(using more cores) the liquid physics and other physics in order to get faster caculations from the CPU that will lift it's bottleneck and hopefully get way for the GPU to get some more FPS, that's the theory everyones talking about, but it's not working in Portal 2 , i am unaware about other valve games.

The option has nothing to do with video or GPU stuff, it only bugs the CPU (yes, the option is broken, do not enable it) and it shouldn't do that, therefore it's currently useless. Im not only saying it's not working , it's actually making huge negative results and that's the reason for this thread, it's not your CPU or system, my freaking Q9300 will be enough for a game like this. Vavle's games aren't really demanding at all, im not sure why everyone's talking about corei7 ... hardware is way infront of software, if they would do proper threading on a quad like mine you wouldn't basically get any better practical experience with core i7. If the option is bugged, it may prove to have same effect on other CPUs as well ,anyone with a core i7 can try that, but then again , it's faster , you won't get as much lag just because of the overhead, but that doesn't mean (the stupid thinking aahh!) it "requires" a good cpu , not a chance , that's an ignorant excuse who would claim that.

Has nothing to do with deferred rendering, that's GPU stuff.

Physics are calculations, they don't "help" render anything other than accuracy of it in game environment.

The command turns off "blobulator" that's definitely a fancy name for a liquid physics engine in the Valves source engine , "threaded" would imply the use of multiple cores, but unfortunately it's bugged so hard, it backfires and makes huge lag.

I have not yet determined which and how many commands are changed when you set multicore rendering options.

 

[EarthDog]

Jesus, what a read......

Render does not always have to mean graphics last I understood it...maybe your myopic view of the definition caused your opinion?

 

[RoutedScripter]

Render is graphics , and CPU doesn't render anything (but it can, with 1-4 FPS, great speed!), Multicore Rendering would therefore stand for "using multiple GPU cores" , since that is totally conflicting with the facts that GPU multicore processing is done in the low level already automatically by GPU driver/firmware ... basicaly the hardware is designed in this way;;; because we found out multiple sources and evidence this option is talking about CPU (screenshot, links) with some common sense like my findings about the lag, CPU bottleneck -> frame drop , sound pop , huge stutter , and the "threaded_blobulator" fix which implies "threaded physics" , we come to the conclusion simple as this: The game always runs in single-core CPU mode, after you enable "multicore rendering" , it enables multiple commands that EITHER: switches the whole game to run with multiple cores , OR assigns only physics operations to second/multiple cores.

The link to the steam forum fix and also on the huge diagnostic list (first 2 links in OP) the OP guy in stream thread says that is still does some stuttering and lag even with the commands disabled, that probably means the whole game is running in multi-core mode, and the physics being the culprit, (implies that the whole game engine is really bad at multicore stuff), this matches perfectly with my findings, physics -> CPU , this is a CPU option, it has nothing to do with video/gfx.

This is all summary , the OP post is more evidence and explanations , which is , with my "super" english skills kind of it is what it is.


EDIT: I have added a note to the start of the OP post, because of the volume of explanations and findings i always do it live so i better explain it in this summary than you could from the OP post since now i fully realize what's going on, that's how i make sure i type/expose everything i think of, help me not to forget things Ofcourse there is some background, half of it, i have to be sure about it before i start and, definitely wouldn't post the thread if i found myself wrong or mistaken.

 

[RoutedScripter]

Now on the steam thread:

r_paintblob_max_number_of_threads
Normally it's 4, you can set it to 1, 2 or 3, and see which your PC can handle without stuttering.

This would be like weird, why would they try to get CPU to help do GPU stuff, ofcourse it's making lag on almost all except enthusiast setups. That would really be only useful if you have a crappy GPU you can't get more than 60 FPS from Portal 2, but come one , i have a HD4870 and i get 150 FPS from Portal 2, and that's more than enough.

So this option is proving to be even more useless. It doesn't really boost anything, it does multiple things , threading the physics but in a sense of MAXIMINZING physics and not actually "using more cores to calculate same level of physics as in single-core mode" , then also, it shifts some GPU stuff to CPU cores, "r_paintblob" "threads" -> that would mean that they're using CPU for rendering?

If that would be threaded(code-wise-threads) on GPU core then, GPU wouldn't cause stuttering and not the huge frame drops/rises , and GPU wouldn't cause sound to pop. So this "r_" > render , and threading , meaning rendering on CPU threads , it makes it TOTALLY stupid design.

The practical common sense, it doesn't do what it should, help the low-end hardware, but now it's just helping high end hardware for ... worthless, who would have a high end CPU with a low-end GPU ? ...

Portal 2 is just a minigame. Multicore Rendering = enable portal2 to use multiple CPU cores to help render the graphics and calculate physics ...

 

[Over_Lord]

unless you have PHYSX or another dedicated physic card , then physics will be done by CPU,

Physx is used only if teh game supports it..

portal 2, correct me if i'm wrong, doesnt.

 

[RoutedScripter]

Multicore Rendering accelerates your framerate by rendering with multiple [CPU] cores..

So i get back to the VE3D @ IGN post, which we claimed to be misleading or misinterpreted , whatever.

In a funny sense this turns out to make sense now, because valve is really doing a STUPID thing, they're using CPU for rendering , as i explained this is impractical for high-ends, and useless for low-ends.

The fact why it doesn't lag normally, is because it doesn't render with CPU in single-core, why can't they just run portal2 in multi-core without helping to render anything.

Good job Valve.

I show my solidarity to the "trolls" that complained about portal 2 , something that i thought i wouldn't, but now that i played the whole game, found this, i can safely say that those guys were just bashed by the media fanboys.

Portal 2 really is a minigame , technologically speaking , and multiplatform code is present in PC version. The design and gameplay is still the top , but the underlayer is bad.

 

[slyfox2151]

it does not support physx. i also very much doubt the CPU is "Rendering" any actual graphics with that option enabled, its likely just using more threads to help send more data to the GPU.... or even just split up the physics more.

 

[RoutedScripter]

it does not support physx. i also very much doubt the CPU is "Rendering" any actual graphics with that option enabled, its likely just using more threads to help send more data to the GPU.... or even just split up the physics more.

Exactly!

Either former or latter or maybe something else similarly.

But , about the "spliting physics to more cores" - it would work faster naturally, but i think they actually maximize the physics calculations too, even if it "multithreades" the intensity helps to decrease performance, but this alone wouldn't cause such a huge lag, agreed.

Guys have to understand, this is some huge lag if even sound starts to pop! On a high end machine

 

[ctrain]

why are you over-complicating this to a comical extent? you wrote a novel on trying to justify it doing what it doesn't do.

it's not perfectly worded, but the threading in source primarily encompasses systems that tie into the renderer, be it particle systems, bone setup, the material system, meta-ball stuff for the fliuds... so on and so forth.

look familar?
http://en.wikipedia.org/wiki/Metaballs

ps: epic words it the same
http://www.unrealengine.com/features/rendering/

 

[EarthDog]

Like I said...

Render does not always have to mean graphics last I understood it...maybe your myopic view of the definition caused your opinion?

 

[C4rnage]

A few people have problem with multi-threading on source, you dont need bash Valve. most of people got huge performace boost when valve put multi threading
and you really doesnt understand what rendering and how games works at all..