thoughts about the GLSlang spec.

I asked a bit about this in the Opengl2.0 forum on 3dlabs site, but the action there is quite slow ( i got some response from 3dlabs in a few questions so its not all silent, but nearly )

  1. The spec doesnt have inverse or transpose of the common matrices. I know that its pretty easy to make this myself and upload in some variable, but the driver has this information, and i bet that the driver developers more often take advantage of SSE2 and similar than the average opengl developer, and since the driver are forced to make this matrices when you have vertex_program i cant see why it couldnt follow into the GLSlang spec.

If your application is split between an exe and a dll, and both are allowed to make glrotate/translate/loadmatrix and similar calls, you ( the application ) never knows if it has to create the inverse again or if the last one still is valid, and that means glGetFloat() to get the current matrice, inverse, and upload… that might work on consumer cards, but if you have a full set of matrice operations in sillicon ( doenst some workstationclass card have that?) it could cause a stall each time.

Is every one here on the spec side and thinks that the developer should be responsible for keeping the inverse and trasnpose of the matrices updated? I whould just like to know why its not there, and not even an ‘issue’ remark in the spec about it.

  1. none if the ‘shaders’ ( like the call it now) have any kind of header, you know the “!!ARBvp1.0” and “!!ARBvfp1.0”. Some might think that its unnecessary since you still need to state the programtype when you upload it, but i think its as smart as creating a new imageformat without a header, and let the user choose from a list when you load it… If you want a simple load function to load the files and place them in the correct shadertype you must invent your own tagging ( .ext or a commented row with your own header) and that means that we cant get a compatible format for the marking.

any comments? from developers, and maybe the ARB members ( still no meetingnotes from that meeting )

/Mikael

I agree with you.
And certainly most others will do, too. But maybe they didn´t think of it in the first spec. And those specs are not final afaik. So, there will certainly be a shader-header and the inverse-matrix, etc.

But the thing with the exe and dll rotate/translate issue is not really important, i think. Such a case is certainly quite rare and it can be solved if the design of the application is well thought-through. Therefore i see no reason to include anything into the gl for such a case.

Jan.

Ok. I understod it as the spec was approved by the ARB in the last meeting and that the spec on 3dlabs site was the final.

must have been misslead by this http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009868.html

[add:] and about the example, isnt that how most pluginbased engines would handle things? but feel free to ignore the example

[This message has been edited by Mazy (edited 07-23-2003).]

Oh, sorry, i didn´t know, that this spec was final. I looked into that specs over a year ago and thought they hadn´t decided about it, yet.

But hey, you can still hope that they will add it (the first extension for gl2? :wink: )

About that dll stuff: As i said, the engine design has to be clever. For example the engine could give the dll functions to translate or rotate instead letting it use OpenGL directly (as long as the dll sticks to that restriction).
This way the main engine can keep track of those rotations and translations.
Or the dll could call an “updatematrices” function, when it changes anything.
Of course how it is handled depends on the actual application, but it is possible.

But still i have to admit, that i totaly agree with you

Jan.

Do your C++ .cpp files have a “!!C_PLUS_PLUS” at the top? No. Nor should they. Because programmers are smart enough to call the right compiler (and we have IDE’s to make it virtually impossible to do the wrong thing).

Shaders aren’t data; they’re code. And they should act like code.

Also, note this: consider that vertex and fragment shaders have access to very different variable sets. If you try to compile or link a vertex shader as a fragment shader, you will know, because the compiler will give you an (hopefully detailed) error. Like, “Parameter X on line Y cannot be accessed in a vertex shader.” Which is enough to tip you off to using fragment shaders as vertex shaders.

The same goes for the ARB versions, but they didn’t see it that way. 3DLabs did.

@Korval
How many C++ applications have you written, which write, compile and execute C++ code while they execute?

Shaders are very different from traditional code in that they’re often written/compiled/executed on the fly. There are already numerous vertex and fragment shader profiles around each with their own limits on instructions, contstant registers and temporary registers. Including the profile type as a header to better keep track of these limits is a small ask and one that is sure to help many developers.

Having an identifier in the header strikes me as simular to the unix script convention.

!/usr/bin/perl

It’s easy enough to put a comment on the first line for this purpose if you need it though.

I know that its easy to make my own commented header, but then it will be my format, not a standard one. And the same group of people thought that it was a good idea in the vertex/fragment programs, so why not in a higher level one.

C/C++ has another way than a header to figure out what file it ies, its .ext based, not a demand but more or less a defacto standard. And for programming languages - Delphi has either Program or unit as the first uncommented word in a file.

I also know that you can test to compile it twice ( once as a vertexshader, and if that fails as a fragment) but how do you then know if its an error in a vertex or fragment program if both failes? the programer might have done a bad job you know . this is for example very helpfull when your doing tools for shaders.

And still, dont forget the matrices question here, that is perhaps even more important. I know that it can be done by the developer, but since vertex/fragment program already have this i bet the optimizations in the driver are pretty good, and it would ease the change to GLSlang from *_programs, since you almost only need to replace the program itself, not much code around, except for grabbing the inparams placenumber.

