Direct3D Performance Improvements Coming To Wine

[Dukenukemx]

Ok wow, this stuff really works. Almost always when i see amazing performance boost claims it turns out to be meh or just total nonsense.
But both trackmania 1 and 2 are at about the 200% boost mark. Diablo 3 seems unaffected though, but it was also unaffected by the nvidia threading optimizations. If you get it to run with this patch that is because it seems to crash the agent like crazy and that causes the game to crash at launch 9 out of 10 times.
Also did a short test with l4d2 and it seems to be a lot faster as well but more like 180%. But that's still nothing compared to the fps the linux version gets.

Care to post benchmarks? Or anyone for that matter?

[Mike Frett]

Call of Duty
Call of Duty 2
Call of Duty 4 modern Warfare
Call of Duty World at War
Call of Duty Modern Warfare
Call of Duty Modern Warfare 2
Call of Duty Black Ops
Call of Duty Modern Warfare 3
Battlefield 1942
Battlefield 2
Battlefield 2142
Battlefield: Bad Company 2
Company of Heroes
World in Conflict: Soviet Assault
Men At War
Soldiers: Heroes of WW2
ArmA 2
ArmA 2: OA

Little did AJSB know...he was playing the same game with a new skin. Oh boo f*cking hoo AJ, I have more than 200 Retail 'Win' CD/DVD games in my closet left over from my switch to Linux last year. Move on already and stop rationalizing your shitty games and your Crutch OS; Windows.

I don't know about anybody else, but I wouldn't WANT an EA game. Or any of those Games he listed, they are redundant rehashes.

[artivision]

Lies above lies.

This patch doesn't do anything. When you have a game that is peaky with threads and doesn't let you have multithreading, now you can partially do it. So you can raise your FPS to some games with CPU bottleneck problems. But unfortunately this will help only if you have a 2-core Sandybridge+. Because if you have a Core2-duo, running two compilers and an emulator (HLSL_source---to_ASM---to_GLSL_source---to_GLSL_bytecode), that will be still a CPU bottleneck.

This also doesn't do anything with D3D to OGL graphics inefficiencies. Really many D3D games can only perform a 60% with emulation, wile they waste the entire GPU. This is not fixable, because the two APIs are different. In some point OGL is like a flipped down(reversed) D3D.

When a working D3D_state_tracker for MESA is ready, then you hear farts coming from all directions. Those CodeWeavers something, they magically double their performance, wile Chronos(outer space) group announces D3D_Compatibility_Extensions for OGL4.4. Of course the first is a lie, and the second is a trash. That's because you probably cannot run MS_D3D_Compiler with this, you still need an OGL based Compiler for HLSL_source. Its basically a faster and more efficient ToGLSL. So we need work again.

I don't care if CodWeavers want something to be inside their closed program, but i want the D3D_state_tracker for MESA and better Open_GPU_drivers. LLVM must have better functionality for GL code (will be done soon), Nouveau must revers GPU cloaking (they are faster per Hz against Nvidia), and Intel must drop their x86 illusions and accept Gallium-LLVM and portable code linking. They must not control Wine any more. Wine is a (Linux) open source and free program.

[who_me]

I don't care if CodWeavers want something to be inside their closed program, but i want the D3D_state_tracker for MESA and better Open_GPU_drivers. LLVM must have better functionality for GL code (will be done soon), Nouveau must revers GPU cloaking (they are faster per Hz against Nvidia), and Intel must drop their x86 illusions and accept Gallium-LLVM and portable code linking. They must not control Wine any more. Wine is a (Linux) open source and free program.

You clearly know what must be done so why don't you stop wasting time writing posts with terrible grammar on forums and start doing. Less talk, more work. Good luck.

[ACiD]

This seems really incredible. Having the WINE compatibility layer implementation being faster than native just shows how crappy the windows codebase really is!

To me it shows how delusional many linux users are. I'd like to see how the game can perform faster than native especially given that linux graphics driver get beaten by windows in benchmarks all the time on linux native code

[ninez]

Lies above lies.

This patch doesn't do anything. When you have a game that is peaky with threads and doesn't let you have multithreading, now you can partially do it. So you can raise your FPS to some games with CPU bottleneck problems. But unfortunately this will help only if you have a 2-core Sandybridge+. Because if you have a Core2-duo, running two compilers and an emulator (HLSL_source---to_ASM---to_GLSL_source---to_GLSL_bytecode), that will be still a CPU bottleneck.

