About GLSL1.3(or 2.0)

OpenGL
1

I have some thinking for the next version of GLSL.
1>Buid In uniform or int semantics:gl_Thread[];
gl_MultiSyncThread[s:e]
Then the API must has:glGenThreads(GLsizei,GLuint*);
glBindThread(GLenum GL_THREAD,GLuint)
glBeginThread(GLuint)
glEndThread(GLuint)
2>Its add glGenPasses,glGenTechniques,glGenEffects, glBindPass,glBindTechnique,glBindEffect, glBeginPass,glBeginTechnique,glBeginEffect, glEndPass,glEndTechnqiue,glEndEffect as better. In the GLSL as that:gl_Pass[]{}, gl_Technique[]{}, gl_Effect[]{}, gl_VertexShader[], gl_GeometryShader[], gl_FragmentShader[], gl_SamplerShape{} 3>Add the Fractal of vector type,e.g: vec4<4> v4Stream;//4 as the depth of the fractal and any element of the fractal level is type vec4 vec4 va0[8]=v4Stream.x.xyzw.xy.xyxy; vec3 va1[3]=v4Stream.wzyx.xyz; mat4 m4=v4Stream.xyxy; That may be add gl_MaxFractalDepth for GLSL 4>Add the time field used for animation in GLSL: gl_FrameField<int start,int end,int step>//It must increment auto by openGL-Drivers 5>Add framebuffer and renderbuffer,like this: gl_FrameBuffer[],gl_RenderBuffer[],gl_TexBuffer[] 6>Its best add geometry stream object:
varying out uint gl_GeometryShape{}
varying out int gl_VerticesOut;
varying in int gl_PrimitiveIn;
varying out int gl_PrimitiveOut;
e.g
uint outGeoBlock=gl_GeometryShape{
gl_VerticesOut=…
gl_PrimitiveOut=TRIANGLES_ADJACENCY;
}
7>Add the virtual field for user defined:
gl_FieldShape<fun/or struct Name,shader>.
e.g
void vortex(sampler3D vorField)
{
gl_TexCoord[0].s=texture3D(vorField,texCoord.p).t-texture3D(vorField,texCoord.t).p;
gl_TexCoord[0].t=texture3D(vorField,texCoord.s).p-texture3D(vorField,texCoord.p).s;
gl_TexCoord[0].p=texture3D(vorField,texCoord.t).s-texture3D(vorField,texCoord.t).s;
}
uint vortexField=gl_FieldShape<vortex,gl_FragmentShader[0]>;
…
GLuint vf=glGetFieldLocation(proc,“vortexField”);
glBindField(GL_FIELD,vf);
…

2

  1. What would this do? GLSL programs are asynchronous anyway, so what would you do with threads?

  2. This has been discussed many times. GLSL is a shading language, not an effect framework. Something like that can be built on top of GLSL, so it should not go into GLSL.

  3. Huh?

  4. Sounds like you’re lazy. You can do this yourself, just use an uniform.

  5. What would this do?

  6. Ever heard of geometry shaders?

  7. Huh?

I’m sorry, but most of your suggestions consist only of some keywords that you would like. I can’t read your mind, so I don’t know what you really propose. But most of the thinks sound either like some shortcut that’s not really needed, or just something that’s a long way outside the scope of GLSL.

To get constructive feedback, you should discuss features here, not just throw a huge list into the forum and say “I want these”…

Also, when thinking about new features, always keep in mind that these things have to run on actual hardware. A feature that can not be done by hardware in the near future is useless.

3

Oh a brainstorm topic. Here are my suggestions:

Sometimes there are optimizations problems with dynamic branching. In wost cast, a coder adds some lines to a shader and it runs much slower then without that optimizing line.
An Example (pseudo code):

void main(void){
   for( int light = 0; light < 8 ; light++){
       if(SHADOW_OR_BACKFACE_SKIP_LIGHT_CONDITION)continue;	
CALCULATE_LIGHNING[light];
       }
  }

The problem is that the continue is only optional. If it’s skipped it wouldn’t change the calculated result (depend on the code !).

An own shader (8 lights with dual parabolic shadown and anisotropic material) has that results:

281 instructions without the if-continue
336 instructions with if-continue but no dynamic branching in the compiler output.
362 instructions with a if construction around the lighting, it calculates exactly the same like the other both variants (but in this version are dynamic branches, so that effective 50% code could be skipped)

The 3rd version may be faster than the first, but the second version is fatal: The coder says skip that stuff if it’s zero, but the compiler wastes instruction for a antioptimization.

The problem is that the compiler don’t know if a dynamic branch is optional (can jump) or not. In both cases it’s alway the question if a dynamic or static variant is faster.

So the idea:
More arguments value (or somethin similar) for if:

if(bool condition, float probability [0.0 … 1.0], bool optional)

the compiler could compile all variants and choose the fastest.
For example a very short optional condition, with a high probability, should never be dynamic, but skipping a light with 3 texture lookups for a BRDF and many instruction should be skipped if the probability is only 0.5 (50%)

4

“if(bool condition, float probability [0.0 … 1.0], bool optional)”

This is weird to me.
I prefer a compiler that does exactly what I tell it to do.

Threads in a shader? Ok, let’s wait for shaders to become ultra sophisticated first and the hw becomes matured.