Question regarding OGL 4 and 3.3. I have a GTX 280, would that support OGL 4 features, or would I just use 3.3. I have heard reports of DX11 features running on a DX10 card, so that's why I ask.
Question regarding OGL 4 and 3.3. I have a GTX 280, would that support OGL 4 features, or would I just use 3.3. I have heard reports of DX11 features running on a DX10 card, so that's why I ask.
No OpenGL 4.0 for DirectX 10(.1) class hardware. All functions from OpenGL 4.0 that can run on DirectX 10(.1) hardware are available in OpenGL 3.3. Examples of functions that you cannot use with your hardware are the new tessellator control shaders, these are therefore only found in OpenGL 4.0 (and not in OpenGL 3.3).Originally Posted by th3flyboy
And now I'd like to present the most awesome thing in the OpenGL 3.3 specification:
Oh, and FYI: glDrawElementsOneInstance also does not existAre there any other functions in OpenGL that do not exist that the ARB would like to tell us about?
It is funny, but that was my dream that the next release of the standard will include actually two versions: 3.3 for DX10(.1) hardware and 4.0 for DX11. It actually became real! Thanks Khronos!
Also thanks for GL_ARB_draw_indirect that will enable the writing of fully GPU accelerated game engines and for GL_ARB_shader_subroutine to enable modular shader development. Great work!
Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/
How are subroutines different from just having a switch statement calling different function depending on an integer uniform?
modularity
Are there likely to be 3.4, 3.5, ... releases? For example, when 4.1 comes out, will 4.1 features not requiring GL 4 hardware be put in the a core 3.4 spec? I'm assuming (or at least hope) the answer is yes.
Long term, wouldn't this get messy after several major GL releases?
Regards,
Patrick
They could just do it with core extensions. For example, if they have shader separation, they could just make an ARB_program_separate core extension rather than a point release.
They didn't make GL 2.2 just so that 2.1 implementations could use VAOs; they just made a VAO extension.
I've advocated for having more core releases because it clarifies the work that each implementor must sign on for in order to keep pace. IMO in the past there were too few core releases and way too many vendor extensions, leading to a lot of developer issues. Looking at it in the present tense, it's really no big deal if a modest number of extensions appear on top of 3.3, or if a 3.4 were to appear - neither one would result in a change of supported hardware, assuming your set of relevant vendors were to implement the completeness of either path.
Looked at another way, say if there are still some couple dozen features on DX10 level hardware that GL3.x has not yet exposed - (I don't think there are, but just for discussion) - there would really be no harm done to have a 3.4 / 3.5 / 3.6 to address those issues over time, as long as you didn't have to wait a couple of years to get there.
It's been about two releases a year for the last two years, IMO this is a sensible cadence that should continue, in turn reinforcing developer confidence.
I guess I'm saying that timeliness and cross-vendor coherency exhibit more value to me than the distinction between core and extension. An example of this would be anisotropic filtering. It's not in core due to some long standing IP conflict the details of which escape me. Doesn't matter though, because most implementations have it.
I agree with Rob, that two core releases they have now are great. GL3 for DX10 hardware and GL4 for DX11 hardware. And 3.3-3.x anything that isn't covered yet can still be added. Same goes for GL4.0-GL4.x when DX12 hardware comes out in a few years!
Posting Permissions
