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