This also doesn't do anything with D3D to OGL graphics inefficiencies. Really many D3D games can only perform a 60% with emulation, wile they waste the entire GPU. This is not fixable, because the two APIs are different. In some point OGL is like a flipped down(reversed) D3D.

That's pretty fallacious, since that patch doesn't claim to do all of which you're proposing it should/does.. It moves the d3d/GL calls out of wineserver (well, once it's complete anyway), so yeah - you get increased performance and that's not rocket science, dude. - now, whether or not it is faster than windows is obviously another story, but it is realistic that this patch would significantly improve Wine's performance... Just as the RGL patch for WOW drastically improves performance, for that game && just as the patches i use for Wine imrpove applications performance significantly by moving calls out of wineserver...

When a working D3D_state_tracker for MESA is ready, then you hear farts coming from all directions. Those CodeWeavers something, they magically double their performance, wile Chronos(outer space) group announces D3D_Compatibility_Extensions for OGL4.4. Of course the first is a lie, and the second is a trash. That's because you probably cannot run MS_D3D_Compiler with this, you still need an OGL based Compiler for HLSL_source. Its basically a faster and more efficient ToGLSL. So we need work again.

I don't care if CodWeavers want something to be inside their closed program, but i want the D3D_state_tracker for MESA and better Open_GPU_drivers. LLVM must have better functionality for GL code (will be done soon), Nouveau must revers GPU cloaking (they are faster per Hz against Nvidia), and Intel must drop their x86 illusions and accept Gallium-LLVM and portable code linking. They must not control Wine any more. Wine is a (Linux) open source and free program.

Fact: Wine is NOT just a Linux open-source and free program. It's multi-platform and has been for years and years... Not only that but it is LGPL - which allows linking against non-free components... and your silly to think that CodeWeavers shouldn't be "in control" of this project. Actually, i tend to think of them as having Stewardship of the Wine Project and they do an excellent job - without CodeWeavers; Wine wouldn't progress at the pace it does and no one would be paid to work on the project, either...

...and as someone else pointed out; Nothing is stopping you from contributing and/or making your own superior implementation- since by the way you talk, i get the impression that you believe you can do better - if that's the case, then stop complaining and do something about it! ...if it's not the case, then stop crying over spilled milk. ...lastly, it should also be pointed out; CodeWeavers has nothing to do with you having better open source GFX drivers, nor was this patch written/tested against anything but nVidia blob... and again, you want better drivers, you want D3D_state_tracker for MESA?? ...then patch Wine to support D3D_state_tracker for MESA && start working on drivers... (or ocntinue to whine and complain, if that better suits your personality).

[AJSB]

If you can't play it native don't pay for it. Also, it seems you've got some kind of military fetish due to the total lack of variety in your list.

1st...who cares and what as to do with what we are talking here if i have or not a "Military Fetish" ?

FWIW, i don't have it...i also have Borderlands, Assassin's Creed 1/2, METRO 2033, NecroVisioN, etc, etc....OOOOKKK....i just noticed...more bloodshed >)

2nd...they are the best (IMHO) games of their genre and i can make almost all work under Wine (BFBC2 not yet because frame rate) some of them with frame rates very close to Window$.

[AJSB]

Little did AJSB know...he was playing the same game with a new skin.

I don't know about anybody else, but I wouldn't WANT an EA game. Or any of those Games he listed, they are redundant rehashes.

LOL, since when ArmA2/ArmA2OA and IFL44 use same engine and graphics than CoD series ?!? )

They are considered very close to mil-sim games.

Did you saw ArmA2/OA/IFL44 in Max quality graphics ?!? I don't think so )

Not to mention damage system, armor penetration in vehicles,etc,etc.

[artivision]

That's pretty fallacious, since that patch doesn't claim to do all of which you're proposing it should/does.. It moves the d3d/GL calls out of wineserver (well, once it's complete anyway), so yeah - you get increased performance and that's not rocket science, dude. - now, whether or not it is faster than windows is obviously another story, but it is realistic that this patch would significantly improve Wine's performance... Just as the RGL patch for WOW drastically improves performance, for that game && just as the patches i use for Wine imrpove applications performance significantly by moving calls out of wineserver...



