Upvote Upvoted 6 Downvote Downvoted
Working Multicore Rendering on Source
1
#1
0 Frags +

Apparently a working version of multicore rendering got added to Garrys Mod in an update back in July:
(http://steamcommunity.com/games/garrysmod/announcements/detail/877456033724316107)

Since Gmod and TF2 are running on the same engine, could this mean possible improvements for TF2 as well? (In case the TF2 devs implemented it of course)
Players reported major performance increases and afaik TF2 is equally, if not even more bottlenecked by poor CPU utilization than Gmod.

Edit: creating threads on mobile sucks

Apparently a working version of multicore rendering got added to Garrys Mod in an update back in July:
(http://steamcommunity.com/games/garrysmod/announcements/detail/877456033724316107)

Since Gmod and TF2 are running on the same engine, could this mean possible improvements for TF2 as well? (In case the TF2 devs implemented it of course)
Players reported major performance increases and afaik TF2 is equally, if not even more bottlenecked by poor CPU utilization than Gmod.

Edit: creating threads on mobile sucks
2
#2
5 Frags +

x

x
3
#3
6 Frags +
FireIsnt multicore Rendering a thing already ? (mat_queue_mode)

Yes, but just like it used to in GMOD, it does barely anything. Correct me if I'm wrong but as far as I know pretty much everything is done on 1 core and the other cores aren't really utilized very much. That is also the reason why getting a higher core clock makes a bigger fps impact than buying let's say a hyperthreaded i7 to play TF2.

If this is the case, proper multicore utilization would yield quite significant performance increases for almost everyone.

[quote=Fire]Isnt multicore Rendering a thing already ? (mat_queue_mode)[/quote]

Yes, but just like it used to in GMOD, it does barely anything. Correct me if I'm wrong but as far as I know pretty much everything is done on 1 core and the other cores aren't really utilized very much. That is also the reason why getting a higher core clock makes a bigger fps impact than buying let's say a hyperthreaded i7 to play TF2.

If this is the case, proper multicore utilization would yield quite significant performance increases for almost everyone.
4
#4
10 Frags +

1. I'm not sure if TF2 and Gmod are even on the same Source Branch right now. TF2 is now 2013 MP iirc.
2. Valve would definitely not implement it in TF2.
3. This is not something new. This is exactly the same Source multithreading TF2 already uses. It was disabled in Gmod until now because it caused crashes.

tl;dr
We already got this years ago. Spoiler: It's shit.

1. I'm not sure if TF2 and Gmod are even on the same Source Branch right now. TF2 is now 2013 MP iirc.
2. Valve would definitely not implement it in TF2.
3. This is not something new. This is exactly the same Source multithreading TF2 already uses. It was disabled in Gmod until now because it caused crashes.

tl;dr
We already got this years ago. Spoiler: It's shit.
5
#5
-3 Frags +

Are you sure TF2 is running on 2013 Source?

Are you sure TF2 is running on 2013 Source?
6
#6
17 Frags +

thank mr setsul

thank mr setsul
7
#7
2 Frags +

I don't know why everyone hates on muticore rendering so much.

TF2 still is limited by single threaded performance with it enabled, but this makes sense seeing as the core logic of game engines are largely sequential in nature.

However, multicore rendering offloads enough processing from the main engine to bring a notable boost to FPS. And, since they resolved the crashing issues that used to occur there's no reason not to use it these days.

I don't know why everyone hates on muticore rendering so much.

TF2 still is limited by single threaded performance with it enabled, but this makes sense seeing as the core logic of game engines are largely sequential in nature.

However, multicore rendering offloads enough processing from the main engine to bring a notable boost to FPS. And, since they resolved the crashing issues that used to occur there's no reason not to use it these days.
8
#8
4 Frags +
Setsul1. I'm not sure if TF2 and Gmod are even on the same Source Branch right now. TF2 is now 2013 MP iirc.
2. Valve would definitely not implement it in TF2.
3. This is not something new. This is exactly the same Source multithreading TF2 already uses. It was disabled in Gmod until now because it caused crashes.

tl;dr
We already got this years ago. Spoiler: It's shit.

I don't understand your contradictory statements, 2 says it defenitely won't be implemented and 3 says we already have it.
I have to disagree with 3 because we do most likely NOT have the same implementation for the TF2 Source engine, we (presumably) have the one that Gmod used to have prior to the afformentioned July update.

Regarding the different Source Branches, would it be that hard to move to a different branch if that is needed for multicore rendering to be implemented in a semi effective way?
And why would Valve defenitely not do it?

The point of my post was not to try and announce this as a new technology, but rather show that a game built on the same engine and of somewhat comparable age managed to get a proper implementation of multicore rendering that significantly improved performance.
I was just wondering how big the improvement one could expect and how likely/hard an official implementation for TF2 would be.

[quote=Setsul]1. I'm not sure if TF2 and Gmod are even on the same Source Branch right now. TF2 is now 2013 MP iirc.
2. Valve would definitely not implement it in TF2.
3. This is not something new. This is exactly the same Source multithreading TF2 already uses. It was disabled in Gmod until now because it caused crashes.

tl;dr
We already got this years ago. Spoiler: It's shit.[/quote]

I don't understand your contradictory statements, 2 says it defenitely won't be implemented and 3 says we already have it.
I have to disagree with 3 because we do most likely NOT have the same implementation for the TF2 Source engine, we (presumably) have the one that Gmod used to have prior to the afformentioned July update.

Regarding the different Source Branches, would it be that hard to move to a different branch if that is needed for multicore rendering to be implemented in a semi effective way?
And why would Valve defenitely not do it?

The point of my post was not to try and announce this as a new technology, but rather show that a game built on the same engine and of somewhat comparable age managed to get a proper implementation of multicore rendering that significantly improved performance.
I was just wondering how big the improvement one could expect and how likely/hard an official implementation for TF2 would be.
9
#9
0 Frags +

@ #8

G-mod and TF2 have, for a long time (like since 2010-ish), had a "technically multi-core support" feature. In g-mod it caused crashes so they disabled it, but now they've re-enabled it (and presumably fixed the crash).

However, this "multi-core support" takes like 2% of the workload (iirc the sound stuff?) and puts it in a second thread, but the bulk of the work is still done on 1 core. Mr Setsul is saying that valve are not, for the foreseeable future, going to bother spreading the rest (or even some) of that workload onto the other cores.

Edit: TL:DR "multicore support" https://imgur.com/gallery/EEdKeXN

@ #8

G-mod and TF2 have, for a long time (like since 2010-ish), had a "technically multi-core support" feature. In g-mod it caused crashes so they disabled it, but now they've re-enabled it (and presumably fixed the crash).

However, this "multi-core support" takes like 2% of the workload (iirc the sound stuff?) and puts it in a second thread, but the bulk of the work is still done on 1 core. Mr Setsul is saying that valve are not, for the foreseeable future, going to bother spreading the rest (or even some) of that workload onto the other cores.

Edit: TL:DR "multicore support" https://imgur.com/gallery/EEdKeXN
10
#10
0 Frags +
Smyther@ #8

G-mod and TF2 have, for a long time (like since 2010-ish), had a "technically multi-core support" feature. In g-mod it caused crashes so they disabled it, but now they've re-enabled it (and presumably fixed the crash).

However, this "multi-core support" takes like 2% of the workload (iirc the sound stuff?) and puts it in a second thread, but the bulk of the work is still done on 1 core. Mr Setsul is saying that valve are not, for the foreseeable future, going to bother spreading the rest (or even some) of that workload onto the other cores.

Edit: TL:DR "multicore support" https://imgur.com/gallery/EEdKeXN

From what I've gathered those 2% must be able to make a pretty hefty difference then. By browsing a few forums I came across posts describing 100% improvement and above (those may obviously cherrypicked, but still) in certain situations.

[quote=Smyther]@ #8

G-mod and TF2 have, for a long time (like since 2010-ish), had a "technically multi-core support" feature. In g-mod it caused crashes so they disabled it, but now they've re-enabled it (and presumably fixed the crash).

However, this "multi-core support" takes like 2% of the workload (iirc the sound stuff?) and puts it in a second thread, but the bulk of the work is still done on 1 core. Mr Setsul is saying that valve are not, for the foreseeable future, going to bother spreading the rest (or even some) of that workload onto the other cores.

Edit: TL:DR "multicore support" https://imgur.com/gallery/EEdKeXN[/quote]

From what I've gathered those 2% must be able to make a pretty hefty difference then. By browsing a few forums I came across posts describing 100% improvement and above (those may obviously cherrypicked, but still) in certain situations.
11
#11
-1 Frags +

Pulled the 2% figure out my arse btw. However much it actually helps, it's not actual, proper multi-core support. That would involve taking many of the sequential jobs that are involved in processing a game engine tick and running some of them in parallel. Shoving the separate, after-thought audio stuff hardly counts.

Pulled the 2% figure out my arse btw. However much it actually helps, it's not actual, proper multi-core support. That would involve taking many of the sequential jobs that are involved in processing a game engine tick and running some of them in parallel. Shoving the separate, after-thought audio stuff hardly counts.
12
#12
-1 Frags +

Ahh, Ok, thanks for the clarification. Well, guess this is one of the things we could defenitely use but won't ever get. Case closed

Ahh, Ok, thanks for the clarification. Well, guess this is one of the things we could defenitely use but won't ever get. Case closed
13
#13
0 Frags +

#5
Valve Dev Wiki says so.

#8

AsecI have to disagree with 3 because we do most likely NOT have the same implementation for the TF2 Source engine, we (presumably) have the one that Gmod used to have prior to the afformentioned July update.

That was my point for 1.

The way that Source handles multithreading hasn't changed in the different branches. It's still the same old queued multithreading (mat_queue_mode 2).

2 doesn't contradict anything. Even if someone implemented the holy grail of multithreading in Gmod Valve would not port it. It's just way too much work. Task based threading is already implemented (and not doing much) and you can't just slap data based threading onto completely different data and hope the locks still work. They won't.

Like I said, this is the same multithreading that gets you about 35% in TF2 because all the new particle effects etc were dumped in the main thread iirc.

The main problem is that Source 2 was supposed to and should solve that problem by having better multithreading and semi-automated porting, but has been delayed for so many years.

#11
It already does that, but most jobs depend on each other so you can't run them out of order. That leads to the problem that it can easily utilize 8 threads at the same time but most jobs are so benign that they are finished almost instantly and we're back to 2 threads. It's about 70% in the main thread, 25% for the 2nd thread (mostly rendering) and <5% for everything else.

Iirc Source doesn't even support locks so that (a lot of work, not much improvement) is not even an option but while their preferred approach of lock-free algorithms (shit ton of work, more improvement) is more or less delayed until Source 2.

You know things like cl_threaded_bone_setup? They've caused crashes for years because that shit is really that complicated.

Could they improve it? Absolutely. But even I would rather see that work go into Source 2 than improve an engine they want to get rid of because it's such a pain in the ass. It's not like Valve has an infinite number of programmers available. If it was your choice would you rather improve Multithreading in Source 1 or Source 2?

#5
Valve Dev Wiki says so.

#8
[quote=Asec]
I have to disagree with 3 because we do most likely NOT have the same implementation for the TF2 Source engine, we (presumably) have the one that Gmod used to have prior to the afformentioned July update.[/quote]
That was my point for 1.

The way that Source handles multithreading hasn't changed in the different branches. It's still the same old queued multithreading (mat_queue_mode 2).

2 doesn't contradict anything. Even if someone implemented the holy grail of multithreading in Gmod Valve would not port it. It's just way too much work. Task based threading is already implemented (and not doing much) and you can't just slap data based threading onto completely different data and hope the locks still work. They won't.

Like I said, this is the same multithreading that gets you about 35% in TF2 because all the new particle effects etc were dumped in the main thread iirc.

The main problem is that Source 2 was supposed to and should solve that problem by having better multithreading and semi-automated porting, but has been delayed for so many years.

#11
It already does that, but most jobs depend on each other so you can't run them out of order. That leads to the problem that it can easily utilize 8 threads at the same time but most jobs are so benign that they are finished almost instantly and we're back to 2 threads. It's about 70% in the main thread, 25% for the 2nd thread (mostly rendering) and <5% for everything else.

Iirc Source doesn't even support locks so that (a lot of work, not much improvement) is not even an option but while their preferred approach of lock-free algorithms (shit ton of work, more improvement) is more or less delayed until Source 2.

You know things like cl_threaded_bone_setup? They've caused crashes for years because that shit is really that complicated.

Could they improve it? Absolutely. But even I would rather see that work go into Source 2 than improve an engine they want to get rid of because it's such a pain in the ass. It's not like Valve has an infinite number of programmers available. If it was your choice would you rather improve Multithreading in Source 1 or Source 2?
14
#14
-3 Frags +

Oh alright. I heard CS:GO is running 2013 Source too, is this true? Given TF2 and CS:GO run on different versions of Source. Can't find anything on it.

Oh alright. I heard CS:GO is running 2013 Source too, is this true? Given TF2 and CS:GO run on different versions of Source. Can't find anything on it.
15
#15
1 Frags +

CS:S is on the same branch as TF2.
CS:GO is on the Portal 2 branch iirc, but definitely a different branch than TF2.

CS:S is on the same branch as TF2.
CS:GO is on the Portal 2 branch iirc, but definitely a different branch than TF2.
16
#16
-3 Frags +

I am actually wondering what's going on with the Source 2 Engine, haven't heard anything about it for a while. Last thing I remember was them focusing on moddability and VR..

I am actually wondering what's going on with the Source 2 Engine, haven't heard anything about it for a while. Last thing I remember was them focusing on moddability and VR..
17
#17
0 Frags +

Got stuck in Valve Time, Dota 2 got ported, DX12 and Vulkan happened and since Valve wants to use Source 2 it's back to the drawing board and stuck in Valve Time again.

Got stuck in Valve Time, Dota 2 got ported, DX12 and Vulkan happened and since Valve wants to use Source 2 it's back to the drawing board and stuck in Valve Time again.
18
#18
-1 Frags +

Dare I dream for 4 cores being used?

Dare I dream for 4 cores being used?
19
#19
0 Frags +

The only game currently using Source 2 is Dota 2, which got it in a beta update late last year and it was made the default branch earlier this year.

The only full game in the foreseeable future that might use Source 2 is Titanfall 2, which we know uses a variant of Source that their developers have highly customized. It's not currently known if that version uses Source 2 or Source 2013 as a base, though. The original Titanfall used Source 2013.

The only game currently using Source 2 is Dota 2, which got it in a beta update late last year and it was made the default branch earlier this year.

The only full game in the foreseeable future that [i]might[/i] use Source 2 is Titanfall 2, which we know uses a variant of Source that their developers have highly customized. It's not currently known if that version uses Source 2 or Source 2013 as a base, though. The original Titanfall used Source 2013.
20
#20
0 Frags +

wait can you bhop and airstrafe to gain speed in titanfall

wait can you bhop and airstrafe to gain speed in titanfall
21
#21
1 Frags +
fade-wait can you bhop and airstrafe to gain speed in titanfall

no

[quote=fade-]wait can you bhop and airstrafe to gain speed in titanfall[/quote]
no
22
#22
0 Frags +
fade-wait can you bhop and airstrafe to gain speed in titanfall

no they have overwatch's "press shift to move in an advanced way" style of movement

[quote=fade-]wait can you bhop and airstrafe to gain speed in titanfall[/quote]

no they have overwatch's "press shift to move in an advanced way" style of movement
23
#23
1 Frags +

what is actually different in Source 2?

what is actually different in Source 2?
24
#24
-2 Frags +

I have an 8 thread CPU

Tf2 uses 100% of one thread
30% of another and 10% of a third.

Very bad "multi core". Best would be 100% on all threads.

I have an 8 thread CPU

Tf2 uses 100% of one thread
30% of another and 10% of a third.

Very bad "multi core". Best would be 100% on all threads.
25
#25
0 Frags +

x

x
26
#26
0 Frags +
SetsulGot stuck in Valve Time, Dota 2 got ported, DX12 and Vulkan happened and since Valve wants to use Source 2 it's back to the drawing board and stuck in Valve Time again.

They have been adding some pieces here and there, most notably panorama and recently datagram support in CS:GO. It's been painfully slow as a player, but there's been a few bits here and there that break Valve's radio silence

[quote=Setsul]Got stuck in Valve Time, Dota 2 got ported, DX12 and Vulkan happened and since Valve wants to use Source 2 it's back to the drawing board and stuck in Valve Time again.[/quote]

They have been adding some pieces here and there, most notably [url=https://steamdb.info/forum/1131/counter-strike-global-offensive-update-for-72716-72816-utc-13543/]panorama[/url] and recently [url=https://www.reddit.com/r/GlobalOffensive/comments/580lxa/steam_datagram_relay_beta/]datagram[/url] support in CS:GO. It's been painfully slow as a player, but there's been a few bits here and there that break Valve's radio silence
27
#27
-1 Frags +

I think they recently added datagram support to TF2.

I think they recently added datagram support to TF2.
Please sign in through STEAM to post a comment.