Comments on: An introduction to OpenGL 4.1 http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/ A technical blog from Daniel Rákos (aka aqnuep) Mon, 16 Apr 2012 23:29:18 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Daniel Rákos http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-802 Daniel Rákos Sun, 21 Nov 2010 12:57:02 +0000 http://rastergrid.com/blog/?p=290#comment-802 ARB_opengl4_core_book => the specification itself I don't really understand why people are not willing to read the specification. Actually it is the best source to learn OpenGL. Besides, if you want to concentrate only on certain functionality, you can read the individual extension specifications. ARB_glsl_ide =><a href="http://lumina.sourceforge.net/" rel="nofollow">Lumina GLSL IDE</a>, <a href="http://www.vis.uni-stuttgart.de/glsldevil/" rel="nofollow">glslDevil</a>, <a href="http://developer.amd.com/archive/gpu/rendermonkey/pages/default.aspx" rel="nofollow">Render Monkey</a> Maybe they are not the most high quality tools but they do the job (personally, I never ever used a GLSL IDE). ARB_opengl4_core_book => the specification itself
I don’t really understand why people are not willing to read the specification. Actually it is the best source to learn OpenGL.
Besides, if you want to concentrate only on certain functionality, you can read the individual extension specifications.
ARB_glsl_ide =>Lumina GLSL IDE, glslDevil, Render Monkey
Maybe they are not the most high quality tools but they do the job (personally, I never ever used a GLSL IDE).

]]> By: przemo_li http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-801 przemo_li Sun, 21 Nov 2010 12:42:07 +0000 http://rastergrid.com/blog/?p=290#comment-801 For me OGL lack ARB_opengl4_core_book & ARB_glsl_ide :) For me OGL lack ARB_opengl4_core_book & ARB_glsl_ide
:)

]]> By: JeGX http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-421 JeGX Thu, 26 Aug 2010 18:01:11 +0000 http://rastergrid.com/blog/?p=290#comment-421 Overloaded is the life of a 3D graphics programmer ;) Will add your nice post to Geeks3D weekly round-up! Overloaded is the life of a 3D graphics programmer ;)
Will add your nice post to Geeks3D weekly round-up!

]]> By: Daniel Rákos http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-419 Daniel Rákos Thu, 26 Aug 2010 06:27:39 +0000 http://rastergrid.com/blog/?p=290#comment-419 <blockquote>It could be nice to speak about this OpenGL C++ wrapper but I don’t think I can commit to one more project as I am doing stuff already with more that I am able to manage… :/</blockquote> I know what you mean as I also always over-commit myself :)

It could be nice to speak about this OpenGL C++ wrapper but I don’t think I can commit to one more project as I am doing stuff already with more that I am able to manage… :/

I know what you mean as I also always over-commit myself :)

]]> By: Rex Guo http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-418 Rex Guo Thu, 26 Aug 2010 05:11:04 +0000 http://rastergrid.com/blog/?p=290#comment-418 Another feature that is still missing is programmable blending stage. ARB_blend_func_extended is hardly useful as the equation is still (a * src + b * dst). A programmable blending stage will allow us to perform free-form arithmetic on it without having to rely on ping-pong buffers. Another feature that is still missing is programmable blending stage. ARB_blend_func_extended is hardly useful as the equation is still (a * src + b * dst). A programmable blending stage will allow us to perform free-form arithmetic on it without having to rely on ping-pong buffers.

]]> By: Groovounet http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-411 Groovounet Wed, 25 Aug 2010 19:16:49 +0000 http://rastergrid.com/blog/?p=290#comment-411 nVidia always details how they support new OpenGL version on this page and this as nothing to do with a press release ;) I am neither an AMD nor a nVidia fan. I'm an OpenGL fan ! Thus I try to always see the thing in the best interest of OpenGL. I like the nVidia OpenGL features, I like the OpenGL API reliability but I don't like the GLSL compiler which can be a such a pain. That's maybe the "we do Cg" legacy and I actually expect the same evolution for the OpenCL implementation because of CUDA. On the AMD side I like what I think is the concern for developers that AMD has, which evolves a nicer GLSL compiler with fairly relevant error messages and let's bless the OpenGL 4.1 man pages and ARB_debug_output. It could be nice to speak about this OpenGL C++ wrapper but I don't think I can commit to one more project as I am doing stuff already with more that I am able to manage... :/ nVidia always details how they support new OpenGL version on this page and this as nothing to do with a press release ;)

I am neither an AMD nor a nVidia fan. I’m an OpenGL fan ! Thus I try to always see the thing in the best interest of OpenGL.

I like the nVidia OpenGL features, I like the OpenGL API reliability but I don’t like the GLSL compiler which can be a such a pain. That’s maybe the “we do Cg” legacy and I actually expect the same evolution for the OpenCL implementation because of CUDA. On the AMD side I like what I think is the concern for developers that AMD has, which evolves a nicer GLSL compiler with fairly relevant error messages and let’s bless the OpenGL 4.1 man pages and ARB_debug_output.

