How many threads does pcsx2 use? or can use?
#1
Im curious on how many threads pcsx2 uses and how many it can use.

So by default, it uses what, 2 threads?
When you enable MTVU, does it use 3 threads or 4? or dependent on your cpu?

im trying to figure out exactly how many threads it uses with that, to try and figure out how many extra software rendering threads are possible.

as if you have 4 threads, and you are using 4, you arnt really going to be able to use any more for software rendering.

Now on that subject, is there a limit to how many extra threads you can use for software rendering?
what about the case of like 12 threaded cpus like the i7-3960? could you use something like 8 rendering threads for software rendering lol?
Reply

Sponsored links

#2
(04-22-2013, 08:25 PM)filenotfound Wrote: Im curious on how many threads pcsx2 uses and how many it can use.

So by default, it uses what, 2 threads?
When you enable MTVU, does it use 3 threads or 4? or dependent on your cpu?

im trying to figure out exactly how many threads it uses with that, to try and figure out how many extra software rendering threads are possible.

as if you have 4 threads, and you are using 4, you arnt really going to be able to use any more for software rendering.

Now on that subject, is there a limit to how many extra threads you can use for software rendering?
what about the case of like 12 threaded cpus like the i7-3960? could you use something like 8 rendering threads for software rendering lol?
Remember, the number of threads in this case means the number of threads the application can open and keep synced. The OS can open dozens of them. Of course "active" at same time depend on the number of available cores.

