[GEM-dev] Re: GEM shader usage

[james tittle]

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...