Wine Begins Work On Direct3D Shader Compiler

[benjamin545]

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.

[elanthis]

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.

[GreatEmerald]

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.

[Thunderbird]

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.

[gilboa]

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

[calim]

Optimize

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

[GreatEmerald]

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?

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

[oliver]

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

[Thunderbird]

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.

[uid313]

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.