Wine and D3D

[Emanuele Oriani]

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-----
>