D3D Pixel/Vertex shader discussion (for shader model 2.0+)

[Phil Costin]

Raphael wrote:

> On Thursday 04 May 2006 20:26, Jason Green wrote:
>> Quite a few of us in #winehackers have been discussing and working on
>> pixel and vertex shaders for the last month or so.  However, due to
>> time zone differences, we don't always get to participate in the
>> discussions, so it's tough to keep track of who's doing what and what
>> the real game plan is.  So, I've started a rough draft of our roadmap
>> for GLSL implementation here:
>>
>> http://wiki.winehq.org/DirectX-Shaders
>>
>> If you've been part of these shader discussions recently or even have
>> at least a vague understanding of how this stuff works in wined3d,
>> please take a look at that page and make any modifications as you see
>> fit.
>>
>> I plan on working on (and hopefully finishing) the GenerateShader()
>> merge mentioned on that page tonight or tomorrow.  With luck, we can
>> begin implementing GLSL very soon and supporting the shaders correctly
>> on newer DirectX games.
> 
> I Jason, i fully agree :)
> 
> Only one "technical thing", how you expect to determin if you need GLSL or
> if ARB_vertex/ARG_fragment is suffcient ?
>   1 - always use GLSL when available, else try ARB compat code ?
>   2 - try to use ARB when possible, else switch to GLSL ?
>   3 - choose the more performant (heuristic depency of opcodes
>   performances) ?
> 
> And why about specifics NV/ATI extensions for shaders ?
> 
> Keep the good job,
> Raphael

Hi Raphael,

In response to your question, I have recently submitted a patch which checks
for ARB_shading_language_100 (GLSL) and also a capability check for it. At
the moment, providing the D3DDEVTYPE_HAL is specified, a check for GLSL is
made using the new GL_SUPPORT(ARB_SHADING_LANGUAGE_100) check. If it is
supported, the app is informed via CAPS that Shader Model 3.0 support is
available. (At this moment in time, that is actually is commented out and
it reports Pixel shader 1.4 and Vertex shader 1.1 instead). Otherwise, if
GLSL support returns false, a check is made for ARB_fragment_program or
ARB_vertex_program respectively. If it turns out those extensions are
supported, PS 1.4 capability is reported along with VS 1.1

PS and VS capabilities are detected individually in case we need that
flexibility...

As it stands, if a card would not normally support shader model 2 or 3 under
Windows, but /does/ support GLSL, we are still telling the app that the
card is capable of shader models 2.0+... It may be that the card simply
does not have the memory. In this case, it may be possible to still use
GLSL... but we might not want to report 2.0 or 3.0 capability to avoid the
app sending a huge shader that the card doesn't have the memory or
capability for.

Regards,
Phil Costin