Announcement

Collapse
No announcement yet.

Wine Begins Work On Direct3D Shader Compiler

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

  • #11
    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


    • #12
      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


      • #13
        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


        • #14
          ok, so this doesnt solve the problem of software shaders. would be nice if they focused on that some, it seems some of the earlier d3d games really did some weird stuff that would make this a requirment.

          did they change their plans on basing the audio structure on openAL? i think at one time they were planning on rewriting the audio stack to use linux's openal to output everything and let openal handle all the system audioo hooks.

          Comment


          • #15
            Originally posted by benjamin545 View Post
            did they change their plans on basing the audio structure on openAL? i think at one time they were planning on rewriting the audio stack to use linux's openal to output everything and let openal handle all the system audioo hooks.
            The Wine audio stack has been rewritten in Wine 1.4. Internally it works similar to the Vista/Win7 audio service which is a bit like Pulseaudio. Wine has small drivers for relevant audio systems like Alsa, OSS and coreaudio. OpenAL wasn't a good fit for Wine and it wouldn't have been great for latency.

            Comment


            • #16
              is there a plan for a simple pulseaudio backend then, ( i know about the pulse driver from pre wine 1.4, it was determined that it wouldnt be incorperated into wine since they were planning on rewriting the audio stack. dont know much more about it after that.)

              Comment


              • #17
                Originally posted by benjamin545 View Post
                is there a plan for a simple pulseaudio backend then, ( i know about the pulse driver from pre wine 1.4, it was determined that it wouldnt be incorperated into wine since they were planning on rewriting the audio stack. dont know much more about it after that.)
                Someone wrote a pulseaudio backend for the new audio subsystem, but it hasn't been added yet. There are some concerns including maintenance. Anyway the new audio subsystem should handle pulseaudio much better than the previous one, so there may not be a big need.

                Comment


                • #18
                  Originally posted by Thunderbird View Post
                  Someone wrote a pulseaudio backend for the new audio subsystem, but it hasn't been added yet. There are some concerns including maintenance. Anyway the new audio subsystem should handle pulseaudio much better than the previous one, so there may not be a big need.
                  Not really. For some odd reason, when I set PulseAudio to use the traditional scheduling with interrupts instead of timers, Wine sound gets completely corrupt and distorted. But then my audio files are played correctly outside of Wine. And if I set it to use timers, Wine works fine but my audio is popping all the time - unless I set PulseAudio to use the trivial resampling method, in which case audio everywhere seems like it's running on a 16K bitrate... So in essence it's a "pick your poison" situation, until Wine incorporates a PA backend.

                  Comment


                  • #19
                    Originally posted by GreatEmerald View Post
                    Not really. For some odd reason, when I set PulseAudio to use the traditional scheduling with interrupts instead of timers, Wine sound gets completely corrupt and distorted. But then my audio files are played correctly outside of Wine. And if I set it to use timers, Wine works fine but my audio is popping all the time - unless I set PulseAudio to use the trivial resampling method, in which case audio everywhere seems like it's running on a 16K bitrate... So in essence it's a "pick your poison" situation, until Wine incorporates a PA backend.
                    Have you tried winepulse?

                    - Gilboa
                    oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                    oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                    oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                    Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                    Comment


                    • #20
                      I think winepluse only exists in git of a developer atm, unless it has been merged with 1.5.6, it's only winealsa for now.

                      As for winealsa, currently for me does not work in combination with pulseaudio. I can kill pulseaudio, run wine just fine with sound, or have pulseaudio running and silent wine.

                      Comment

                      Working...
                      X