Fact: Wine is NOT just a Linux open-source and free program. It's multi-platform and has been for years and years... Not only that but it is LGPL - which allows linking against non-free components... and your silly to think that CodeWeavers shouldn't be "in control" of this project. Actually, i tend to think of them as having Stewardship of the Wine Project and they do an excellent job - without CodeWeavers; Wine wouldn't progress at the pace it does and no one would be paid to work on the project, either...

...and as someone else pointed out; Nothing is stopping you from contributing and/or making your own superior implementation- since by the way you talk, i get the impression that you believe you can do better - if that's the case, then stop complaining and do something about it! ...if it's not the case, then stop crying over spilled milk. ...lastly, it should also be pointed out; CodeWeavers has nothing to do with you having better open source GFX drivers, nor was this patch written/tested against anything but nVidia blob... and again, you want better drivers, you want D3D_state_tracker for MESA?? ...then patch Wine to support D3D_state_tracker for MESA && start working on drivers... (or ocntinue to whine and complain, if that better suits your personality).

First of all i didn't say anything like that you mention above. Second, that i don't like it's not them, it is the using ones authority to harm others. I will be sorry to see this good state_tracker(to), to be abandoned because of boycottage. Third, emulation will be always inferior, even against an inferior driver with an inferior state_tracker, who told you that can be faster?. Fourth, for someone above your comment, it is not right to mock another who writes in a non native language, i probably have less mistakes than you anyway. Fifth, if i decide to help somewhere, you will see the difference. It's in the character not to the knowledge.

[ninez]

First of all i didn't say anything like that you mention above. Second, that i don't like it's not them, it is the using ones authority to harm others. I will be sorry to see this good state_tracker(to), to be abandoned because of boycottage. Third, emulation will be always inferior, even against an inferior driver with an inferior state_tracker, who told you that can be faster?. Fourth, for someone above your comment, it is not right to mock another who writes in a non native language, i probably have less mistakes than you anyway. Fifth, if i decide to help somewhere, you will see the difference. It's in the character not to the knowledge.

You didn't say anything that i mentioned above eh? lololol... So you didn't claim Wine was a linux open source program? (you did). You didn't claim that "this patch doesnt't do anything"?? (you did) ....lololol... You didn't claim that "hey must not control Wine any more"?? lololol. (you did)... And your above comment is even worse / more hilarious; You're being ridiculous and making wild accusations about people that you don't even know AT ALL - Saying they are "using authority to harm others" and "boycotting". It's borderline conspiracy theory and certainly does not reflect reality within the project at all. You've been huffing solvents or smoking crack to come to your conclusiobns...seriously.

it just isn't worth merging, at this point (it hasn't even gone through the typical wine review process at all - but hey, with all of your expertise, psychic abilities to extract the wine develpoers && Codeweavers motivations - you know better, of course...) AND they may not want that patch over some platform specific stuff -> unless they were convinced to / high enough demand... The Wine-patches review process can be rather thorough / time-consuming / rigorous and it isn't uncommon to see more invasive patchsets take some time to be merged. It will also depends on a number of other factors; so saying "they are using authority to harm others" and "boycotting" is just a bunch of asinine nonsense, that only a village idiot would come up with and peddle as fact. <which is exactly what you are doing>..

On your third point; I never claimed emulation was better did I?? Wtf are you even going on about, really? ... I said it was an improvement over normal wine (that is bound to wineserver) which is true...so seriously, piss off with this nonsensical babble.

When did i mock someone for writing crappy because of using their non-native tongue in this thread? - sure, i could of mocked someone for many things; but even if that was the case; oh well, cry me a river or grow some thicker skin. It also should be noted that i could care less about perfect grammer on Phoronix forums, pal - So, if you want an award - here you go - you're a real "winner".

On point 5; good for you! But all that i see is someone complaining like a little baby. i could care less about how amazing you think you are and how "big" your contributions would be, *if* you chose to do so. ~ You're not fooling anyone; you're just being a pretentious narcissistic asshat. Lastly, who told me it was faster? ... Moving busy/taxing calls out of Wineserver almost always ends up in performance improvements, that is just a fact, since wineserver is not multithreaded. Wineserver is probably the biggest bottleneck in Wine, by having dedicated threads (for these kind of calls) instead of relying on Wineserver, you avoid a lot performance problems in Wine, not all of them - but some pretty significant ones, for sure.