GLSL problems on Mac (really broken now)

[ds01]

r_textureunits 1 would probably hide this artifact

I just tried this by setting the textureunits to 1 in my autoexec.cfg but it still happens.

Also for some reason never saw any warnings in the shader compile log before, but i.e. on maps with this strange problem I ran using developer option on and noticed this:

Code: Select all

^7program link log:
^7WARNING: Vertex shader writes varying 'EyeVector' which is not read by fragment shader.

That's the only warning I ever get in the shaders (note it doesn't cause a link failure), and I've never noticed it as it doesn't occur on all maps (only in specific instances i.e. on nexdm03).

[LordHavoc]

r_textureunits 1 in the console works just as well, it takes effect immediately.

Normally your r_textureunits should be somewhere in the 4-16 range on GL2 cards like yours.

Harmless warning, I knew my simplification would cause that warning, tempted to add the relevant #ifdefs to avoid that warning though (like before).

[ds01]

r_textureunits 1 in the console works just as well, it takes effect immediately.

I figured it did, but I wanted to be sure

Normally your r_textureunits should be somewhere in the 4-16 range on GL2 cards like yours.

It's recognized correctly as 4 plus 16 image and 8 array (in the logs I posted as well). One of the first things I did was check the number of TMUs reported by the driver upon looking at the GL support after getting the machine. It's just sad when the corp.s have to dupe the consumers with marketting ploys like "24 Texture Units", but then fail to call attention to the fact their product only actually supports 4 for TMU - the rest being pixel or vertex.

Harmless warning, I knew my simplification would cause that warning, tempted to add the relevant #ifdefs to avoid that warning though (like before).

Well you do what you gotta do.

Have you considered moving the shader routines into the permutation, so they're 'injected' into the shaderstring as needed? You've probably already thought of that, since you stated manageability in merging vp and fp into one string and treating them as one unit. It might decrease the compile time of the shaders a bit if you did, although I'm unaware of anyone benchmarking GLSL compile times.

[LordHavoc]

It's recognized correctly as 4 plus 16 image and 8 array (in the logs I posted as well). One of the first things I did was check the number of TMUs reported by the driver upon looking at the GL support after getting the machine. It's just sad when the corp.s have to dupe the consumers with marketting ploys like "24 Texture Units", but then fail to call attention to the fact their product only actually supports 4 for TMU - the rest being pixel or vertex.

Well it has 24 texture units because it has 24 pixel pipelines (each consisting of one 8 scalar floating point math units, one of which is also a texture unit), so in a performance sense it has 24 texture units, but texture units are (in the age of pixel shaders) separate from texture image units of which there are 16, but only 8 array units, and a driver so lazy it only emulates 4 conventional texture units.

Note that NVIDIA's Direct3D driver offers 8 texture units and NVIDIA's OpenGL driver offers 4 texture units, and UT2004's Onslaught mode has a shield around the power nodes (domination control points) whose shader uses 5 texture units and looks wrong in OpenGL mode on NVIDIA.

Have you considered moving the shader routines into the permutation, so they're 'injected' into the shaderstring as needed? You've probably already thought of that, since you stated manageability in merging vp and fp into one string and treating them as one unit. It might decrease the compile time of the shaders a bit if you did, although I'm unaware of anyone benchmarking GLSL compile times.

The GLSL preprocessor quickly eliminates the undesired permutation code, so it would have no effect on compile times whether I do it in engine code or the driver does it.

As for the idea itself, that's what I mentioned earlier as a workaround for the driver bug, but I do not want to do that, it's stupid for the engine to have to do something the spec mandates support for in the driver.

[ds01]

Glow is fixed in cvs hey good job

The problems with blooms moving is related to waterscroll, and I discovered this by chance - disabling waterscroll stops the problem. Looks like there are some things going on which are related to each other, but I haven't wrapped my head around it yet.

If gl_paranoid is on there are invalid ops, usually only two are often but if the map has textures that do waterscroll then there are more. There is also one straight off that only occurs once while the screen is setup.

Log was like 25MB so I went through and deleted all duplicates to get a single instance of each:

Code: Select all

GL_INVALID_OPERATION at cl_screen.c:1411
GL_INVALID_OPERATION at gl_rmain.c:916
GL_INVALID_OPERATION at gl_backend.c:604
GL_INVALID_OPERATION at gl_backend.c:547
GL_INVALID_OPERATION at gl_backend.c:560
GL_INVALID_OPERATION at gl_backend.c:642
GL_INVALID_OPERATION at gl_backend.c:569
GL_INVALID_OPERATION at gl_backend.c:1331


That's in the order in which they occur. Tried to look for differences in API behaviour between Apple's implementation and a reference (used Mesa) and only found a few things.

