Direct3D Performance Improvements Coming To Wine

[Veerappan]

Typo:

necro-thread much?

[tildearrow]

Typo:

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

[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.

[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.

[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.

[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.

[artivision]

The shaders are represented as shaders in TGSI (which the pipe driver compiles to hardware instructions), not as lines/triangles/textures. Triangle vertices get processed by the vertex shaders then reassembled into triangles, the triangle is broken down into pixels, then an instance of the pixel shader runs for each pixel and generates an output using texture samples etc...



Are you talking about converting to the *inputs* of an OpenGL driver ? If so, isn't that basically what Wine does today ?

No Mr Bridgman, no. There are at least three ways to be portable:

1) We can patch D3D_ST to work with closed drivers instead of Gallium. You can make the patch yourself.

2) You can connect Gallium and closed drivers via a driver that speaks with OGL or OCL. You don't convert anything, you do it like a compute shader. Lets assume that i make an OCL compute shader with circles and spheres instead of triangles and lines. A compute shader does have the shader it self --and-- the rules to interact, wile a normal shader hes only the first. This way a compute shader adds new programs to the state tracker, or you can say that is an addon state tracker by it self. So we don't convert to OGL, the d3d9_st works by its own rules, with equal rights as your driver it self.

3) You can have good open drivers and the closed drivers, installed in any system at the same time, and you can switch without system restart. So you don't need to connect the d3d9_st with closed drivers.

Extra) Wine must be compiled for this, and we must have an option with a simple tick, if we want the d3d9_st or GLSL or WineD3D and GLSL off.

Final) I'm sorry if i showed disrespect to CodeWeavers people, it was not my intention. I just want Wine to implement other ideas to. If they don't want to work for this new thing it is their right. But it is not their right to exclude it from main Wine.

[bridgman]

Both OGL3.3 and D3D9 state trackers speak to Gallium3D. Then Gallium represents shaders to the main synthesizer as lines, triangles and textures.

The shaders are represented as shaders in TGSI (which the pipe driver compiles to hardware instructions), not as lines/triangles/textures. Triangle vertices get processed by the vertex shaders then reassembled into triangles, the triangle is broken down into pixels, then an instance of the pixel shader runs for each pixel and generates an output using texture samples etc...

I said that the D3D9 state tracker can speak to Catalyst via a patch, targeting the place where libogl32.dll does connect. My point is that we can make a Gallium driver that can speak to Catalyst via OGL, and make Catalyst work with the D3D9 state tracker. Then we don't need that because MESA is fast, near Catalyst and faster per clock against Nvidia.

Are you talking about converting to the *inputs* of an OpenGL driver ? If so, isn't that basically what Wine does today ?

[Dukenukemx]

Portable "in theory" only. that's all... The particualr state_tracker you are whining about isn't implemented anywhere else (multiplatform), and likely wont be, either.

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

[artivision]

State trackers talk to Gallium3D pipe and winsys drivers, not to OpenGL. The OpenGL API code *is* a state tracker.

Both OGL3.3 and D3D9 state trackers speak to Gallium3D. Then Gallium represents shaders to the main synthesizer as lines, triangles and textures. I said that the D3D9 state tracker can speak to Catalyst via a patch, targeting the place where libogl32.dll does connect. My point is that we can make a Gallium driver that can speak to Catalyst via OGL, and make Catalyst work with the D3D9 state tracker. Then we don't need that because MESA is fast, near Catalyst and faster per clock against Nvidia.