[Wine] Wine 3D performance - where does the bottleneck lies and how

James Huk huk256 at gmail.com
Sun Feb 7 02:42:17 CST 2010


On Sun, Feb 7, 2010 at 2:49 AM, oiaohm <wineforum-user at winehq.org> wrote:
> James Huk  I am sorry but there is a limit to what can be done to WineD3D
>
> Mapping from Direct X to Opengl is never going to be a 100 percent clean process.
>
> This branch of gallium is working on a different solution to problem.  http://cgit.freedesktop.org/~jsindholt/mesa/log/?h=gallium-nine ie avoid opengl get closer to the hardware itself.
>
> There is still a lot of debuging code and the like in WineD3D.  All those printing of fixmes cost a lot of time.   But even disabled they cost a little bit of time.
>
> Optimizing by assembler is not worth doing.  Yes a lot of people will foolishly say it can help.  Reason it does not help is each x86 cpu these days even from the same batch takes different ammounts of time to process the same x86 instructions.   So two x86 processes same batch can require two completely different asm's to perform at best.   Also to make it worse even the same instructions sent into the cpu at different times will take different times to run.  Days of super fast asm are over. Lot of people who do that these days ends up with super snail code and cannot work out why.
>
> Reason why some developers near gcc are developing this http://ctuning.org/wiki/index.php/CTools:MilepostGCC so that complier can adjust to the cpu it has at hand.
>
> Currently gcc is very poor optimizer.   The upcoming gcc 4.5.0 will help a bit.
>
> Current gcc optimization only happens with the .c to .o conversion happens.   Does not happen at conversion from .o to final binary.   There are most likely areas in the wined3d that can optimize out that are not.
>
> gcc 4.5.0 has a link time optimisation option that does .o to final binary optimisation.
>
> Problem here is lets say you do optimize them out by hand at this stage you will make maintenance of code harder.
>
> Basically lots of different issues causing it speed problems.   Some inside wine control some not.
>
>
>
>
>
>

Thank you for the answer.

Of course I understand that there will always be overhead because of
D3D to OpenGL conversion - however, there are some games that works
significantly faster on Cedega for example - one of such games was
Rally Championship 2000 - (was because now it doesn't work on Cedega
at all - typical)
while driving it was 5 times faster on Cedega(practically Windows
speed) then on wine, even thou both wrappers run it perfectly, so I
guess there is a way to optimize wine code a bit more. Also please
keep in mind - I'm talking here about program specific optimizations
rather then generic optimizations, also I think that if the game runs
50% slower then on Windows then there is a room for improvement (at
leas I hope there is)?



More information about the wine-users mailing list