D3D Pixel/Vertex shader discussion (for shader model 2.0+)
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.
This gets me excited. I've been working on a Windows->Linux migration project that uses shader API in a mandatory library that we don't have source code for, and in a few months I'll most likely be helping to get this to work. -- Coleman Kane IntelliTree Solutions llc. 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.
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
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
On 5/4/06, Raphael <fenix(a)club-internet.fr> wrote:
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) ?
In general, any shader version 2.0 or higher will require GLSL. There are exceptions, but that's the general rule of thumb. So, unless the performance is seriously impacted, we should use GLSL if possible. Also, I'm not sure of the ramifications of using both GLSL shaders and ARB_vertex_program shaders at the same time... Haven't got that far yet, but it's a good question to look into. Phil Costin has already submitted a patch which is in Mike's tree which checks for the existence of the ARB_shader_100 extension (whatever it's called) which allows us to use GLSL shaders.
And why about specifics NV/ATI extensions for shaders ?
Hopefully we won't need them for shaders as there is already an ARB_ extension that should be usable by both vendors. But, if it turns out that we do need one or the other, then it will have to be an if () else type of scenario.
Jason Green <jave27 <at> gmail.com> writes:
On 5/4/06, Raphael <fenix <at> club-internet.fr> wrote: Also, I'm not sure of the ramifications of using both GLSL shaders and ARB_vertex_program shaders at the same time... Haven't got that far yet, but it's a good question to look into.
You can't use both at the exact same time, but it should be possible to switch between them. Also you cannot combine ARB_v_p with GLSL as far as I know. I remember reading somewhere in the GLSL spec that states that if a vertex shader is used an accompanying pixel shader must be used as well (and vice-versa), implying that you either use all GLSL or all ARB_v_p but can't mix-n-match. I would think that once GLSL is in use, we shouldn't have a reason to change to ARB_v_p. Maybe some apps/games out there use, for example, Pixel Shader 1.4 with Vertex Shader 2.0? If so, then we would have to have a PS1.4->GLSL path. I wouldn't worry about this unless it actually arises though. (Maybe non-issue, found this on MSDN: "If you are implementing shaders in hardware, you may not use vs_3_0 or ps_3_0 with any other shader versions, and you may not use either shader type with the fixed function pipeline."). Out of curiosity, is anyone working on a HLSL->GLSL compiler? This seems like a large, non-trivial part of shader model 3 that would be required for Wine to properly implement HLSL. - Aric
On 5/8/06, Aric Cyr <Aric.Cyr(a)gmail.com> wrote:
Out of curiosity, is anyone working on a HLSL->GLSL compiler? This seems like a large, non-trivial part of shader model 3 that would be required for Wine to properly implement HLSL.
At the moment, the d3d9x_##.dll files are shipped with games and those dlls convert the HLSL shaders to bytecode which we use for parsing (I think - I might be wrong about where exactly the bytecode comes from, but that's what we are using at the moment to generate shaders). Ideally, we could write our own d3d9x_## dlls to intercept the HLSL before it becomes bytecode and then perform some conversion to GLSL, but at the moment it's not needed. AFAIK, no one has done any more than talk about this type of project so far. Current status on the implementing GLSL from the bytecode: - I have some very hacked-up code working which has successfully run a 2-line DX shader using GLSL (no, I won't submit anything yet - it's that embarrasingly bad ;-) At least I now know that it'll work. - Once all of the patches that were submitted during Alexandre's vacation make it into the master git repo, I'll get the framework submitted for implementing each DX shader opcode in GLSL. There were a couple of patches sent that were rejected, and most of the patches afterwards depended on those, so nothing is applying cleanly. That part should be resolved in the next few days [hopefully]. Jason
On 04/05/06, Raphael <fenix(a)club-internet.fr> wrote:
Only one "technical thing", how you expect to determin if you need GLSL or if ARB_vertex/ARG_fragment is suffcient ? The functionality in GLSL is a superset of ARB programs. Simply use GLSL if it's available, otherwise hope ARB programs ae sufficient.
And why about specifics NV/ATI extensions for shaders ? Could be usefull for some cards that don't support GLSL, but do support certain functionality. However, I don't think there are any plans for that at the moment.
participants (6)
-
Aric Cyr -
Coleman Kane -
H. Verbeet -
Jason Green -
Phil Costin -
Raphael