Think it as a complex traffic system with semaphores controlling the whole mess (and you'll not be wrong). That's possible because a thread is not always doing something actively, it may be waiting response of some other device (like the controller or keyboard, the disk...) and then another thread becomes active meanwhile and the cycle repeats.

Normally a module or process will try and avoid opening more threads than the amount of physical cores and most of times not even that much.

One good example to understand this is looking to the ini tweaks for Bethesda games, once hosted by the tweakguides.com site.

On Oblivion game is advised to increase the havoc to 9 threads, to actually activate threaded processing for several other parameters in the game and to include a line limiting the number of actual "hardware" threads to the amount of cores in your CPU.

That's no all, Fallout 3, despite being newer than Oblivion (yet using the same engine slightly modified), was found you should limit the hardware threads to 2 cores max, despite the number of them in the CPU.

That's tell us it's not just defining the number of threads the application can open, it must be able to keep them under control or things go astray. And PS2 architecture is not the tree model common on most nowadays software (and then good for multithreading) but pipelined what is bad for threaded processing.

Resuming, you can still define a reasonable number of threads for GSDX software mode and yet activate MTVU having some gain in performance.

The other side of that coin is not all programs react equal to this and in the specific case some games will take greater advantage of MTVU while another game may just crash it.

Sorry, already too long post, I hope the main idea was passed.
Imagination is where we are truly real
Reply
#3
(04-22-2013, 08:50 PM)nosisab Ken Keleh Wrote: Remember, the number of threads in this case means the number of threads the application can open and keep synced. The OS can open dozens of them. Of course "active" at same time depend on the number of available cores.

Think it as a complex traffic system with semaphores controlling the whole mess (and you'll not be wrong). That's possible because a thread is not always doing something actively, it may be waiting response of some other device (like the controller or keyboard, the disk...) and then another thread becomes active meanwhile and the cycle repeats.

Normally a module or process will try and avoid opening more threads than the amount of physical cores and most of times not even that much.

One good example to understand this is looking to the ini tweaks for Bethesda games, once hosted by the tweakguides.com site.

On Oblivion game is advised to increase the havoc to 9 threads, to actually activate threaded processing for several other parameters in the game and to include a line limiting the number of actual "hardware" threads to the amount of cores in your CPU.

That's no all, Fallout 3, despite being newer than Oblivion (yet using the same engine slightly modified), was found you should limit the hardware threads to 2 cores max, despite the number of them in the CPU.

That's tell us it's not just defining the number of threads the application can open, it must be able to keep them under control or things go astray. And PS2 architecture is not the tree model common on most nowadays software (and then good for multithreading) but pipelined what is bad for threaded processing.

Resuming, you can still define a reasonable number of threads for GSDX software mode and yet activate MTVU having some gain in performance.

The other side of that coin is not all programs react equal to this and in the specific case some games will take greater advantage of MTVU while another game may just crash it.

Sorry, already too long post, I hope the main idea was passed.

Well ti does make sense, as i do somewhat understand cpu threading. Just never really became a thought that, ya threads arnt always active 100% of the time.

and ya when running in parallel, things can get out of sync, since they are unable to communicate with each other, so the more the threads would have to communicate data between themselves it thus further limits the number of parallel threads able to be used.


I was more or less wondering, how many threads on average are able to be run in parallel in pcsx2?
Like will most all games work with 1-2 extra rendering threads? ofcourse maybe not all would, but would using say 1-2 on average be the best?
Reply
#4
That's only if using software mode, in hardware mode the GPU will be doing the bulk of work and if it is strong enough you could even try (and should do in this case) upscale till 4x depending on the card. in a way it's easier to newer cards to deal with resolutions near their optimal points than very low or very high figures.

At MTVU side you just enable or disable it, the module itself will try what if finds available, it's not related with software mode number of treads.

As general rule, if using software mode try the number of cores minus 1 (or maybe two depending on what else is running on the machine. That's to grant GSDX will not try to allocate resources from at least one coee to be used primarily by EE+VUs.

In software mode GS becomes a greater resource rogue, as to say, but should not be forgotten that much of PS2 graphics processing (and post processing) is done at VU level.

In time: where is stated PS2 is meant PS2 indeed, not to be confused with the emulation of it by PCSX2.

PS: Important, due to flaw in it's architecture Buldozer CPUs may not fare well with MTVU, maybe having the performance harmed more than helped. That's due a problem when 2 cores under the same module (in the CPU) works. This problem was addressed but I'm not sure if totally fixed on Piledriver. Intel CPUs on the other side seems specially happy with MTVU.

The advice is trying and observing if any speedhack is helping, if it is not doing it in a perceivable way, better having it reduced or disabled.
Imagination is where we are truly real
Reply
#5
Extra rendering threads seems to be optimal at 3 for a quad core or above. If you have mtvu enabled, pcsx2 will use 3 cores with 1 being gsdx (which will split in to more when using extra rendering threads)
[Image: ref-sig-anim.gif]

Reply
#6
(04-22-2013, 11:09 PM)refraction Wrote: Extra rendering threads seems to be optimal at 3 for a quad core or above. If you have mtvu enabled, pcsx2 will use 3 cores with 1 being gsdx (which will split in to more when using extra rendering threads)

I'll keep in mind that empiric statistic about the optimal number of rendering threads in the future, thanks, refraction.

Edit: complementing previous post. Another way to look at the poor MTVU performance on Bulldozer being due the cores are actually only for integer operations, sharing the module's float point mechanism, and since almost all VU processing is done with vectors (uhhh), that architecture exposes the weakness in this case.
Imagination is where we are truly real
Reply
#7
Nps Smile I can't 100% confirm that, but Gabest said he tested it and around 2-4 seemed to be optimal (said you should use your number of cores - 1 really) and trying higher numbers actually resulted in degraded performance.
[Image: ref-sig-anim.gif]

Reply
#8
(04-22-2013, 11:20 PM)nosisab Ken Keleh Wrote: I'll keep in mind that empiric statistic about the optimal number of rendering threads in the future, thanks, refraction.

Edit: complementing previous post. Another way to look at the poor MTVU performance on Bulldozer being due the cores are actually only for integer operations, sharing the module's float point mechanism, and since almost all VU processing is done with vectors (uhhh), that architecture exposes the weakness in this case.

I never saw any performance loss with the MTVU active neither with the FX-6100 or with the FX-6300, maybe it happen with models with 2 or 1 modules, but I'd not say that it always happens.

(04-22-2013, 11:23 PM)refraction Wrote: Nps Smile I can't 100% confirm that, but Gabest said he tested it and around 2-4 seemed to be optimal (said you should use your number of cores - 1 really) and trying higher numbers actually resulted in degraded performance.

I made some test with Baldur's Gate II and Champions of Norrath and using 4 or more thread gave lower FPS than 3 despite having at least another unused core.
Ryzen 7 3800X | Noctua NH-D14| Gigabyte X570 Aorus Pro| RX Vega 64| 2*8GB Patriot Viper 3733MHz C17@3733MHz C16| Samsung 840EVO 250GB + 970EVO 512GB NVMe| 4TB Hard Drive| Samsung C25FG7 + Samsung S24D300 + Samsung S24F250| NZXT Phantom 410| Enermax Revo'Xt 730W| Gigabyte M6900
Reply
#9
(04-23-2013, 12:03 AM)||dav1de|| Wrote: I never saw any performance loss with the MTVU active neither with the FX-6100 or with the FX-6300, maybe it happen with models with 2 or 1 modules, but I'd not say that it always happens.


I made some test with Baldur's Gate II and Champions of Norrath and using 4 or more thread gave lower FPS than 3 despite having at least another unused core.

You may be right, I can grant that happens only with my own system and only with the games I tried (I don't have many). and in this case is the FX-8150 which theoretically should get a huge improvement with MTVU.
Imagination is where we are truly real
Reply
#10
(04-23-2013, 12:12 AM)nosisab Ken Keleh Wrote: You may be right, I can grant that happens only with my own system and only with the games I tried (I don't have many). and in this case is the FX-8150 which theoretically should get a huge improvement with MTVU.

I see that your FX is at default frequency with turbo enabled, thus using another core may force the CPU to work at a lower frequency and thus a small or even zero performance gain that the MTVU should give you in the specific situation becomes an overall decrease in performances due to the frequency.
The highest turbo for example works when 2 modules are idled, if you use 3 cores of 3 different modules...no more max turbo! If the 3rd core is in a module where there is the EE or the GS you may have performance losses due to the MTVU stealing resources to one of the other two threads.
Ryzen 7 3800X | Noctua NH-D14| Gigabyte X570 Aorus Pro| RX Vega 64| 2*8GB Patriot Viper 3733MHz C17@3733MHz C16| Samsung 840EVO 250GB + 970EVO 512GB NVMe| 4TB Hard Drive| Samsung C25FG7 + Samsung S24D300 + Samsung S24F250| NZXT Phantom 410| Enermax Revo'Xt 730W| Gigabyte M6900
Reply




Users browsing this thread: 1 Guest(s)