On Oct 18, 2005, at 12:48 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
...so, I think this means we should just have one [shader_program] that can accept one or two names as arguments (vertex shader followed by fragment?), but we would then need some mechanism to determine which one is the vertex or fragment shader...so, I've been just going ahead with making it a message based object, such that you send a [vertex nameOfVertexShader< and/or [fragment nameOfFragShader< to the [shader_program]...then the shader_program will try to link together whatever it has, report what happens, and go on from there...
but does this mean that we can only have 1 fragment-object and 1 vertex-object, while GLSL would support multiples of both (the only restriction ist that there must be one and only one main() routing in both fragment and vertex sets)
so i was thinking of having 3 objects: vertex- and fragment-shader loaders ("compilers") and a linker-object.
does this make the patches unnaturally bloated ?
it would look like
| [GLSL_vertex vertex_main.glsl] | [GLSL_vertex vertex_sub1.glsl] | [GLSL_fragment fragment_main.glsl] | [GLSL] |
(the object-names just came to my mind while typing, so i don't care about them)
and both [GLSL_vertex] and [GLSL_fragment] would have one additional inlet/outlet so you could share shader-objects.
...this sounds fine, but could also just be done with one object that can be created with multiple names, like you did with fragment_program inheriting from vertex_program: the only difference in vertex/fragment shader object creation is what is passed to glCreateShaderObject(): GL_VERTEX_SHADER or GL_FRAGMENT_SHADER...chris had actually suggest the "shader_program" name, but I kinda like putting in the GLSL/glsl_whatever to make it more obviously different from the ARB program stuff, tho pedanticly glsl is "shaders" and arb is "programs" (of course a glsl shader object becomes a glsl program object when it's linked!)...
...then I agree we should have a GLSL_link/bind/program that would be like the soon-to-be-CVSed pix_multitexture, in that it'll accept shader object ID's...the thing here is that I haven't seen examples where more than one of each shader is bound together in one program (not to say that "I've seen it all")...I have seen header files for shaders that include common lists of uniform variables, so I guess these would have to be included somewhere along the line...
otoh, i am not sure what's the fuzz about all those different compiled shader-objects. one thing is that you can keep your (shading) code cleaner and re- use it (as a programmer i mean); so it wouldn't be _that_ bad, if you had to copy everything to one file before loading it into [shader_program]. the more serious question is, whether you can use more distinct complex shaders, if they share modules(==shader objects). so if 2 shaders share 50% of the code and loading both totally separately would exceed the maximum number of instructions, you might be able to load both with the share objects (only 75% (compared to the other option) has to be loaded) is this assumption correct ? should it bother us ?
...yeh, I think it's good to stop and try to get it correct the first time, which is why I didn't just do a similar set of object like the ARB stuff...
...one thing that I REALLY want to add to this (and possibly the ARB program objects) is a way to edit the programs without using an external editor, and this'll be pretty easy to do with the tcl text widget, I'd imagine...then we have a really cool system for playing with GPU programming!
jamie
ps: do your current gl drivers include support for pixel buffer objects and framebuffer objects? If so, I had a crazy idea for multiple_windows where we could just render things to framebuffer objects and then use those for our different windows...