I have previous experience with writing shaders and rendering but I never really learned OpenGL. I have recently decided to start working on my own graphics project, hopefully being able to expand that into something bigger if my ideas work out, but I'm not sure if it'd be worth it to start right now.

Just to give some info on what I'd like to do, I would like to generate most of my content on the GPU, so that means I'd be using gpgpu and probably compute shaders with very modern (4.3+) OpenGL at the minimum. I'm targetting high framerates with very low latency because I'd like to try to get things working well on an oculus rift at some point, and I'm assuming that that would mean modern topics on reducing driver overhead and latency would also be relevant.

My dilema right now is that I'm not sure if it would be wise or even worth the effort(and pain) to learn the 800+ page core specification, dig around and try to figure out the current best-practices for azdo and gpgpu (and cross my fingers that any of it is actually supported properly) and all of that while there's a completely new specification on the horizon that is supposed to address these things.

Any thoughts and resources would be helpful.

What exactly does OpenGL NG offer that you are going to take advantage of that is not currently available in the latest version ( 4.5 ) as of this post ? There is alway doing to be driver overhead, unless you have direct access to the hardware...most of the technique to lower driver overhead and whatnot is currently available in the latest GL version..My silly advice to you is to learn the API first instead of waiting for features that you may/may not use.

I'll qualify this post first by stating that I know very little of OpenGL NG. That said, I think investing in OpenGL 4.3+ at this time is still a good move.

First, it sounds like GLSL syntax may not change much, we're getting a new standardized intermediate format which is long overdue but your shaders may require little (if any) modification for the new version.

Second, learning how to reduce OpenGL driver overhead means learning about how the hardware works. This will serve you well regardless of API, and using these techniques you should be able to get performance pretty close to what a lower level API would get you. Plus you should have the advantage of wider hardware compatibility.

Third, you know that claiming you would need to learn an 800+ page specification is gross exaggeration, right? There's a ton of stuff you won't need for your application, even in core profile. Also, I know it looks like there's a lot of functions but remember a ton of those are OpenGL's version of function overloads. The "real" API isn't that scary.

For my use I have my GL code wrapped up in a (simplified) D3D11-style device/context interface so they look identical to my renderer. This helps break the API usage into nice bite-sized chunks that are easy to understand. I'm also using hard-coded shaders to avoid HLSL/GLSL translation issues at the cost of some flexibility.

Finally, I noticed UE4 is basically wrapping IOS 8's low level Metal API in a higher-level manager that makes it behave a bit of more D3D11, which sits just under the RHI, and they're still getting huge performance gains.

What exactly does OpenGL NG offer that you are going to take advantage of that is not currently available in the latest version ( 4.5 ) as of this post ? There is alway doing to be driver overhead, unless you have direct access to the hardware...most of the technique to lower driver overhead and whatnot is currently available in the latest GL version..My silly advice to you is to learn the API first instead of waiting for features that you may/may not use.

There really isn't a lot of information out right now, but the next generation OpenGL initiative is a ground-up redesign that [paraphrasing] aims to streamline the api for easier use and implimentation, act to unify and bring modern GPU access to all platforms, provide a standard intermediate shader format for greater portability of shader programs, provide enhanced conformance testing methodology, provide explicit application control over GPU and CPU workloads, be multithreading friendly, greatly reduce CPU overhead and provide full support for tiled and direct renderers.

It will not be backwards compatible with the old specification, which has been bulking up for over 20 years, and that's really what I'm trying to ask - is it worth learning at this point? I've read a lot of criticisms of the current specification (see: http://www.joshbarczak.com/blog/?p=154 and http://richg42.blogspot.com/2014/05/things-that-drive-me-nuts-about-opengl.html ), and they're not alone it seems.

As someone who wants to work with primarily the modern parts of OpenGL (for both computing and managing lots of data asynchronously), it's difficult for me to parse through what's an old part of the specifcation, what's newer and a better practice, what examples are using pure legacy code and should be avoided, what extensions are available and what are appropriate to use... the books that I can find only go up to OpenGL 4.3 but there are some major additions to the core profile in the past few years (direct state access, buffer placement control, efficient asynchronous queries, efficient multiple object binding, flush control...) that I could see causing significant changes to how someone manages their project. I've been reading through the sixth edition of the OpenGL superbible, one of the most up-to-date references I could find for getting started (published last year), and it's still hard to trust the format that's provided.

I understand that I wouldn't _have_ to read the entire 800+ page specification, but at the same time I sort of would. At the end of the day you really don't know what you don't know and with something that's been around as long as OpenGL has and is as quick of a moving target, it's difficult to trust what you're doing without going through the entire spec first. If anyone knows a trustworthy and well up-to-date and informed source for learning, including the current best practices, that would be super helpful.

@Hodgman No I don't know any graphics API at the moment, the experience I have is mostly limited to shading languages like GLSL and some math and theory behind light and rendering, reading papers and things like that.

I'd love an api to mess with and try implementing ideas, I just wanted some guidance before digging too deep and regretting it, but I think you're right about getting over the first one and the future ones being easier to pick up.

If that's the case though I'm not sure, should I necessarily start with the current OpenGL?. What would be a great "baby's first modern graphics api"?

edit: @swiftcoder

This is different than the 3.0 stuff which had legacy support. I believe the new api will represent a clean break from the current OpenGL, and they appear to have the major companies and hardware support behind it.

You have the choice of using an API that is readily available and works (with some annoying quirks, but it does work) just fine for thousands of applications, including high performance ones on the one hand side, and using an API that may be laid down in 6 months or a year and that may change, and which will not be supported before a long time in the future.

OpenGL as it is maybe not perfect, but it is still very capable and (some quirks and personal feelings left aside) entirely sufficient for what 95% of all people are doing.

Insofar, it is somewhat nonsensical to even think about waiting for NG. Produce now, on an API that works. Not maybe in a year, on something that may not even exist.