A feature request: Auto-configured software rendering threads

[gregory]

Honestly, 2 ert is the best for a 2 cores. Thread overhead isn't that important

[ssakash]

If your answer is "Because some people have dual cores or single cores" then that's not good reasoning. You could say the same thing about why 2 is the best choice "Because many people have quad cores or higher"

not really some, according to Steam Hardware survey people with single and dual core processors are near 50% which is about half of the people. http://store.steampowered.com/hwsurvey

on the other hand why I'm suggesting 0 is because at some cases 1+ values produce lower speed compared to 0 which means that they're actually limiting the potential of their processor's ability of getting higher speeds (it's not the same with quad cores/ higher). default value should be fair globally for all the processors.

[ssakash]

wait a sec.. do you guys mean 2 applying this commit (or) without applying it ? if you mean without applying the commit then I agree with this.

[willkuer]

My point was that old:3/new:2 ERT's don't yield strong framedrops on singlecores. If I compare that with dogen's results I think this is justified.
On the other side old:3/new:2 ERT's should yield much better results on quadcores than one thread less.
This is for all applications valid where inter-thread communication or locking is not present or neglectable. That's here indeed the case (as rendering threads don't communicate with each other).

So I would rather chose old:3/new:2 ERT's than old:2/new:1 ERT's.

[ssakash]

oh well, I'm inclining towards the majority anyway. why not just use a detection of cores to set extra rendering threads ?

[willkuer]

There isn't 1 way to do it across platforms, but Windows, Mac, Linux, BSD all have ways to get some number from a terminal emulator/command prompt.
Windows:

Code:

echo %NUMBER_OF_PROCESSORS%

Mac/BSD/Linux: 

Code:

sysctl -n hw.ncpu

GNU/Linux:

Code:

nproc

You do the fancy #ifdef to obtain a number in a way that's dependent on the platform[...]

That the definition of not portable. Honestly auto will be complicated to code, and will never give you a correct settings.[...]

Gregory voted against as there is no general/portable approach to get the number of cores. And from a consumer point of view gsdx (slave) might need to ask pcsx2 (master) how many cores to use and not just decide by itself.

I actually don't care. I just didn't want to change too much code and considered a static compile time constant better.

[willkuer]

It would be good to find a decision which setting is the best. So please try to agree on something.

Open candidates for default ERT's are:
0
2
3

using the old model:
0 ERT mean the main gs thread is doing the rendering
2 ERT means there are 2 threads that render while the main gs thread idles/waits
3 ERT means there are 3 threads that render while the main gs thread idles/waits

Giving you some more analysis on dogen's results.

First plot just shows directly his results:
   

Second plot shows the relative speed loss due to bad settings: (Error calculation is not completely correct)
   


And last but not least the average speedloss per ERT setting due to non optimal settings:

Code:

0ERT |  1ERT  |  2ERT  |  3ERT |
-8%  |   -12% |   -8%  |  -7%  |

As you can see there is no obvious general optimum. Currently we have following conclusions:
- Syncing async threads is non-neglectable for very high framerates
- 0 ERT is the best if you already have high FPS.
- 1 ERT is never a good choice - as expected.
- 2 ERT is sometimes the optimum. Especially if you have low frame rates.
- 3 ERT is a local optimum for some games. Especially those who have high framerates. The mean speedloss is lower than for 2 ERT.
- 3 ERT and more will be probably better on QuadCores.



I would stick to 3ERT as default as it yields better results on QuadCores and is similarly good on dualcores as 2 ERT.

[ssakash]

I would stick to 3ERT as default as it yields better results on QuadCores and is similarly good on dualcores as 2 ERT.

TBH I wouldn't conclude so without testing lots of games but either way it seems good for the current tested scenarios so I agree with it. though do note that for dual cores 3 still produces lower speed compared to 0 at some instances

I think you should change your code to use 3 then : https://github.com/willkuer/pcsx2/commit...916f38216c

[willkuer]

Yes. More games and more cpu's would be nice for this study. But I guess it will be too much work for a default setting.

My code actually followed this idea as I was increasing in the other commit the number of threads by one. But you are right it needs to be adjusted. As gregory would like to split the pr and and get a global default value and I forgot LinuxDialog again I need to work on it in any case. visual studio is just updating now for half an hour and not close to an end. -.-''

[Dalba]

Hello, 
using latest dev build, i'm still a little confused about how many thread i have to set using software renderer. 
Knowing i'm using a quad core i5 3570k @ 4,4ghz, what should i set in this parameter with MTVU active and without ?