And the same group of people thought that it was a good idea in the vertex/fragment programs

Oh, I wouldn’t say that.

3DLabs has been pushing glslang hard. They don’t care about the two ARB*program extensions; they wanted glslang (mainly because their hardware is better suited to it, but that’s an aside). As such, when someone proposed the prefix for the two assembies, they probably didn’t raise an objection. But, when it may have been proposed for glslang, they probably jumped all over it, citing precident in C, C++, and various other higher-level languages.

And for programming languages - Delphi has either Program or unit as the first uncommented word in a file.

Neither Java, C#, or VB has any kind of prefix. Lua doesn’t either, nor does Perl. I can go on, if you like. There are plenty of examples on my side.

I also know that you can test to compile it twice ( once as a vertexshader, and if that fails as a fragment)

You do realize that you should already know what kind of shader it is when you acquire it from wherever you’re getting it from. It’s not like loading textures, where you’re going to iterate over a file and just start loading objects. They’re shaders. You should be building programs, which reference shaders. The program says, “Use vertex shader 1, 2, 23, with fragment shader 6 & 9”, and these “indices” would map to files or an index into various files, or something of that nature.

but how do you then know if its an error in a vertex or fragment program if both failes?

I’ve already taken issue with the notion of even compiling it twice. However, if you want to use that as a method of telling one from another, and it fails both, clearly the shader doesn’t work. So, throw an error.

but since vertex/fragment program already have this i bet the optimizations in the driver are pretty good, and it would ease the change to GLSlang from *_programs, since you almost only need to replace the program itself, not much code around, except for grabbing the inparams placenumber.

There are good arguments both for and against this operation (the arguments against are mainly to keep people from binding to paramaters that are not built into the API itself. What does the inverse mean if the matrix is not invertable?). However, one thing you should understand is this: glslang is not the “sequel” to ARB_*_program. It was devised before either of those extensions. After all, the original API for attaching generic attributes didn’t use anything from ARB_vertex_program. So, it’s easy to see how glslang isn’t a functional superset.

With teh same group of people i meant that both specifiations are approved by the ARB and they doesnt change members frequently.

And ok, you have more examples of ‘unheadered’ files, but almost all of those have a defacto .ext standard (actually, java must be named .java for the compiler, and vb have a set of different .ext that are forced by the IDE), so i hope that will come to these shaders as well. But your right, there are ways around this, its just that it should be convinient to have it. ( just like GLSlang is more convinient than *programs )

And for the moment you cannot have multiple shaders of the same kind in one program, and im a bit worried by an answer on 3dlabs forum, by a 3dlabs employee when i asked about how different shaders of the same kind should cooperate in one program
-“I believe the intent is that function calling semantics will be employed”.
It doesnt look like they thought that through yet

And even if its not a superset of *_programs they do refer to, and often chooses the *_program way of doing things in the GLSlang spec, so why break that on this? same here, its ways around it, but it should be convinient to have it. None of these questions are even in the Issues part of the specifications, so we have no answer on why they left it out, or even if it was discussed.

[This message has been edited by Mazy (edited 07-24-2003).]

Originally posted by Korval:
[b]Do your C++ .cpp files have a “!!C_PLUS_PLUS” at the top? No. Nor should they. Because programmers are smart enough to call the right compiler (and we have IDE’s to make it virtually impossible to do the wrong thing).

Shaders aren’t data; they’re code. And they should act like code.
[/b]

No, you don’t see “!!C_PLUS_PLUS”. (Though you do quite frequently see warts like

#ifdef __cplusplus
extern “C” {
#endif

which are arguably serving a similar purpose.) But that’s not to say it’s a bad idea. The C++ language newsgroups generate an awful lot of heat whenever a proposed change might silently alter the meaning of existing code, precisely because there’s no way for the compiler to reliably determine which version of the language code was written for. Specifying this sort of thing on a per-file basis via compiler flags is messy, error-prone and nonportable.

And that’s C++, which was made an ISO standard and, as such, guaranteed not to change for at least 10 years. Hopefully, although on current evidence not necessarily, glslang will evolve rather faster than that. A better analogy might be with the major XML technologies (XSL/XSLT is almost precisely a “shader” for XML data) - they also evolve pretty fast and have all chosen to version themselves using namespaces.

I agree with Korval that identifying vertex vs fragment shader is fairly pointless, but support for versioning ought to be a no-brainer.

Just my 2 pennies. Though anyone who disagrees with them is clearly Quite Simply Wrong :wink:

Originally posted by MikeC:
I agree with Korval that identifying vertex vs fragment shader is fairly pointless, but support for versioning ought to be a no-brainer.

FYI… There is a ‘VERSION’ predefined preprocessor macro, so you could surround your version-specific code with ‘#if VERSION > xxx’ blocks.

bashbaug - thanks, I’d forgotten that.

Although I do still think that it would be cleaner to have the shader saying what version it requires, rather than (or as well as) the compiler saying what version it is. It would avoid having to duplicate boilerplate version compatibility checks in every shader.

(I also think that deliberately copying the C preprocessor syntax in a greenfield language was insane, but that’s a lost cause…)