OpenGL and Direct3D are both high-level abstractions of the hardware and drivers allowing you to make an application that can port between devices from different hardware vendors or even different operating systems (Direct3D mostly between different Microsoft operating systems only, of course).

OpenGL is higher level than modern incarnations of Direct3D. OpenGL 1 was not designed for anything resembling modern hardware. OpenGL 3 was designed around a number of assumptions about where hardware would go but which did not pan out. OpenGL 4 has done its best to move GL back towards the reality of hardware but Khronos' refusal to break backwards compatibility or to continue using the deprecation model of GL 3.1 (it's sometimes called a "failure" even) leaves OpenGL with a lot of cruft that doesn't directly match real hardware.

If you're trying to learn PC graphics programming, I _highly_ recommend starting out with Direct3D 11. It much more accurately represents how hardware really works and all the conceptual lessons you will learn from it port relatively directly to modern OpenGL. Starting with OpenGL can be really confusing since it's difficult to tell what parts of GL are "good" and which parts are legacy cruft (and this confusion spreads to most articles, books, and blog posts on OpenGL, which in turn will just confuse you even more).

Note that there are lower level graphics APIs. AMD's Mantle is one recently announced. Sony's libgcm (PS3) is another. The version of Direct3D used for native XBox development has a lot of differences to the PC version making it more low-level. Older PC hardware had its own custom APIs, like Glide for Voodoo cards (there were others, though they didn't succeed as well as Glide and they all died out after GL hit PCs and D3D came about). The problem with these lower level APIs is that they are typically very tightly tied to a specific piece of hardware or operating system.

OpenGL is slightly schizophrenic (yes, I know this is not the real definition of "schizophrenic") in this regard.

Early OpenGL was designed around some very specific hardware (of it's time and that no longer exists) and was closely coupled to the capabilities of that hardware.

Mid-period OpenGL became a fairly abstract virtual machine which didn't really reflect what the hardware of it's time was capable of doing or how it worked.

Modern OpenGL is getting back to being more tightly coupled to the way hardware works.

So, early OpenGL is the simple, clean, elegant API that the likes of John Carmack raved about back in 1996. In truth there weren't that many exciting hardware capabilities back then anyway: you could put on some textures, do some limited blending, and that was about all. The entire per-vertex pipeline was typically run in software, so it didn't hurt so much to have to respecify your geometry each frame. The cool kids with expensive hardware got to cache some stuff with display lists, but graphics memory was so tight that you couldn't do too much of this.

Mid-period OpenGL went from about 1998 to 2008. It started small by just adding multitexture, but some bad design decisions were made at the time (and that were carried forward to other features later on) and the API eventually became bloated and overloaded with esoteric features, multiple different ways of doing the same thing, interminable delays on important features making it to the core API resulting in massive fragmentation as it had to be propped up with vendor extensions, and those initial bad decisions coming back to bite as the requirements of those actually using the API (as opposed to thinking abstractly about it) became more complex and demanding.

Modern OpenGL runs from 2008 to the present day. Good, new, important features are coming in, new extensions address much of the mid-period mess, and the deprecation mechanism addresses the "multiple different ways of doing the same thing" mess (even if it doesn't quite work out in practice, at least the existence of core contexts clues you in on the API paths you should be using).

If you're using early or modern OpenGL you may find it too low-level. You just get basic (as in fundamental, not simple) capabilities and it's up to you to put them together in a way that actually does something.

If you're using mid-period OpenGL you may find (parts of) it too high-level. This is the dreaded "switches and dials" state machine with multiple selectors, hugely complex drivers, messy interacting states, an API model that tries (and ultimately fails) to model 4 or 5 different (sometimes wildly different) generations of hardware, and guess what - it's still up to you to put all of this together in a way that actually does something.

If you consider that the "put them together in a way that actually does something" is too low-level, then you've ultimately just chosen the wrong tool for what it is you want to do. No graphics API is going to give you the higher level capabilities you'd need, you're much better off with a pre-built framework or even using somebody else's game engine instead. Graphics APIs need to exist because higher-level functionality must be built on lower-level functionality, and even if you wanted OpenGL to be higher-level (and assuming that the ARB would take up this desire) there would still need to be a lower-level layer under it. Considering OpenGL to be too low-level doesn't mean that something is wrong with OpenGL, it means that something is wrong with the choice you've made and that you need to back off and rethink.

I actually tend to agree with the original suggestion. I feel like OpenGL falls into an awful pit where it is neither low level enough to provide sufficient control, nor high level enough to provide sufficient abstraction. It's just a headache for both. The correct thing would be for it to be more low level, of course. Whether they're making useful progress in that vein... I think the jury is still out.

how low, how high is subjective to from where you looking at . From perspective of game dev I would say its pretty low and that's why writing a solid abstract middleware(not be confused with extension) is must for any medium to high end production. I would like to hear about scenarios while you felt lack of control due to over abstraction by opengl.

That's a much more substantial subject than will fit here, but I can come up with a taste:

* Pretty much everything about the compilation system for GLSL. Lack of sane binary format, lack of control over optimization or even basic compiler correctness, inability to inspect what kind of backend output I'm getting from any given shader, etc.

* Everything to do with asynchronous upload and download with GPU memory. Also highly inconsistent between drivers.

* No exposure of unified hardware memory, primarily on mobile devices.

* The idiotic handle/bind system (GenTextures, BindTexture for example). This has been documented in detail by NVIDIA and AMD as a major performance problem. We're now seeing extensions like bindless, pinned_memory and buffer_storage to deal with this and a few related issues.

* The state machine and state change handling. Direct3D improved this significantly in the transition from 9 to 10.

* The ability to use the same data on GPU as different types of buffers. We're just now seeing this addressed in 4.3.

* A lot of internal garbage surrounding draw call setup. Mantle exists to address this point, and there's some new approaches using MultiDrawIndirect.

* All the really messy performance stuff like GPU pipeline flushes and CPU syncs that make a huge difference and are near impossible to study.