7 Versions Of WINE Benchmarked
Phoronix: 7 Versions Of WINE Benchmarked
The WINE project is going on 15 years in existence, and two years ago, it finally went into beta. Through the beta stage, there has been a consistent release about every two weeks, which often brings a fair number of improvements to this software for running Windows programs on Linux (and other operating systems). Sparked by curiosity as to how the performance of WINE is affected release by release, we have gone through and benchmarked the past seven releases. While this only represents the past four months of work by the WINE community, the results may surprise you.
Are you sure that the different versions of wine are rendering the same items? If 0.9.44 ignores or only has stub functions for certain shader elements, then that would easily explain why it performs better than later wine versions that actually implement these functions. I'm not sure that this has happened, but for this comparison to be meaningful you have to have a screenshot comparison or something to show us they're actually rendering the same elements.
Most users reading this article would say afterwards that recent Wine versions are crap in terms of performance but there is more than that. For a large part it is a bit comparing apples with oranges.
Since the end of the summer we have been using the 'DirectX conformance tests' to make WineD3D conform a lot better to the Windows drivers. Those tests for instance check if all 3d functionality exported by your driver (in this case Wine) is present. A lot of bugs and issues have been fixed by that and there are still a lot of issues remaining (there are thousands of tests).
Returning back to for instance 3dmark2003. At some points no shadows got rendered. And somewhere around the time of the DCT tests, those started to work. There are more examples like that.
So in other words because WineD3D is behaving more correctly now its performance decreased.
Further the drop in performance after 0.9.48 is caused by the use of GLSL. It is required to run modern games with Shader Model 2.0 / 3.0 but for lower versions ARB shaders are more optimal as the glsl calls cause a little overhead (the shader compilation and linking stages).
Last edited by Thunderbird; 12-09-2007 at 09:35 AM.
Would you rather have every game at slow but playable framerates or very few games, at good framerates but with no graphics quality.
Right now Wine should be about compatibility. Optimising for advanced features should come later.
We are running the DCT to increase compatibility. Lots of additional games work due to this. These days there are still some d3d bugs (stability / drawing bugs) but a game not starting up is in general not anymore due to crappy direct3d support. The main issues lie elsewhere in e.g. installers, copy protections and other areas.
Originally Posted by Game_boy
Those benches must have taken forever!
@Thunderbird that is very interesting, have you also been doing the same for audio related tests?