WineD3D performance

[Graham Knap]

Stefan Dösinger wrote:
> Note however that improving performance is not a weekend's job.
> It needs a lot of careful profiling, testing and bugfixing.

Of course. I'm also starting with no knowledge of D3D/OpenGL, so
that's going to slow me down rather a lot.

> Depending on your settings, you may be CPU or GPU limited.

As noted in Wine bug 24558, I find that need to use taskset to get any
useful amount of performance.

$ taskset -a -p 2 `pidof SC2.exe`
$ taskset -p 1 `pidof SC2.exe`

I am not sure that this is a Wine bug at all. I think it is merely a
difference in the OS's scheduler and power management. SC2 probably
should set thread CPU affinity, but I don't think it does that.

The graphic detail and display resolution settings in the game don't
make a huge difference to the frame rate, so I think we're CPU-bound.

> In the CPU limited case, I believe the main reason is that native is able
> to move a lot of the CPU-side work to a different thread, thus utilizing
> two CPU cores. You can test that theory by forcing Windows to run with
> one CPU only (use msconfig for that) and comparing performance again.

That makes a difference for sure. Frame rate during a small recorded battle:

* Linux + Wine: about 18 FPS
* Windows XP (native D3D) with 1 core: about 48 FPS
* Windows XP (native D3D) with 2 cores: about 67 FPS

We have spent some time with strace, latencytop, and WINEDEBUG,
looking for ways to reduce latency and scheduler thrash. I don't think
there is much room for optimization here. However, I would still like
to know what is calling various functions that cause latency, such as
Sleep() or anything that requires a server call. Does anyone know how
I can get that information? (I just want to know whether the call is
coming from SC2, or from somewhere within Wine.)

We have tried using Linux's "perf" tool to find out what code paths
should be given attention first. However, even though I have compiled
Wine with "-ggdb", perf seems unable to show symbols for some parts of
Wine, notably ntdll and kernel32, but probably also others. Does
anyone know why? Is there a workaround, or a better method altogether?

The "Performance" page on the Wine Wiki suggests that it may be
possible to use Visual Studio's profiling tools. Can anyone offer any
tips for compiling and profiling WineD3D with Visual Studio?

-- graham