I must say it: I was excited by GL_ARB_explicit_attrib_location reading the specs but now I have tested. It is absolutely AWESOME! Please generalize it everywhere, it's a much.
Thank you very very much for the new drivers sub-forum! Finally one good place to dump bugs,feedback and praise!
Any hope of having "precise" qualifier outside of GPU_EXT_shader5 extension i.e. for not fermi and cypress gpus..
it's not good since double precision emulation on d3d10 gpus using
float-float approaches gets optimized by Nvidia compiler!
float-float approaches gets badly optimized by Nvidia compiler!
Example code badly optimized (so not working as expected):
changing vec2 z to precise vec2 z; would fix that!
vec2 dblsgl_add (vec2 x, vec2 y)
float t1, t2, e;
t1 = x.y + y.y;
e = t1 - x.y;
t2 = ((y.y - e) + (x.y - (t1 - e))) + x.x + y.x;
z.y = e = t1 + t2;
z.x = t2 - (e - t1);
vec2 dblsgl_mul (vec2 x, vec2 y)
float up, vp, u1, u2, v1, v2, mh, ml;
up = x.y * 4097.0;
u1 = (x.y - up) + up;
u2 = x.y - u1;
vp = y.y * 4097.0;
v1 = (y.y - vp) + vp;
v2 = y.y - v1;
//mh = __fmul_rn(x.y,y.y);
mh = x.y*y.y;
ml = (((u1 * v1 - mh) + u1 * v2) + u2 * v1) + u2 * v2;
//ml = (fmul_rn(x.y,y.x) + __fmul_rn(x.x,y.y)) + ml;
ml = (x.y*y.x + x.x*y.y) + ml;
z.y = up = mh + ml;
z.x = (mh - up) + ml;
I think there is a little mistake in the specification as pointed here.
At page 104 of openGl 4.0 spec (without compatibility) it speak about how tassellated triangles are created.
It speak about perpendicular lines, but they should be parallel. Only parallel lines (same angles) assure that triangles are similar.Otherwise, for each corner of the outer triangle, an inner triangle corner is produced at the intersection of two lines extended perpendicular to the corner's two adjacent edges running through the vertex of the subdivided outer edge nearest that corner.
~ ~ I tell you, realtime 3D is made of blood, sweat and screams! ~ ~
Pretty much this. HW stuff is always nice, but tweaking api in such ways is really cool - and what GL needs imo. I like how this obsoletes a few functions and removes string manipulation through GL code.Originally Posted by Groovounet
Also having something like GL_ARB_explicit_uniform_location seems like a natural progression.
And something like GL_ARB_varying_uniform_location! (Which nVidia drivers support even if it shouldn't)
That's why I said just "generalized".
I think we had enough of "it's just a trick blabla" in the past. The way the API is designed implies a lot of consequences in the design of the software that uses OpenGL. By itself GL_ARB_explicit_attrib_location well it's "nice" but generalized... it's awesome!
No more query of locations, it's already "known", the C++ program can change the GLSL programs but still use the same ways to communicate with them... Thanks to something like a guaranty actually! In a way this is a more flexible approach than the "program environment object" of Long Peak.
As the design strategy level, the environment object would be the same approach than the vertex array object and generalized explicit location would be the same approach of the long time dreamt vertex layout object. (that show off as the evil VAO in OpenGL 3.0! :/)
Huge wish for OpenGL 3.4 and 4.1!
Guess I missed the memo on that one. You're saying you can set a specific uniform index for the GLSL compiler to use for a normal uniform (not UBO) given the uniform name? How?Originally Posted by Groovounet
Remember this for Cg and the assembly profiles (program env), but never saw it for GLSL.
I meant something like like
In vertex shader:
#define COLOR 0
layout(location = COLOR) in VertexColor;
In Fragment shader:
#define COLOR 0
layout(location = COLOR) out FragColor;
Variables are connected through a number, no need of linking?
For variables between shader stages!
It would make separate shader more sensible (no need to use deprecated build-in variables... (*crap*)).
I actually had a look yesterday and I am not sure the nVidia drivers allows it.
EDIT: Sorry, I meant something like GL_ARB_explicit_varying_location (also GL_ARB_explicit_uniform_location and GL_ARB_explicit_block_index in a way)
Oh, OK. Thanks for clarifying.