Announcement

Collapse
No announcement yet.

Direct3D Performance Improvements Coming To Wine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Veerappan
    replied
    Originally posted by tildearrow View Post
    Typo:

    necro-thread much?

    Leave a comment:


  • tildearrow
    replied
    Typo:

    Originally posted by phoronix View Post
    by creating a separate command stream / worker thread for WineD3D.

    Leave a comment:


  • artivision
    replied
    Originally posted by Henri View Post
    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.

    Leave a comment:


  • sabun
    replied
    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.
    Last edited by sabun; 09-14-2013, 09:54 AM.

    Leave a comment:


  • Henri
    replied
    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.

    Leave a comment:


  • ninez
    replied
    Originally posted by Dukenukemx View Post
    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.

    Leave a comment:


  • artivision
    replied
    Originally posted by bridgman View Post
    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.

    Leave a comment:


  • bridgman
    replied
    Originally posted by artivision View Post
    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...

    Originally posted by artivision View Post
    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 ?

    Leave a comment:


  • Dukenukemx
    replied
    Originally posted by ninez View Post
    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?

    Leave a comment:


  • artivision
    replied
    Originally posted by bridgman View Post
    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.

    Leave a comment:

Working...
X