Did some benchmarks with all texunits enabled versus setting them to 1 to see if it makes any difference, because there doesn't seem to be any difference at all; and there was none - neither synthetic nor in-game (no diff in FPS). I realize the DP engine is for most part shader-bound by GPU and performance is CPU-limited, but there ought to be a diff. Can you confirm whether there is a performance diff or not?

If you look at those lines, there are colorfloat err depthmask err blendfunc err, so many I don't have enough experience with DP to judge which is causing what (or not).

So the only thing I discovered was different in the API docs would be this and not sure if it's a factor, (besides initially depth buffer writing is enabled in OSX)...

DP:
glquake.h extern void (GLAPIENTRY *qglActiveTexture) (GLenum);
OSX:
gl.h extern void glActiveTexture (GLenum texture);
and
glext.h extern void glActiveTextureARB (GLenum);

[same situation for qglClientActiveTexture also]

[LordHavoc]

Glow is fixed in cvs hey good job

The problems with blooms moving is related to waterscroll, and I discovered this by chance - disabling waterscroll stops the problem. Looks like there are some things going on which are related to each other, but I haven't wrapped my head around it yet.

This means the driver is not paying proper attention to the glActiveTexture calls switching between texture units.

If gl_paranoid is on there are invalid ops, usually only two are often but if the map has textures that do waterscroll then there are more. There is also one straight off that only occurs once while the screen is setup.

Log was like 25MB so I went through and deleted all duplicates to get a single instance of each:

Code: Select all

GL_INVALID_OPERATION at cl_screen.c:1411
GL_INVALID_OPERATION at gl_rmain.c:916
GL_INVALID_OPERATION at gl_backend.c:604
GL_INVALID_OPERATION at gl_backend.c:547
GL_INVALID_OPERATION at gl_backend.c:560
GL_INVALID_OPERATION at gl_backend.c:642
GL_INVALID_OPERATION at gl_backend.c:569
GL_INVALID_OPERATION at gl_backend.c:1331


Unfortunately none of those line numbers match up to my current source, could you redo that with the current DP cvs source?

That's in the order in which they occur. Tried to look for differences in API behaviour between Apple's implementation and a reference (used Mesa) and only found a few things.

Did some benchmarks with all texunits enabled versus setting them to 1 to see if it makes any difference, because there doesn't seem to be any difference at all; and there was none - neither synthetic nor in-game (no diff in FPS). I realize the DP engine is for most part shader-bound by GPU and performance is CPU-limited, but there ought to be a diff. Can you confirm whether there is a performance diff or not?

texture units setting is ignored when using the GLSL renderer (because it is basically meaningless in that context), use r_glsl 0 if you want to see a difference.

If you look at those lines, there are colorfloat err depthmask err blendfunc err, so many I don't have enough experience with DP to judge which is causing what (or not).

So the only thing I discovered was different in the API docs would be this and not sure if it's a factor, (besides initially depth buffer writing is enabled in OSX)...

DP:
glquake.h extern void (GLAPIENTRY *qglActiveTexture) (GLenum);
OSX:
gl.h extern void glActiveTexture (GLenum texture);
and
glext.h extern void glActiveTextureARB (GLenum);

[same situation for qglClientActiveTexture also]

No differences at all there. just syntax and the fact mine is a function pointer because it is not directly linked, and the GLAPIENTRY is nothing on Mac, it's only used on some platforms.

[ds01]

Here's from very latest cvs commit as of Apr24th06:

Code: Select all

^7GL_INVALID_OPERATION at cl_screen.c:1392
^7GL_INVALID_OPERATION at gl_backend.c:609
^7GL_INVALID_OPERATION at gl_rmain.c:922
^7GL_INVALID_OPERATION at gl_backend.c:1092
^7GL_INVALID_OPERATION at gl_backend.c:552
^7GL_INVALID_OPERATION at gl_backend.c:741
^7GL_INVALID_OPERATION at gl_backend.c:565
^7GL_INVALID_OPERATION at gl_backend.c:663
^7GL_INVALID_OPERATION at gl_backend.c:574
^7GL_INVALID_OPERATION at gl_backend.c:1352


As I noted in the other post from Dave the mac user, this last commit (2nd to last I suppose), it broke world dlights (not displayed on map textures, but are shown on models/items) and the glow i.e. in Glow Arena is broken again (was fixed shortly in cvs for ~week previous).

Three maps run shortly and those errs are in order, nexdm01 > 03 > 08.

The depth err happens when the waterscroll make the bloom move as if part of it [on same plane]. The vertex err happens when the glow fails in map dm08. etc

The OSX drivers are like GL 1.5 with 2.0 extensions. They are not garbage they are just very picky Yes it sucks Apple expects extra things be done just would like to know what those are; BTW I've seen the "shadows are broken windows" problem on NVidia Linux drivers when they were circa 1.5 spec.