Hi Stefan,
First of all thanks for the answer. It's a shame you lost that presentation, but it'd be great if you could in some way point out what are the current issues and where we spend CPU time (did I understand correctly). I don't have much free time, but would be more than happy to contribute as much as I can.
About SC2 specifically, how do I execute the +d3d9,tid command line? Keep in mind SC2.exe is a (child detached) process spawned by the 'parent' launcher (it's not so straightforward to execute it without launcher because of dlls and other stuff) so would it be like: wine +d3d9,tid SC2Switcher.exe (where SC2Switcher.exe is the launcher)?
More information about the CPU usage. If during my tests I set the affinity of the executable (and subsequently all its threads) to a particular core I have to say that core gets fully used and FPS are better than general... apparently with multiple cores set the OS tries to balance the workload, thus decreasing the FPS.
I'll be looking into dlls/wined3d/context.c as well.
Thanks again, Cheers,
Ps. When I said multiple threads directly invoke SleepEx, didn't mean it's a bad thing, just we have like 10+ threads which are inactive 95~99% of the time... and themselves set into this state I reckon.
On 08/01/11 23:20, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, I am afraid some of your conclusions are not correct, more about that at the end of the mail. Basically most of the performance issues are caused by wined3d and the opengl driver requiring too much CPU time. That slows down the game as-is, and means that the GPU can never live up to its full potential(except if you have a really weak GPU).
Unfortunately that is not one single bug, but rather 10-15 issues that sum up - and that is just covering the simplest possible rendering cases(just draw a few vertices), by adding extra stuff like textures, dynamic resources, render target switches, etc there will be many more. Fixing that will require a lot of work.
I gave a talk about this topic at wineconf 2010, but unfortunately there was no recording and I even lost my slides. However, one thing survived: My very basic drawprim benchmark at https://84.112.174.163/git/?p=perftest;a=summary (self-signed certificate). With it you can benchmark how fast wine can dispatch draw calls and optimize this very basic functionality. Once this benchmark is fixed we'll have to write many more for other d3d features(shader changes, resource loading, texture changes, thread switching, etc etc etc). So it is a lot of work. Coding help is always welcome of course :-)
Cheers, Stefan
Am 08.01.2011 um 19:34 schrieb Emanuele Oriani:
My fear is that Blizzard has introduced some sort of FPS limit and probably wine doesn't cope very well with that.
And, potentially they're using multi-threaded rendering as well.
Not as far as I know, but it is easy to check: Run the game with +d3d9,+tid and see if there are d3d drawing calls from multiple threads. If the game switches threads every now and then I wouldn't count it as multithreaded, if it constantly calls d3d from more than one thread it is multithreaded.
I've done some thread analysis and apparently the many threads the game execute stay in sleep (they actively invoke SleepEx) for 95% of the time, which is very strange.
No, not necessarily. The threads may be waiting for something, e.g. user input or network messages. Waiting threads don't have to be a bug, quite to the contrary.
This is why if we leave the CPU frequency in 'Ondemand' mode it goes to 800MHz (or the lowest frequency). Could it be related to the rendering infrastructure?
I doubt it, I guess that depends on the cpufreq settings and your CPU. I'd expect cpufreq to clock down all but one core.
I know OpenGL is essentially mono-threaded (I've used it for quite a bit in the past years). During some research I came across a Stefan's email from July 2006, were he was proposing the right thing (imho) to do to support multi-threaded D3D: a GL rendered thread per device/buffer. What happened with that? How is currently multi-threaded D3D rendering implemented in wine?
It is implemented pretty much in the way I outlined it in 2006. dlls/wined3d/context.c is responsible for multithreading, see context_acquire() and context_release().
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
iQIcBAEBAgAGBQJNKPE3AAoJEN0/YqbEcdMwo9EP/jfJyeZlVx0AsHoxWLtZ77OV ttBwCsIKs4IqJyJXgv8hNkeNQaDwk0QoJqxHkw/2AlGDO2sdaNR9EGbRMTmtH3OP 8x+UeiEntJRP3zHamxRxCus6F86cEqfca9PV/PYiVLSCdIb7v2i091n4z6o2nk7t b5yutdJsMx7jgH1QLCluS2dWs50SgFw/UXgs3nTGmg0vPefhDd4846uBKgi+yCL9 Ol5RcRz8N8VxD3dJTCgjKt8kPxlIRFiIB9Og3F9T4UowmVMTiYKvuJ/TTz/jAgTe zHzNqwNjSXScupRTFWV9EesJZKkYY5+GO0JVX1OXMWbeWG0vdmgaAsUhkLc4PHIF kFUdAnx9uOlu//F5opL9LGzwiyTfsAXNVstEs7m1jCpBoed80OfZMFNY0wH5wN9h 3c5kWIY1UoIaWkeMNLt+O3k6Xwsbfl0UAo6tgBxzx6sBff6MNxzCR6mZdz+hwhE7 eekK3N+r5nvOp9yuCQTdm+PEoaH/uPRPTqt2Z8zhABeZMdrzjcXghWRc+7dkwFic nw7qKEGoXW0zt+p58HAM8PbhMlhp6L784U3/Td11y7moXlcPh7MiaUcgYq1kBALf nOaBinWgGmzhvU5ub6l6HwAMpZl6MEKn0GeHBUMBuLhEgYdXG/l7K4hxXgYvyulg ySRGDcxFEqJezQPHNg9w =diUG -----END PGP SIGNATURE-----