wine users - Feb 2010 - Re: Wine 3D performance - where does the bottleneck lies and how

The performance of WineD3D depends on the application and display drivers. It is
hard to say where we are losing the performance and whether it is WineD3D which
has to be blamed.

To find out where the performance is lost you need to profile the app using e.g.
sysprof or oprofile. Then you can see where the time is spent. Typically we
don't spend a lot of time in Wine code but outside Wine in the display
drivers. Some drivers don't offer good implementations for all OpenGL calls
which causes software emulation. It can also be that the drivers have to to
convert data to a different format before they are upload to the GPU. It can
also be that we use OpenGL in an inefficient way for this app. It is very hard
to figure out good optimizations.

James Huk you will also notice at times  Cedega  is fast than wine on some games
but other games using the same functions don't work at all under Cedega but
run perfectly under wine.

Ie poorer implementation with less checks for features runs faster.  Sorry but
that is the way it is at times.   Its very hard to compare two different
implementations complete to different levels and forecast anything.

There are lot of different things that still can be done.   James Huk so there
is hope.

Wine does not doing application specific optimizations in the code base any
more(over 8 years go that was no more).  It makes maintenance of code insanely
hard.   Either implement right or not at all.

They may be some place for run game profiling wine then rebuilt wine with code
in different function layout by compiler to suit game.  So leaving the wine
source base alone.  These kind of experiments have not been tried with wine as
far as I know.  Of course that is only going to have advantages on a application
by application base.  Maybe some functions have order of check for operations
wrong.

Basically without collected data changing the perminte order of checks in the
main wine source code would be reckless.

Thunderbird question do we need something like milepost for opengl/direct x that
can rebuild code different ways depending on how smart or how dumb the video
card is?

On 9 February 2010 00:12, James Huk <huk256 at gmail.com> wrote:
> Thanks for the information everyone - that cleared thing up a bit. One
> more thing I was wondering... do you know if somebody ever tried
> compiling wine using Intel C Compiler (presumably - the fastest x86
> compiler there is)? Should it be possible to compile wine using this
> compiler "out of the box" or would some changes to the code need
to be
> done first?

http://wiki.winehq.org/icc - some experiments along these lines. Not
sure anyone's actively working to keep Wine compilable in icc, let
alone doing performance testing. Basically, give it a try and you'll
be helping keep the Wine codebase robust and cross-compiler compliant!


- d.

---------- Forwarded message ----------
From: James Huk <huk256 at gmail.com>
Date: Fri, Feb 12, 2010 at 4:26 AM
Subject: Re: [Wine] Wine 3D performance - where does the bottleneck lies and how
To: David Gerard <dgerard at gmail.com>


On Tue, Feb 9, 2010 at 1:28 AM, David Gerard <dgerard at gmail.com>
wrote:
> On 9 February 2010 00:12, James Huk <huk256 at gmail.com> wrote:
>
>> Thanks for the information everyone - that cleared thing up a bit. One
>> more thing I was wondering... do you know if somebody ever tried
>> compiling wine using Intel C Compiler (presumably - the fastest x86
>> compiler there is)? Should it be possible to compile wine using this
>> compiler "out of the box" or would some changes to the code
need to be
>> done first?
>
>
> http://wiki.winehq.org/icc - some experiments along these lines. Not
> sure anyone's actively working to keep Wine compilable in icc, let
> alone doing performance testing. Basically, give it a try and you'll
> be helping keep the Wine codebase robust and cross-compiler compliant!
>
>
> - d.
>
Ok, i managed to compile it, well most of it anyway - some test
failed, or at least I think that's what is in the log. Also dxgi
(whatever that is) failed to compile, and no programs were build, I
had to go to the programs dir and type "make" there - then they
compiled without problem.
Hopefully nothing else is missing. And holy hell! Wine source after
compilation has 17.7 GB!! With GCC it usually have a bit more then 1GB
- 16GB difference is a bit weird.

As for speed - I will try to test that tomorrow (sorry, it is 4.23 AM
in here ;] ), but I already managed to run Operation Flashpoint and I
must say, I don't see any difference in speed, however more apps need
to be tested. I will try some 3d marks tomorrow, anything else you
would recommend for speed tests?

Compilation log can be found here:

http://wine.x.pl/wine-1.1.38-ICC-compilation.log.tar.gz