Announcement

Collapse
No announcement yet.

Wine Begins Work On Direct3D Shader Compiler

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

  • Wine Begins Work On Direct3D Shader Compiler

    Phoronix: Wine Begins Work On Direct3D Shader Compiler

    It's time for another development snapshot of Wine, but this bi-weekly release does carry several features worth noting...

    http://www.phoronix.com/vr.php?view=MTExNjI

  • #2
    what is the usage of a "Direct3D shader compiler " ???

    Comment


    • #3
      Bit off topic but I find it amazing how Wine is soon 19 year old project and its creator has worked on it from the very beging and is still the most active developer. Also the project has had contributions from over 1300 developers over its life time. Here's a link to the ohloh page. Awesome stuff.

      Comment


      • #4
        Originally posted by Teho View Post
        Bit off topic but I find it amazing how Wine is soon 19 year old project and its creator has worked on it from the very beging and is still the most active developer. Also the project has had contributions from over 1300 developers over its life time. Here's a link to the ohloh page. Awesome stuff.
        This is terrible that after 21 years Linux users still need applications for Windows.

        Comment


        • #5
          @ Q

          try running sims 1 or sims 2 under previous wine's and that is your answer.

          basicaly you have different shaders, and you have a maximum number of shaders availible. this depends on your graphics card and how many it supports. in opengl, it will report how ever many your graphics card supports, and any more is, well, scuks for you if you need more. in direct3D, there is some number i cant remember off the top of my head of maximum number of shaders availible, lets just say for simplicity its 12,565, im not shure if thats it but its something arbitrary like that. direct3D will use however many shaders your graphics card supports first, and if it runs out, will start to use the software shaders to fill in. with wine since opengl doesnt support extra software shaders, we cant actualy support any more shaders than the card(or driver) provides and it throws an error. there is a similar issue where wine uses a few d3d shader slots in teh proccessof convertng it to opengl that is pretty much unavoidable and if an application expects all the shader slots to be availible and tries to use them as such, you will have an error.

          to me, having a d3d shader compiler like what is stated in the patch notes would allow you to support software shaders and thus hopeflly avoid at least the first of these problems. not 100% shure though.

          also, it would be really nice if we could have a list of what all the DIB engine does NOT currently support rather than it being stated as done like a year ago even though every new wine release another part of it is stated as done. its really hard to tell if the dib engine is really working as a finished product.

          Comment


          • #6
            I miss World Wine News Issue

            I miss the World Wine News Issues.
            It was information that came every now and then with status of Wine and how things are progressing.

            Comment


            • #7
              Let me clear up the need for the shader compiler. Most games require DirectX runtime dlls (d3dx9_*.dll) which contain utility functions and the shader compiler. Some games install them while in other cases you have to resort to tools like winetricks to obtain them. When Wine has its own shader compiler it means you don't need the d3dx9_* Microsoft dlls.

              The shader compiler has nothing to do with software rendering. Let me summarize how things work. At the core d3d9.dll only accepts 'precompiled' shaders in a bytecode format (this is an assembler format). Game developers like to write shaders in a high-level language like HLSL or Cg instead of assembler. This is where d3dx9_*.dll and the Wine shader compiler come in. The d3dx9 library contains HLSL shader compiler. It compiles Direct3D9 HLSL shaders to Direct3D9 bytecode.

              In any case whether you use the Microsoft d3dx9_*.dll implementation or the Wine one (once the HLSL compiler is done), Wine's Direct3D implementation converts the Direct3D9 bytecodes to OpenGL shaders.

              Comment


              • #8
                Originally posted by Thunderbird View Post
                Let me clear up the need for the shader compiler. Most games require DirectX runtime dlls (d3dx9_*.dll) which contain utility functions and the shader compiler. Some games install them while in other cases you have to resort to tools like winetricks to obtain them. When Wine has its own shader compiler it means you don't need the d3dx9_* Microsoft dlls.

                The shader compiler has nothing to do with software rendering. Let me summarize how things work. At the core d3d9.dll only accepts 'precompiled' shaders in a bytecode format (this is an assembler format). Game developers like to write shaders in a high-level language like HLSL or Cg instead of assembler. This is where d3dx9_*.dll and the Wine shader compiler come in. The d3dx9 library contains HLSL shader compiler. It compiles Direct3D9 HLSL shaders to Direct3D9 bytecode.

                In any case whether you use the Microsoft d3dx9_*.dll implementation or the Wine one (once the HLSL compiler is done), Wine's Direct3D implementation converts the Direct3D9 bytecodes to OpenGL shaders.
                ah nice it just makes the need of "Microsoft d3dx9_*.dll implementation " obsolete yes very nice

                Comment


                • #9
                  Again, no pulse audio support (I know it's being worked on). Hopefully we can see this support soon!

                  Comment


                  • #10
                    Originally posted by Thunderbird View Post
                    Let me clear up the need for the shader compiler. Most games require DirectX runtime dlls (d3dx9_*.dll) which contain utility functions and the shader compiler. Some games install them while in other cases you have to resort to tools like winetricks to obtain them. When Wine has its own shader compiler it means you don't need the d3dx9_* Microsoft dlls.

                    The shader compiler has nothing to do with software rendering. Let me summarize how things work. At the core d3d9.dll only accepts 'precompiled' shaders in a bytecode format (this is an assembler format). Game developers like to write shaders in a high-level language like HLSL or Cg instead of assembler. This is where d3dx9_*.dll and the Wine shader compiler come in. The d3dx9 library contains HLSL shader compiler. It compiles Direct3D9 HLSL shaders to Direct3D9 bytecode.

                    In any case whether you use the Microsoft d3dx9_*.dll implementation or the Wine one (once the HLSL compiler is done), Wine's Direct3D implementation converts the Direct3D9 bytecodes to OpenGL shaders.
                    Interesting... Couldn't Wine convert HLSL to OpenGL shaders directly, without needing to use D3D9 bytecode?

                    Originally posted by oliver View Post
                    Again, no pulse audio support (I know it's being worked on). Hopefully we can see this support soon!
                    This. If Wine had support for PulseAudio, then I could finally listen to music outside of Wine that doesn't have popping sounds or horrible quality, since otherwise if I set my PA settings to give me that, Wine starts shrieking like a banshee...

                    Comment


                    • #11
                      Optimize

                      Originally posted by Qaridarium View Post
                      ah nice it just makes the need of "Microsoft d3dx9_*.dll implementation " obsolete yes very nice
                      Yeah, well, I'd still trust their compiler to produce the better optimized output for the next 10 years. And unfortunately I can't rely on mesa's glsl compiler to compensate (yet ...).

                      Comment


                      • #12
                        Originally posted by oliver View Post
                        Again, no pulse audio support (I know it's being worked on). Hopefully we can see this support soon!
                        If you don't mind building wine by yourself, wine-pulse [1] works just fine on both Fedora 16 and Fedora 17.

                        - Gilboa
                        [1] http://repo.or.cz/w/wine/multimedia.git
                        DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                        SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                        BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                        LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                        Comment


                        • #13
                          Originally posted by GreatEmerald View Post
                          Interesting... Couldn't Wine convert HLSL to OpenGL shaders directly, without needing to use D3D9 bytecode?
                          There are small differences between HLSL and OpenGL shaders which require some 'fixups' when the shaders are being used. I don't remember the exact details, may be some cheating is useful. Note a lot of games ship with precompiled HLSL shaders in order not to have a runtime shader compile penalty. Some games may compile shaders only at first run or something.

                          For a long time to come the Microsoft compiler will likely generate faster code. Though the OpenGL shader compiler may be able to perform less optimizations on the precompiled HLSL code from the Microsoft compiler. This may actually be a disadvantage. The Wine HLSL compiler may generate less efficient code, but the code may be better suited for translation to GLSL. A good GLSL compiler may be able to compensate for inefficiencies. What will be better performance wise? Time will tell.

                          The Wine HLSL compiler will have some advantages though. Especially on older hardware SM2.0/SM3.0 hardware, scheduling of shader constants within a shader was not ideal. Games tried using constants which Wine wanted to use itself for emulating slight D3D/OpenGL differences. When Wine has its own compiler, it can try not to allocate shader constants in the range Wine wants for itself.

                          Comment


                          • #14
                            Originally posted by Thunderbird View Post
                            There are small differences between HLSL and OpenGL shaders which require some 'fixups' when the shaders are being used. I don't remember the exact details, may be some cheating is useful. Note a lot of games ship with precompiled HLSL shaders in order not to have a runtime shader compile penalty. Some games may compile shaders only at first run or something.

                            For a long time to come the Microsoft compiler will likely generate faster code. Though the OpenGL shader compiler may be able to perform less optimizations on the precompiled HLSL code from the Microsoft compiler. This may actually be a disadvantage. The Wine HLSL compiler may generate less efficient code, but the code may be better suited for translation to GLSL. A good GLSL compiler may be able to compensate for inefficiencies. What will be better performance wise? Time will tell.

                            The Wine HLSL compiler will have some advantages though. Especially on older hardware SM2.0/SM3.0 hardware, scheduling of shader constants within a shader was not ideal. Games tried using constants which Wine wanted to use itself for emulating slight D3D/OpenGL differences. When Wine has its own compiler, it can try not to allocate shader constants in the range Wine wants for itself.
                            I see. And yeap, some games do indeed precompile their shaders on the first run, like Mass Effect (creates a "shader cache" file). What fun when for some reason the precompilation doesn't work correctly or those precompiled shaders become corrupt... Black textures all over the place.

                            Comment


                            • #15
                              Originally posted by GreatEmerald View Post
                              Interesting... Couldn't Wine convert HLSL to OpenGL shaders directly, without needing to use D3D9 bytecode?
                              The API layering says no. Apps need to be able to pass in HLSL source, get back "something," and pass that in to the APIs that expect that something to be precompiled HLSL shaders and not GLSL source.

                              Even if Wine made the D3D API implementations auto-detect and accept GLSL source in place of the usual binary files, other third-party APIs cannot be magically converted, and there are such things as third-party tools that decompose and analyze the precompiled HLSL binaries.

                              Comment

                              Working...
                              X