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

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.

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