D3D Shaders - how does it work?

[Thomas Berger]

Hi,

i'm digging in the shader code for some hours right now, to understand what 
must be done to fix #41173 [1] and #40873 [2].

Right now, i don't really understand how the declaration of variables works in 
detail.

Is there any documentation how the handling and registering of variables 
works, or should the could be documentation enough?

[1] https://bugs.winehq.org/show_bug.cgi?id=41173
[2] https://bugs.winehq.org/show_bug.cgi?id=40873

Greetings, 
Thomas

[Henri Verbeet]

On 17 July 2017 at 15:33, Thomas Berger  wrote:
> i'm digging in the shader code for some hours right now, to understand what
> must be done to fix #41173 [1] and #40873 [2].

Quite frankly, I think those bug reports are questionable to begin
with. The level of analysis seems to be "I saw a FIXME", without any
reasoning how that's related to any negative effect in the
application. You could use shader_glsl_nop() as handler to make the
FIXME go away, but WINEDEBUG=-all would do that without having to
touch any source code. Phrased differently, what is the problem you're
*really* trying to solve? The FIXME may not have anything to do with
it.

[Thomas Berger]

On Montag, 17. Juli 2017 16:26:18 CEST Henri Verbeet wrote:
> Quite frankly, I think those bug reports are questionable to begin
> with. The level of analysis seems to be "I saw a FIXME", without any
> reasoning how that's related to any negative effect in the
> application.

There are some bugs, blocked by the missing opcodes right now. It also sound 
reasonable that, if the interpolation for shaders is not working as expected, 
it results in graphical artifacts.

There are many other bugs, much more critical with more effect, yes. But:
The wine source is something new to me. Implementing this two opcodes is a 
task where i know what the opcodes should do, and how to do that. As there is 
a very straight forward translation to GLSL, it is not much afford to write 
high performance translation functions. So, that's the reason why i decided to 
pick these two bugs.
> You could use shader_glsl_nop() as handler to make the
> FIXME go away, but WINEDEBUG=-all would do that without having to
> touch any source code.

An what is the idea behind that? It does not fix the problem, it is only 
hidden.
> Phrased differently, what is the problem you're
> *really* trying to solve? The FIXME may not have anything to do with
> it.

First of all, i want to find my way in this pile of code called wined3d ;)
An if the graphical glitches i encounter in some games with this fixme messages 
could be fixed, great! If not: Also great.

---
Thomas

[Józef Kucia]

On Mon, Jul 17, 2017 at 8:30 PM, Thomas Berger  wrote:
> On Montag, 17. Juli 2017 16:26:18 CEST Henri Verbeet wrote:
> > Quite frankly, I think those bug reports are questionable to begin
> > with. The level of analysis seems to be "I saw a FIXME", without any
> > reasoning how that's related to any negative effect in the
> > application.
>
> There are some bugs, blocked by the missing opcodes right now. It also sound
> reasonable that, if the interpolation for shaders is not working as expected,
> it results in graphical artifacts.

For a lot of games implementing those opcodes won't make any,
noticeable or significant difference, but yes, it may fix some
graphics artifacts for other games.
> There are many other bugs, much more critical with more effect, yes. But:
> The wine source is something new to me. Implementing this two opcodes is a
> task where i know what the opcodes should do, and how to do that. As there is
> a very straight forward translation to GLSL, it is not much afford to write
> high performance translation functions. So, that's the reason why i decided to
> pick these two bugs.

If we want to implement this we potentially need two code paths:
* in GLSL 4.40+ you can just specify interpolation qualifiers in a
fragment shaders (i.e. interpolation qualifiers don't have too much
between shader stages),
* in older GLSL versions the implementation will be more involved, you
have to specify matching interpolation qualifiers in a fragment shader
and a previous shader stage. It's a bit problematic because you will
need to generate a shader variant for a previous shader stage
depending on interpolation qualifiers in a fragment shader.

I think we should implement the code path for older GLSL versions
first, so we do not require GLSL 4.40+ for SM4 shader support. The
GLSL 4.40+ code path is a nice addition because it doesn't need shader
variants.

FWIW, there were some patches submitted for interpolation qualifiers
in the past [1], [2]. You can potentially use them as a starting
point. The mentioned patches contain a simple test case for
interpolation qualifiers. You can also find some review comments on
wine-devel [3], [4].

[1] - https://www.winehq.org/pipermail/wine-patches/2016-November/155649.html
[2] - https://www.winehq.org/pipermail/wine-patches/2016-November/155843.html
[3] - https://www.winehq.org/pipermail/wine-devel/2016-November/115234.html
[4] - https://www.winehq.org/pipermail/wine-devel/2016-November/115338.html

[Henri Verbeet]

On 17 July 2017 at 21:18, Józef Kucia  wrote:
> On Mon, Jul 17, 2017 at 8:30 PM, Thomas Berger  wrote:
> > There are some bugs, blocked by the missing opcodes right now. It also sound
> > reasonable that, if the interpolation for shaders is not working as expected,
> > it results in graphical artifacts.
>
> For a lot of games implementing those opcodes won't make any,
> noticeable or significant difference, but yes, it may fix some
> graphics artifacts for other games.

Case in point, several of the d3d11 regression tests produce the
FIXMEs mentioned in those bug reports, while working fine. That's not
to say making the different interpolation modes work wouldn't be
appreciated, but the number of applications it's going to affect in a
significant way is likely to be more modest than those bug reports
would suggest.

[Ken Thomases]

On Jul 17, 2017, at 8:33 AM, Thomas Berger  wrote:
> i'm digging in the shader code for some hours right now, to understand what 
> must be done to fix #41173 [1] and #40873 [2].
>
> Right now, i don't really understand how the declaration of variables works in 
> detail.
>
> Is there any documentation how the handling and registering of variables 
> works, or should the could be documentation enough?

Probably the best approach is to examine the commit history to see how it was done in the past.  For example, take a look at some of the commits listed by this command:

git whatchanged -n 20 --grep '\bdcl_' origin/master -- dlls/wined3d

-Ken