GLSL problems on Mac (really broken now)

[ds01]

I am having trouble uploading the logs to that site, so I'll have to try again later. If you want me to email them to you, my email is on record or just pm me.

Here is a code snip from the first log - unmodified snapshot with the default GLSL code mashed together (both fp/vp).

At first I had forgotten that I split the vertex and fragment code (duplicated the shared code so it's in both), so there's a second log -these things are huge so not spamming the forum.

I just grabbed the first shader output + compile from the log, the code clip here is unedited from it's start to end. It only shows one fp compile after spitting out one each of vp then fp [then the one fp log], but as you see it does include the defines. Why all the logs, in the entire file even - do the same thing: one vertex shader + one fragement shader = one fragment compile log? It sending one each from the list, sequentially, but both to compile as fp? I saw the same thing in the other log too.

[edit: removed the code block - (link to the log is in a post below)]

[LordHavoc]

I think you mean one vertex shader compile log.

The reason it's not printing a fragment shader compiler log is because the vertex shader failed to compile so it didn't even bother trying to compile the fragment shader (which would not work without the vertex shader).

Without going into a lot of detail about GLSL compilation, I'll just say that DarkPlaces makes two shader objects (one for vertex shader, one for fragment shader) and links them to make a program object (the thing that I bind for rendering), the error encountered here would occur on either the vertex shader or fragment shader, whichever is compiled first, because the compiler is simply ignoring the #ifdef statements, so all code for all cases is included at once (which won't work).

[ds01]

Yes I meant vertex compile log. The reason I interpreted the output in the way that I did is for a couple of reasons.

In the error log the first error that main already has a body, well that does not happen if you split the 'builtinshaderstring' into [i.e.] builtinvpstring and builtinfpstring in gl_rmain.c. So if it does it like I think you are saying it does, then it should still have the main error right?

Also, when I split the strings like that it didn't show compile logs for vertex only for fragment. If the conditionals were not working then a main error would be reported, because as you obviously already know there's that "Easter Egg" conditional which would have caused a double main error (but there was no such main err in the fp log).

There must be something else going on here, if the conditionals were broken there would also be a double main err. Well in that case of spliting vp and fp there is no double main err in the fp compile log.

[ds01]

Managed to get the logs uploaded.
The second one qconsole.2.ds.log.gz is the one with split strings.

New Logs

[LordHavoc]

Managed to get the logs uploaded.
The second one qconsole.2.ds.log.gz is the one with split strings.

New Logs

They used to be split in the first place, I merged them to reduce maintenance.

I have greatly simplified the shader yesterday (a lot less #ifdefs and #if defined stuff) and could split it into two files again if you prefer, I merged it to make it more of a unit, since the two parts are made for eachother.

What is certain is that this is a driver bug, we're just not entirely sure what kind of driver bug.

[ds01]

I know they used to be split and realize it must be easier to manage merged I did that to try and narrow the field of possibilites to more easily find the problem over here.

Since there were no GLSL errors printed out to console when using builds before you merged the fragment and shader code and changed the backend compiler, etc. etc. like said before I know a LOT has been done since then, that's why I've been trying different things in an attempt to find the exact issue.

I'm interested in the more simplified GLSL block you mentioned, so I'll keep checking cvs to see if you commit those. In the meantime just got an idea...

Thanks again for your time and patience

[LordHavoc]

Oh I forgot I hadn't committed that yet, I had gotten caught up in a debate over whether USESPECULAR should be optional or always on, ended up deciding to keep it optional, but was too tired to commit it at the time.

Committed now.

[ds01]

Hey it's a lot more simplified hehe.

This funky driver still freaks out on the merged shaderstring (doesn't stop at last VP #endif), so I split it again and then got an error which looks like it gets confused lower down in the fragment shader (it never gets the tempcolor).

Odd you should mention whether or not to make USESPECULAR default, because if I force that to always be enabled (comment out the leading/trailing conditionals around those in the FP) then both the VP and the FP programs compile... but they don't link

Do I need to change something in the code so that the backend compiler knows how to use the compiled objects, or does this look like another driver bug to you?

Code: Select all

^7program link log:                                                                                                                                 
^7WARNING: Vertex shader writes varying 'TexCoordLightmap' which is not read by fragment shader.
^7WARNING: Vertex shader writes varying 'EyeVector' which is not read by fragment shader.
^7ERROR: Fragment shader reads varying 'CubeVector' which is not written by vertex shader.


Thanks.

[LordHavoc]

Do I need to change something in the code so that the backend compiler knows how to use the compiled objects, or does this look like another driver bug to you?

You could make it always calculate CubeVector, although this would be quite pointless for lightmapped surfaces.

Good luck, I'm not sure the driver will even render it right if it's having this much trouble compiling it

[ds01]

You must have given me a lucky clover lol, because I got it working. The bug is the conditionals where it doesn't skip the block when it should even though it stores them. I know it stores/recognizes them, because if you add extra checks then it parses and compiles everything ok.

So I dunno if you want to include this - all I did was add extra checks. Of course it should also work on drivers that actually obey the ARB spec (Yes I am going to go file bug report and report it on the list, not sure when/if it will be fixed.)

Here's a patch against the darkplaces cvs:
gl_rmain.c.extrachecks.diff.gz
[edit: patch updated rev. 2]