pouët.net

Current ( >= 3.3) OpenGL - some questions.

category: code [glöplog]
@w23

the #version directive inside GLSL shaders is defining the GLSL version used, but it's true that if you get a 3.30 context you can assume that GLSL 330 is supported as well in hardware. It doesn't prevents you to use different versions of GLSL for different shaders (which is in fact good, if I use a specific hardware feature of GLSL 330 in only one shader, I'd like that other shaders keep compiling on older hardware without any significant development effort for instance, and then I'm free to use a backward compatible and simpler method for the incriminated shader/codepath). So you can have all kind of versions of shaders on the run, it's only the GLSL parser's/compiler's issue.

btw, I really enjoy the fact that GLSL 330 has implicit int<->float cast like HLSL :) I use/abuse it nowadays. :)

@KeyJ gl_VertexID is supported in all GLSL versions according to this documentation page. Thanks for the info about context creation.. :)
added on the 2012-01-23 16:20:27 by nystep nystep
May I ask if someone who has an actual AMD card like to test if glCreateShaderProgramv is implemented and functional in the latest drivers?
added on the 2012-01-23 16:43:25 by nystep nystep
@nystep
on osx, when you have a 2.1 context and you write "#version 1.30" or greater, you get nice errors like "NO, I CAN'T! STOP IT!".
added on the 2012-01-23 18:09:22 by provod provod
I also want to know what nystep asked for (especially without calling wglCreateContextAttribsARB). Does it work on current AMD drivers?
added on the 2012-01-23 21:39:34 by las las
Recent news from the mercury research labs:

Code: [...] call _wglMakeCurrent@8 %ifdef DEBUG push GL_VERSION call _glGetString@4 DBG 'VERSION:' push eax DBG_STR DBG '' %endif [...]



NVIDIA (290.53 beta).
Quote:

VERSION:
4.2.0


ATI/AMD (Catalyst 11.12 / HD 6670).
Quote:

VERSION:
4.2.11318 Compatibility Profile Context


<3 to manx who sacrificed time testing this on ATI/AMD.
added on the 2012-01-23 22:02:50 by las las
a bit off-topic, but... you guys claiming that the overdraw in the diagonal pixels of a screen (which would count for less than 0.2% of pixels, or less than 2.0% of wasted fillrate assuming 16x16 pixel tiles) does really matter at all for the baste majority off cases/demos? you must be kidding...

size wise, drawing two tris might be smaller than one tri, or not, depending on too many factors, including the content of the rest of the intro code. this reminds me that i remember having people spending weeks optimizing 4k intro frameworks without any "intro", having only the framework without any other context, which is useless. you better have alternative implementations for usual operations and try them all AFTER you have nearly completed your intro and have context (try "edit" and "static", both, none is better per-se). aaaanyway, i shut up now.
added on the 2012-01-24 06:20:26 by iq iq
I consider this the iq version of "make a demo about it" :).

@Iq:
Quote:
...majority off cases/demos

Nope. :)

Quote:
you better have alternative implementations for usual operations

ACK.

goto _topic
added on the 2012-01-24 08:00:45 by las las

login