It could be nice to speak about this OpenGL C++ wrapper but I don’t think I can commit to one more project as I am doing stuff already with more that I am able to manage… :/

]]> By: Daniel Rákos http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-410 Daniel Rákos Wed, 25 Aug 2010 18:49:20 +0000 http://rastergrid.com/blog/?p=290#comment-410 Very interesting! It is good to see that NVIDIA is keeping up-to-date the developers that precisely of what's going on with their OpenGL support. I didn't know about it. Btw, it's interesting that GL_ARB_separate_shader_objects is in OpenGL 2. I don't say that it cannot be useful for OpenGL 2 capable cards, still the full power of separate shader programs is obviously unleashed by having OpenGL 3+. Thanks for the information! I suppose you are an NVIDIA fan :) Still thanks for the info, as being an ATI fan I'm not pretty up-to-date with NVIDIA press releases. Btw, we should discuss sometime about the OpenGL C++ wrapper as I remember we had an argument about the topic on the OpenGL forums. And also be assured that GLM has it's own role in this project as well ;) Very interesting!

It is good to see that NVIDIA is keeping up-to-date the developers that precisely of what’s going on with their OpenGL support. I didn’t know about it.

Btw, it’s interesting that GL_ARB_separate_shader_objects is in OpenGL 2. I don’t say that it cannot be useful for OpenGL 2 capable cards, still the full power of separate shader programs is obviously unleashed by having OpenGL 3+.

Thanks for the information!

I suppose you are an NVIDIA fan :) Still thanks for the info, as being an ATI fan I’m not pretty up-to-date with NVIDIA press releases.

Btw, we should discuss sometime about the OpenGL C++ wrapper as I remember we had an argument about the topic on the OpenGL forums. And also be assured that GLM has it’s own role in this project as well ;)

]]> By: Groovounet http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-408 Groovounet Wed, 25 Aug 2010 09:50:20 +0000 http://rastergrid.com/blog/?p=290#comment-408 I guess nVidia is pretty clear about it's support: For OpenGL 2 capable hardware, these new extensions are provided: ARB_debug_output ARB_ES2_compatibility (also in core OpenGL 4.1) ARB_separate_shader_objects (also in core OpenGL 4.1) For OpenGL 3 capable hardware, these new extensions are provided: ARB_get_program_binary (also in core OpenGL 4.1) ARB_robustness ARB_viewport_array (also in core OpenGL 4.1) GLX_EXT_create_context_ES2_profile WGL_EXT_create_context_ES2_profile GLX_ARB_create_context_robust_access WGL_ARB_create_context_robust_access For OpenGL 4 capable hardware, these new extensions are provided: ARB_shader_precision (also in core OpenGL 4.1) ARB_vertex_attrib_64bit (also in core OpenGL 4.1) http://developer.nvidia.com/object/opengl_driver.html I guess nVidia is pretty clear about it’s support:

For OpenGL 2 capable hardware, these new extensions are provided:

ARB_debug_output
ARB_ES2_compatibility (also in core OpenGL 4.1)
ARB_separate_shader_objects (also in core OpenGL 4.1)
For OpenGL 3 capable hardware, these new extensions are provided:

ARB_get_program_binary (also in core OpenGL 4.1)
ARB_robustness
ARB_viewport_array (also in core OpenGL 4.1)
GLX_EXT_create_context_ES2_profile
WGL_EXT_create_context_ES2_profile
GLX_ARB_create_context_robust_access
WGL_ARB_create_context_robust_access
For OpenGL 4 capable hardware, these new extensions are provided:

ARB_shader_precision (also in core OpenGL 4.1)
ARB_vertex_attrib_64bit (also in core OpenGL 4.1)

http://developer.nvidia.com/object/opengl_driver.html

]]> By: Daniel Rákos http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-407 Daniel Rákos Wed, 25 Aug 2010 07:21:30 +0000 http://rastergrid.com/blog/?p=290#comment-407 Yes, direct state access is not anymore that urgent as the nice design of some extensions introduced lately solved most of the problems, however as you said, slowly but inevitably it will get its way to the core specification. You are also right that many of the extensions are features that should work as well on previous hardware generations as I pointed it out also in the article, however I am unsure which one are those that will definitely be supported by previous generations. I said it targets SM5 hardware as it is an extension of OpenGL 4 and OpenGL 4.1 in fact will be 100% supported only by SM5 cards. Still, I agree that this release also exposes a lot of ARB extensions that also target previous GPUs. Yes, direct state access is not anymore that urgent as the nice design of some extensions introduced lately solved most of the problems, however as you said, slowly but inevitably it will get its way to the core specification.

You are also right that many of the extensions are features that should work as well on previous hardware generations as I pointed it out also in the article, however I am unsure which one are those that will definitely be supported by previous generations. I said it targets SM5 hardware as it is an extension of OpenGL 4 and OpenGL 4.1 in fact will be 100% supported only by SM5 cards. Still, I agree that this release also exposes a lot of ARB extensions that also target previous GPUs.

]]> By: Groovounet http://rastergrid.com/blog/2010/08/an-introduction-to-opengl-4-1/comment-page-1/#comment-406 Groovounet Tue, 24 Aug 2010 23:58:30 +0000 http://rastergrid.com/blog/?p=290#comment-406 Oh and I forgot: contrary to your introduction, OpenGL 4.1 doesn't really target SM5 hardware and actually only ARB_shader_precision and ARB_vertex_attrib_64bit are OpenGL 4 hardware features. The rest of them can be used on OpenGL 3.X hardware and some event on OpenGL 2.1 hardware. I actually quite like this. Great article anyway! Oh and I forgot: contrary to your introduction, OpenGL 4.1 doesn’t really target SM5 hardware and actually only ARB_shader_precision and ARB_vertex_attrib_64bit are OpenGL 4 hardware features. The rest of them can be used on OpenGL 3.X hardware and some event on OpenGL 2.1 hardware. I actually quite like this.

Great article anyway!

]]>