Jump to content

  • Log In with Google      Sign In   
  • Create Account


isnt opengl to high or to low


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 fir   Members   -  Reputation: -410

Like
0Likes
Like

Posted 26 January 2014 - 03:09 PM

I dont know but when i compare opengl with some higher level 

functions opengl seem to be just to low level making me programming

boring lowlevel things -so i thing it is to low level api On the other side for

lov level maniacs this is probably to high level not giving control over each

possible lov level hardware possibilities... So for me it seems that opengl

is both to low level (taking one philosophy of what it should be) and to high

lewel taking the other philosophy. what are the opinions?



Sponsor:

#2 3TATUK2   Members   -  Reputation: 695

Like
0Likes
Like

Posted 26 January 2014 - 03:19 PM

It's not "too" high, nor "too" low. That can only be assessed on a case-by-case basis of application with specific details.

 

GL provides an essential+necessary functionality. "Higher level" projects are built on TOP of GL.

 

For example, if your goal is to make a game ... Then another project might be more suitable, such as Irrlicht, OGRE, etc.

 

But, GL provides a high level of flexibility and performance, without dictating how certain things should be handled. So if you want to do something a specific way without being forced in some direction by an existing codebase, then GL is applicable. As well as even when using something existing, you can still possibly modify/extend it with GL.

 

Also this might have to take into account your own personal level of ability or experience with development.



#3 fir   Members   -  Reputation: -410

Like
0Likes
Like

Posted 26 January 2014 - 03:37 PM

I think there are possible two points of view

 

1) one that such thing like opengl should be compact

logical not tu much burden of internal details

 

2) that it should be as low level as possible (or

as low level as it counts, it means that taking it to 

lover level will not give programmers more usable

ways of doing things 

 

for sure opengl do not conforms to (1) and I cannot be sure but it probably do not conforms to (2) so i doubt if there is some rational 

ground for that it looks like it looks (for me i must admit opengl

looks ugly and strange) [though i must say i have only some partial

view on this and also readed some opinions, Im far of knowing it

good - so im curious what others can say as to that]


Edited by fir, 26 January 2014 - 03:40 PM.


#4 SeanMiddleditch   Members   -  Reputation: 3487

Like
6Likes
Like

Posted 26 January 2014 - 05:54 PM

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.



#5 mhagain   Crossbones+   -  Reputation: 7328

Like
4Likes
Like

Posted 26 January 2014 - 05:56 PM

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.


Edited by mhagain, 26 January 2014 - 06:32 PM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#6 Promit   Moderators   -  Reputation: 5890

Like
2Likes
Like

Posted 26 January 2014 - 07:35 PM

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.


Edited by Promit, 26 January 2014 - 07:36 PM.


#7 nish_wk   Members   -  Reputation: 185

Like
0Likes
Like

Posted 26 January 2014 - 10:14 PM

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.



#8 Promit   Moderators   -  Reputation: 5890

Like
4Likes
Like

Posted 26 January 2014 - 11:01 PM

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.


Edited by Promit, 26 January 2014 - 11:02 PM.


#9 Ryan_001   Prime Members   -  Reputation: 1206

Like
0Likes
Like

Posted 27 January 2014 - 05:58 AM

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.

 

Seems I'm not the only one who feels this way.  I'm still completely baffled as to why they are so stuck on backwards compatibility.



#10 fir   Members   -  Reputation: -410

Like
-1Likes
Like

Posted 27 January 2014 - 10:13 AM

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 am low level man too, but there seem maybe two kind of low level 

 

 

1) RAW low level when you just have strict acces to hardware

 

2) some managed lov level when you got a lot of complrx idioms of opaque functions to use to get low lewel things done

 

I am not sure (I do not know OGL too much yet) but it seem to me

that OGL maybe gone into second way, This opaque low level is not a thing that i would be crazy for, (thats probably why i must call it 'ugly and strange', though i like simple c flavor of it )


Edited by fir, 27 January 2014 - 10:31 AM.


#11 Aliii   Members   -  Reputation: 1310

Like
1Likes
Like

Posted 27 January 2014 - 11:14 AM

There is OpenGL and Direct3D so you dont have to program using the interfaces the GPU drivers would give you. It has to be higher-level than the API on a console cause it has to work for many different GPUs.

The API is the way it is, but normally you write wrappers around its objects ....so you wont see its arcane functions all the time.

 

Heres a good presentation, ...he talks a lot about why is openGL good/bad. (and rants a lot too).

 

BTW if you want to see a change you are free to talk to the ARB memers and/or be there on the meetings.



#12 mhagain   Crossbones+   -  Reputation: 7328

Like
2Likes
Like

Posted 27 January 2014 - 01:50 PM

BTW if you want to see a change you are free to talk to the ARB memers and/or be there on the meetings.

 

...but don't imagine it will get you that change, because it won't.

 

OK, if you're a AAA studio you can push the hardware vendors for some new extensions and in a few years time they might be rolled into core.  Otherwise - well all anyone has to do is point out all of the online clamouring about the ancient binding model as evidence.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#13 SeanMiddleditch   Members   -  Reputation: 3487

Like
0Likes
Like

Posted 27 January 2014 - 06:24 PM

Heres a good presentation, ...he talks a lot about why is openGL good/bad. (and rants a lot too).


Haha. I did rant a little more than I probably should have in that talk. smile.png

#14 Aliii   Members   -  Reputation: 1310

Like
0Likes
Like

Posted 27 January 2014 - 08:18 PM


Haha. I did rant a little more than I probably should have in that talk. smile.png

 

All the rant-points were legit.

(Thanks for those great talks BTW! ....I really enjoyed the one about game engines and the 8-hour game. I wish I saw that a few years ago:))



#15 phantom   Moderators   -  Reputation: 6652

Like
3Likes
Like

Posted 28 January 2014 - 11:24 AM

Otherwise - well all anyone has to do is point out all of the online clamouring about the ancient binding model as evidence.


Or the shit storm which was the reaction to the OpenGL3.0 announcement after the promises/designs of Longs Peak.

(Yeah, still bitter about that; taking that one to the grave I think...)

#16 TheChubu   Crossbones+   -  Reputation: 3600

Like
1Likes
Like

Posted 30 January 2014 - 07:41 AM

(Yeah, still bitter about that; taking that one to the grave I think...)

 

Methinks you're not the only one :D


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#17 Olof Hedman   Crossbones+   -  Reputation: 2617

Like
0Likes
Like

Posted 30 January 2014 - 08:47 AM

 

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 am low level man too, but there seem maybe two kind of low level 

 

 

1) RAW low level when you just have strict acces to hardware

 

2) some managed lov level when you got a lot of complrx idioms of opaque functions to use to get low lewel things done

 

I am not sure (I do not know OGL too much yet) but it seem to me

that OGL maybe gone into second way, This opaque low level is not a thing that i would be crazy for, (thats probably why i must call it 'ugly and strange', though i like simple c flavor of it )

 

 

I would say there isn't just two levels, "high" and "low", there are many layers of abstraction, and if they are "high" or "low" depends on the context.


Edited by Olof Hedman, 30 January 2014 - 08:49 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS