NVIDIA Updates its OpenGL SDK
I must say I saw better updates than this one. This new OpenGL SDK contains, at first sight, only one sample (an OpenGL 4 tessellation demo) and bad luck, it has a little problem (at least with recent drivers). If you launch the demo (simple_tessellation_shader.exe) you’ll get the following output (on my GTX 680 with latest R310.90):
Supports glsl include Compiling vertex shader Compiling tessellation control shader Tessellation control info ------------------------- 0(22) : error C7593: Builtin block member gl_Position not found in redeclaration of out gl_PerVertex Compiling tessellation evaluation shader for plane Tessellation evaluation info ---------------------------- 0(25) : error C7593: Builtin block member gl_Position not found in redeclaration of out gl_PerVertex Compiling tessellation evaluation shader for torus Tessellation evaluation info ---------------------------- 0(21) : error C7593: Builtin block member gl_Position not found in redeclaration of out gl_PerVertex Compiling fragment shader Failed to compile all shaders, exitting
The demo uses separate shader objects (GL_ARB_separate_shader_objects) and activates the GPU program with glBindProgramPipeline() and glUseProgramStages(). When separate shader objects are used, you have to redeclare in the shaders the gl_PerVertex structure as said in the spec:
To use any built-in input or output in the gl_PerVertex and
gl_PerFragment blocks in separable program objects, shader code must
redeclare those blocks prior to use. A separable program will
fail to link if:
* it contains multiple shaders of a single type with different
redeclarations of these built-in input and output blocks; or
* any shader uses a built-in block member not found in the
redeclaration of that block.
So I tweaked a bit each shader (the download is available hereafter) and added few missing gl_PerVertex redeclarations and I get this nice tessellated torus:
You can download the updated sample here (left-click to grab the file):
You can find more information about NVIDIA’s new OpenGL SDK here: Introducing New OpenGL SDK Samples.
One large change evident to anyone who has looked at our SDK in the past will be in the shaders. First, all shaders are now in GLSL, instead of the mix of languages supported previously. Additionally, we’ve moved to extensive use of shader includes, separate shader objects, and uniform buffers. Using separate shader objects simplifies mixing and matching shader stages, which previously required linking all desired combinations when using GLSL. Next, the “layout” qualifier allows our shaders to directly specify their desired environment. Previously, there was a lot of reflection required to just setup the correct bindings for textures and vertex attributes. Now, all shaders specify this explicitly in the code. Finally, and possibly most importantly, shader include plus the uniform buffer objects, allows the SDK code to share uniform data definitions not just between shaders, but also with the C++ program. By specifying the uniform buffer definition in a header and relaying on a few special type definitions, we can have a struct that directly matches the layout of our constant buffer. From here maintaining and updating state is greatly simplified.
Another big change that you’ll notice is that our UI has been converted over to path rendering. This means no more bitmap fonts that scale poorly. The new path rendering extension in the driver is really great for a lot of UI work, and you can definitely do some pretty complex text rendering with it. This isn’t to say things are fully changed over. The text has already moved, and you will see more things in our UI code move toward path rendering as we make additional updates.
Finally, we decided to stop using GLUT as the basis of the SDK. It has served us well for a long time, and we think it can continue to serve others well. We have replaced it with GLFW for windowing, as it offers a couple other things we were looking for. As you will notice, we do not use it directly, but wrap it in our custom SDK framework. The main reason here is to provide some additional portability, for when we decide to support additional platforms GLFW does not handle.
Source: Geeks3D forum