1) The following pixel shader opcodes appear to be implemented with fragment_ARB, yet they are marked REQUIRE_GLSL. This generates errors, and they are skipped. Is this intentional?
D3DSIO_TEX (texld), D3DSIO_CND, D3DSIO_CMP.
2) D3DSIO_CMP appears incorrect according to info online - the Opengl CMP should check >0, while the DirectX checks >= 0.
3) Is there a point at storing the OpenGL code in this large table? I don't like how for half the codes wined3d attempts to map them 1:1 to an opengl code via this table, and for the other half it doesn't use this field at all [ because it can't, combinations are necessary ]. Why not get rid of the field completely?
4) Wined3d likes to print out comment tokens as a FIXME - can this be downgraded to a TRACE?
5) The d3d9 pixel shader relay says (Disabled) - this is misleading, the shaders are enabled.
========== I want to figure out why HL2 doesn't work - enabling the codes above does not seem to help (but looking at the generated shader output, it makes make more sense). HL2 has severe texturing, lighting, and sound problems with hardware shaders (and it's slow and unusable with the software ones).
On 09/04/06, Ivan Gyurdiev ivg2@cornell.edu wrote:
- The following pixel shader opcodes appear to be implemented with
fragment_ARB, yet they are marked REQUIRE_GLSL. This generates errors, and they are skipped. Is this intentional?
D3DSIO_TEX (texld), D3DSIO_CND, D3DSIO_CMP.
I'm not sure why they were disabled in the first place, but they can probably be used, yes. However, before doing that it should be verified the opcodes are equivalent.
- Is there a point at storing the OpenGL code in this large table? I
don't like how for half the codes wined3d attempts to map them 1:1 to an opengl code via this table, and for the other half it doesn't use this field at all [ because it can't, combinations are necessary ]. Why not get rid of the field completely?
It should probably be replaced with something more similar to what's used for software shaders, but it's certainly being used at the moment.
- Wined3d likes to print out comment tokens as a FIXME - can this be
downgraded to a TRACE?
Sure. It's certainly not the only place in wined3d where a FIXME is used but a TRACE would be more appropriate.
- The d3d9 pixel shader relay says (Disabled) - this is misleading, the
shaders are enabled.
That can be removed.
I want to figure out why HL2 doesn't work - enabling the codes above does not seem to help (but looking at the generated shader output, it makes make more sense). HL2 has severe texturing, lighting, and sound problems with hardware shaders (and it's slow and unusable with the software ones).
There are currently several things broken with shaders, but I doubt they are the cause for sound problems.
H. Verbeet wrote:
On 09/04/06, Ivan Gyurdiev ivg2@cornell.edu wrote:
- The following pixel shader opcodes appear to be implemented with
fragment_ARB, yet they are marked REQUIRE_GLSL. This generates errors, and they are skipped. Is this intentional?
D3DSIO_TEX (texld), D3DSIO_CND, D3DSIO_CMP.
I'm not sure why they were disabled in the first place, but they can probably be used, yes. However, before doing that it should be verified the opcodes are equivalent.
They're not equivalent - they're implemented [ in wined3d ] as combinations of other opcodes (and the cmp one is wrong). However, this appears to be dead code at the moment - see after the GLSL check.
I want to figure out why HL2 doesn't work - enabling the codes above does not seem to help (but looking at the generated shader output, it makes make more sense). HL2 has severe texturing, lighting, and sound problems with hardware shaders (and it's slow and unusable with the software ones).
There are currently several things broken with shaders, but I doubt they are the cause for sound problems.
What's broken with shaders? Are there known problems, or bugs that haven't been found yet?
On 09/04/06, Ivan Gyurdiev ivg2@cornell.edu wrote:
What's broken with shaders? Are there known problems, or bugs that haven't been found yet?
There's quite a bit of functionality that isn't implemented, or isn't implemented correctly, in particular v2 and v3 shaders. It also looks like in certain places code for vertex shaders was simply used for pixel shaders despite the fact that it's not always possible. There's probably a fair amount of bugs as well. A lot of that just takes a lot of time to figure out, but some of it would also require GLSL to implement correctly.
-
H. Verbeet -
Ivan Gyurdiev