Direct3D Performance Improvements Coming To Wine

[ninez]

What would be the problem if the state tracker were to only be for Linux? I don't understand am I missing something important?

It just makes it less likely to be accepted into Wine.

[Henri]

Just for the record, while I think it's fairly unlikely that the code for supporting the Gallium3D d3d9 state tracker would be accepted in Wine in its current form, it was never actually submitted for inclusion. In addition, Christoph Bumiller has stated fairly explicitly on IRC that he's not particularly interested in doing the considerable amount of work to make that happen.

I do have an (obvious) opinion on the relative merit of a custom state tracker vs. an implementation based on GL + extensions, as well as on some other design decisions, but that's simply not what's keeping the d3d9 state tracker out of Wine at this point.

[sabun]

Testing this patch...

Alright, so I've been trying out this patch for a bit.

It struggles with Steam, that's for sure. So I tried a pirated version of Blur, doesn't run at all. Works fine in 1.5.27, but 1.7.1 with the patch it won't run.

Tried GRID (in Steam), this game is still problematic, no matter what Wine version I try.

Tried Mortal Kombat, crashed immediately. Mortal Kombat is one such game that suffers low FPS in normal Wine, I was hoping to get it playable with this patch.

Steam with normal 1.7.1 is fine.
Steam with patched 1.7.1 is troublesome. I was able to run it once, but no more after that.

EDIT: Need For Speed Hot Pursuit does not work with this patch. Works with clean Wine 1.7.1.

[artivision]

Just for the record, while I think it's fairly unlikely that the code for supporting the Gallium3D d3d9 state tracker would be accepted in Wine in its current form, it was never actually submitted for inclusion. In addition, Christoph Bumiller has stated fairly explicitly on IRC that he's not particularly interested in doing the considerable amount of work to make that happen.

I do have an (obvious) opinion on the relative merit of a custom state tracker vs. an implementation based on GL + extensions, as well as on some other design decisions, but that's simply not what's keeping the d3d9 state tracker out of Wine at this point.

First i am sorry if i was disrespectful. Second your implementation is like you are in agreement with MS. You run 2 compilers and an emulator. HLSL_source to HLSL_asm with MS_d3d_compiler, HLSL_asm to GLSL_source with an emulator, GLSL_source to GLSL_bytecode with a vendor GLSL_compiler. Totally overkill for a Core2Duo. Also D3D, in one point is like a reversed (flipped down) OGL, so in many games there is a -40% in efficiency only from that (it is exactly 40%, no less). My point is that you must start an OGL based D3D(source) compiler, that has direct GLSL_bytecode as output and not nv_gl_assembly like WineD3D, that will save the CPU. Also, your HLSL_source to HLSL_bytecode via LLVM experiment is a +failure to the basket. You must try immediately those scenarios like HLSL_source to direct GLSL_source and then GLSL_bytecode, and also those new OGL4.4 D3D_compatibility_extensions, the second will save the GPU. Also i noticed that without a native D3D state tracker, we are just waiting when MS will change again D3D in an incompatible way, when GPU vendors will decide to fix the bridge, and when you are ready to do something. I thing a D3D state tracker is the right way, so no one can use extortion on as.

[tildearrow]

Typo:

by creating a separate command stream / worker thread for WineD3D.

[Veerappan]

Typo:

necro-thread much?