PDA

View Full Version : i want a C++(or even STL) compatible OpenGL API!



RAYtracer__ DREAMWALKER
08-26-2001, 02:48 AM
i want a C++(or even STL) compatible OpenGL API!

i'm of the opinion that if openGL is ported to C++ many Direct3D programmers will use OpenGL instead of Direct3D

Bob
08-26-2001, 06:50 AM
What do you mean with C++ compatible? OpenGL can already be used in a C++ environment.

OpenGL is not bound to a specific language. You can use it in any language you like, BASIC, LISP, Fortran, Pascal, you name it, as long as there are bindings to OpenGL.

And by the way, Direct3D is not a C++ specific API, it can be used with plain C aswell. So why does some people uses Direct3D instead of OpenGL? It's certainly not because of Direct3D being "C++ compatible", because both APIs can be used in both plain C as easy as in C++.

john
08-26-2001, 03:35 PM
Howdy,

I agree with Bob. Futhermore, what on earth do you mean by "compatiable with STL"? STL is just the Standard Template Library. Its not a language, but a library that comes with C++. You might as well be saying you want a stdlib compatible version of OpenGL for C.

cheers,
John

opla
08-28-2001, 08:04 AM
I think he means Object oriented by C++ compatible.

exemple :
std::vector<glDisplayList *> myDLvect;
glDisplayList myDL = new glDisplayList();
myDLvect.push_back(myDL);

or

std::list<glVertexArray *> myVA;
myVA.push_back(new glVertexArray());


I'm sure somebody can make a C++ wrapper ...

V--man
08-29-2001, 01:54 PM
OpenGL will almost certainly stay with C for a very long time (I mean opengl itself and not the bindings).

If you want a C++ wrapper, all you have to do is a search. There are tons of them around. Isn't OpenInventor in C++ besides being a scene graph?

One more thing to the OP. You already posted in comp.graphics.api.opengl and got plenty of replies. Try to listen to peoples suggestions.

V-man

NigelStewart
08-29-2001, 06:14 PM
I think it's still early days for
a C++ oriented OpenGL API. For one,
the level of abstraction is not clear -
are we talking about higher level
notions of object heirachies, or just
OpenGL level polygon rendering?

Anyway, this is an are that interests
me, and some results of this thought
are available in the form of a C++
toolkit for OpenGL & GLUT programming.
It's not complete, but already useful.
There are also links to similar projects
from this page:
http://www.nigels.com/glt/

Emanuele
09-16-2001, 12:36 AM
The worst thing could be an high-level implementation of OpenGL. OpenGL is a solid low-level API, written in C (ANSI), right?

So if I write ANSI code I can compile it on win32 ~ linux and _magic_ it runs!

OpenGL is needed, cause its portability, to stay tuned on C (and it also can be used in C++).

Hi, Ema! ;-)

Bob
09-16-2001, 05:34 AM
>>written in C (ANSI), right?

OpenGL is not written in on for any language. OpenGL is a standard, a set of functions. There are bindings for lots of languages, including C.

Meteorhead
02-27-2012, 02:30 AM
I think he means Object oriented by C++ compatible.

exemple :
std::vector<glDisplayList *> myDLvect;
glDisplayList myDL = new glDisplayList();
myDLvect.push_back(myDL);

or

std::list<glVertexArray *> myVA;
myVA.push_back(new glVertexArray());


I'm sure somebody can make a C++ wrapper ...

I have not read DREAMWALKERS prior topic, so I do not know what suggestions he recieved. (if you got a link, I'd read it through) However I would also join him in opting for STL compatible bindings. Please read:

http://www.khronos.org/message_boards/viewtopic.php?f=56&amp;t=4786

The case of OpenCL is very similar to OpenGL in this case. It is a lot younger API, and although implementation is in C, there is a STANDARD cl.hpp wrap to it that is managed by Khronos whenever version is increased. It is no black magic, still very lightweight, but powerful and useful and STL-ready (moreover, it has a more compatible version of vector as cl::vector, but it also supports using homemade vector classes if the proper interface is implemented).

This is what Dreamwalker and I are requesting. OpenGL is just as object oriented as OpenCL, but the bindings seem... very old school. It is really interesting that no centrally maintained C++ wrap has been invented in the past 15 years.

Ideas, suggestions?

Alfonse Reinheart
02-27-2012, 09:52 AM
Why did you feel the need to unearth an eleven year old thread for a suggestion that:

1: Is not going to happen.

2: Wouldn't be useful. I'm a C++ programmer, and I would avoid any sort of texture/program/VAO class. At least, not unless DSA is core OpenGL; you don't want member functions to randomly have to bind stuff just to do their job. And doing the usual constructor/destructor stuff in C++ is dangerous; if someone creates a global texture object, OpenGL won't be initialized yet. And I fail to see how STL is even involved with this.

3: There technically isn't even a centralized gl.h. Virtually every OpenGL loading library provides its own headers that replace the platform-specific gl.h. If the ARB doesn't have a centralized header, they certainly aren't going to have a centralized C++ header.

Meteorhead
02-27-2012, 03:46 PM
To be honest, I did not look at the date, just took a glance at it and thought it was 2009, but actually this proves the point that the need is something new. First of all, thank you for your reply, however:

1: More likely it won't. I was just curious why it hasn't happened.

2: Would be useful, I believe. Having a runtime keeping track of all the handles it has created is a lot more obscure than having clean objects. I do not know what DSA refers to, so an explanation would be welcome. API bindings can be failsafe, but nothing is stupid-safe. I don't have to strain myself to wreck havoc in the C API either.

3: How come that the spec exists but no central C++ bindings exist? Or to be more precise, for all I care, I don't give a jumping jellyfish if the header itself is standard or not. OpenCL 1.2 has a few hundred page spec document, and a roughly 40-60 page spec how the C++ bindings must wrap the C API. All I want is to avoid making homebrew libs (I'm a physicist, and I should be doing physics) and to avoid using thrid party junk that god-only-knows whether they will be kept up to date or not.

If OpenGL has a spec (which it does), why cannot a standard binding be specified and let yet again the vendors make their own .hpp files as they see fit.?

Alfonse Reinheart
02-27-2012, 04:59 PM
I do not know what DSA refers to, so an explanation would be welcome.

EXT_direct_state_access (http://www.opengl.org/registry/specs/EXT/direct_state_access.txt)


Having a runtime keeping track of all the handles it has created is a lot more obscure than having clean objects.

You realize that "Having a runtime keeping track of all the handles it has created" will not magically go away just because you're programming in C++. It's a wrapper, so it is implemented on top of the existing C interface.


How come that the spec exists but no central C++ bindings exist?

Because there aren't "central C bindings" either. There are platform-specific "gl.h" headers, but most people bypass them with glew.h or another loading library (http://www.opengl.org/wiki/OpenGL_Loading_Library).


All I want is to avoid making homebrew libs

Nobody's forcing you to make a homebrew library to use OpenGL in a C++ application. If you do it, it is only because you want to write a wrapper around it.

The C++ police will not arrest you for using a C API. I promise.

Many applications that use OpenGL do wrap it in an abstraction. But the levels of abstraction are always different. And those wrappers are generally bound to other constructs, like resource managers and the like that ensure that resources are disposed of. Your suggestion would not help them in that task; they would still wrap it because your GL++ would be too low-level to work in.

thokra
02-27-2012, 05:05 PM
Would be useful, I believe. Having a runtime keeping track of all the handles it has created is a lot more obscure than having clean objects. I do not know what DSA refers to, so an explanation would be welcome. API bindings can be failsafe, but nothing is stupid-safe.

And how do bindings improve this situation in your opinion? Your GL implementation will still handle every chunk of memory you want it to aquire and you will still have to call specific functions to release said memory. Furthermore, how would you time the initialization of GL objects? Do it when a constructor is called? How do you deal with multiple sets of state? How can you be sure that an object constructed on the app level is already set up and ready for rendering?

In my experience, wrapping OpenGL functionality is much more involved that simply providing a shallow wrapper for a bunch of functions. You can't use any object wrapping GL calls unless a context is created and made current, as Alfonse already mentioned you can't use the destructor most of the time, since GL object may very well surpass the lifetime of local app level objects. If you delete it too early, you will most likely get undefined results or even crash your app. But when is the right time to delete it? What it comes down to is that the app has to do a lot of work that has to be triggered explicitly depending on what is needed at the time. Even if you have every function wrapped, you will still have to make smart decisions about when to invoke what and not simply call an object's convenience functions which do a lot of work for nothing.

The DSA that Alfonse mentioned is short for direct state access and refers to the possibility to change the state of GL objects without first binding them to a specific target, e.g. glBindTexture(GL_TEXTURE_2D, handle). http://www.opengl.org/registry/specs/EXT/direct_state_access.txt shows more precisely what is meant. There were also some vibrant discussions on the topic in this forum.

mhagain
02-27-2012, 07:14 PM
The API is already C++ compatible. You can call it from C++ code. A C++ style API is another matter entirely, and doesn't seem to make sense. Why on earth would the ARB specify two APIs that do the same thing? Better to clean out the junk in OpenGL first before making any moves in that direction.

As primarily a D3D programmer, choice of C or C++ was WAY down at the bottom of any concievable list of factors influencing that particular decision. Tools, documention, driver quality, and general API cleanliness came much higher. They're the issues that need addressing, not C++ifying OpenGL.

Meteorhead
02-28-2012, 10:15 AM
I see that people have joined forces against the idea. I admit I am no expert at OpenGL, I have been fiddling around with it for just half a year from a more practical view. All I was trying to say:

being an OpenCL programmer from the very start of it and the first beta releases (some 3 years ago) I have gained quite some experience in the GPGPU side of programming. Seeing the (I believe) rather big difference in the understandability of the C and the C++ bindings of OpenCL, the C++ is a lot more clean and if I were to teach someone, I'd advise them to start using the C++ bindings. I have nothing against the C bindings (apart from being slightly more verbose in code), I have used it long enough to get bored of coding it.

OpenGL by what I understand from the big picture is VERY much similar, Device Contexts, Render Contexts, Buffers, Programs, etc. I do not see how could the idea of C++ bindings practically start a riot, when there is really no big difference. Naively I would think, it would be easier to learn, and the different types of entities, and the respective places of functions relating to handles would be a lot more clean if there were C++ bindings (not wrapped).

I know I can call the code from C++, but that was never the question.

If someone can point out to significant differences in either function or philosophy of the two APIs, and explain why that abolishes the possibility (or the reason) to create C++ bindings, than I will give you the credit.

menzel
02-28-2012, 11:58 AM
I'm not too familiar with OpenCL, but in OpenGL we have often to bind objects before they can be used. How would a C++ wrapper look like for e.g. textures? Would it bind the texture automatically for you if you want to change the mag-filter? Will it restore the previously bound texture? Will it require you to call a bind() method of that texture first? Sadly, not everything in OpenGL works the DSA way. There are design questions regarding a C++ interface to OpenGL, that can't be answered with a perfect solution for everyone.
You can however roll your own C++ wrapper with your philosophy regarding those details. Most methods would be realy simple and can be inlined by the compiler, so you wouldn't have an overhead. But you must keep the problem with object creation and destruction in mind (you need a context first).

Personally, I like the idea of a C++ wrapper (and I'm working on one despite some problems) but I don't think a general one-size-fits-all wrapper (or official API) would be easily doable. I don't even think that would be something the ARB should waste time on, there are bigger problems / thinks that would help more. DSA alternatives for more functions, reading fragment outputs ( ;-) ), more OpenGL 3.3 like OpenGL ES, conformance tests you have to pass before sticking an OpenGL sticker on your driver so Apple can't get away with there crap... ok, that drifts into a personal wishlist.

The strongest argument against trying to come up with a general, official C++ API is IMHO that the time could be spend more useful by the ARB.

Alfonse Reinheart
02-28-2012, 12:10 PM
OpenGL by what I understand from the big picture is VERY much similar, Device Contexts, Render Contexts, Buffers, Programs, etc.

Similar in concept perhaps, but not similar in form.

Take the OpenCL function that creates a buffer object, for example:



cl_mem clCreateBuffer(cl_context context, cl_mem_flags flags, size_t size, void *host_ptr, cl_int *errcode_ret);


Notice how the function takes everything it needs as an explicit parameter. Specifically, it takes the context directly, which means that `cl_context` is defined as part of the OpenCL specification. Not merely the concept of a context, but the actual object itself.

This function returns a new object, which is of the `cl_mem` type. `cl_mem` is defined as an opaque pointer: a pointer to a struct of unknown definition.

This is basically an object constructor. It is self-contained, affects nothing other than the parameters it is given, and so forth. Simple and clean; this is what a good C API looks like. It's pretty obvious what the C++ version would look like.

Now, let's compare this with the equivalent OpenGL functionality:



GLuint buffer;
glGenBuffer(1, &amp;buffer);
glBindBuffer(GL_ARRAY_BUFFER, buffer);

void glBufferData(GLenum target, GLsizeiptr size, const GLvoid * data, GLenum usage);


Notice the differences. It went from 1 function call to three. It went from a single "create an object" function to "create a name, bind that name to the context, allocate memory in that object".

Also, note that the context has disappeared. It's a global context, an implicit parameter to the function. It's not something that's directly part of the OpenGL API; it's an external thing that's part of the platform-specific API for initializing OpenGL.

Next, realize that this series of functions changes global state. In order to allocate memory for the buffer object, we must first bind it to a target in the OpenGL context. If some other buffer object was already bound to that target, then it becomes unbound. So by binding a buffer at all, you are potentially messing with state someone else owns.

This is not unique to buffer objects; almost every OpenGL function that modifies an object does so by modifying one directly bound to the context. That is the standard way OpenGL operates; only recently have functions appeared that take objects instead of bind target locations like `GL_ARRAY_BUFFER`.

So now, after having created the name and bound it, we can finally allocate memory for it with `glBufferData`.

This overall is a bad C API. It's not encapsulated. It modifies global state needlessly. It has 3-stage object construction, and each of these stages can fire OpenGL errors (which are also global state, not a function parameter).

Imagine class `BufferObject`, which encapsulates a buffer object. If you want to upload some data to it, with say `BufferObject::WriteBuffer` or something, this will modify global state. It has to bind the buffer to do that write, thus evicting whatever was bound previously. Yes, it is possible to query what was bound, store it, and then bind it back again afterwards. But that turns a single wrapper function into a longer series of function calls. And then there are the performance implications of all this binding, which aren't very good.

And buffer objects are the simplest case for OpenGL. Vertex Array Objects (http://www.opengl.org/wiki/Vertex_Array_Objects) may be C's first non-Euclidean API. I'd tell you of the Eldrich Abominations known as texture objects, but it's better that you know of sleep untroubled by such things.

The simple fact is this: OpenGL is a terrible C API. Wrapping a crappy API in C++ is not going to make what you get any better. You're either going to sacrifice performance, functionality, or quality. And likely more than one.

You can certainly do it. But you wouldn't gain anything by doing so.


If someone can point out to significant differences in either function or philosophy of the two APIs, and explain why that abolishes the possibility (or the reason) to create C++ bindings, than I will give you the credit.

In general, if you're going to ask for something, it's a good idea to learn about the current state of that something, rather than make assumptions. It's common courtesy to educate yourself about currently exists rather than just declaring "It should be like this!" It is not our responsibility to educate you on what OpenGL is; that's something you should have done yourself before deciding to ask for something.

We get enough lame suggestions in this forum as it is. We don't need suggestions based on ignorance on top of that.


conformance tests you have to pass before sticking an OpenGL sticker on your driver so Apple can't get away with there crap...

What Apple gets away with? I'm more concerned about what AMD and NVIDIA (and Intel) get away with. AMD with its occasional missing or broken features (sampler_objects were unusable for 9 months after they were supposedly available), NVIDIA with their ridiculous looseness of spec compliance. These hurt more than anything Apple does.

Dardan
02-28-2012, 12:48 PM
I agree with Alfonse :D

And btw, why would you suggest this problem, while it isn't really a problem? I code with C++ and OpenGL a LOT and I never even thought about this.

menzel
02-29-2012, 03:41 AM
[quote]

What Apple gets away with? I'm more concerned about what AMD and NVIDIA (and Intel) get away with. AMD with its occasional missing or broken features (sampler_objects were unusable for 9 months after they were supposedly available), NVIDIA with their ridiculous looseness of spec compliance. These hurt more than anything Apple does.

I personally don't have much bad experiances with NVidia or ATI lately (beside a matrix constructor bug in NVidias GLSL compiler) but found some bad bugs in Apples implementation. But if good conformance tests would show problems with other implementations as well (or at least, provide a good overview of what works on which plattform), thats a big step forwards. Riccio (http://www.g-truc.net/post-0445.html#menu) has a great test set. Something in this direction maybe.

thokra
02-29-2012, 04:02 AM
Never having owned or seriously used Apple devices up until now excludes me from commenting on that, but I definitely have to agree that developing for NVIDIA and AMD hardware isn't fun. Let's leave out Intel - although I have to give them credit because they do a lot of good work for Mesa and push some interesting concepts that Linux will probably benefit from.

NVIDIA notoriously disregards explicit statements and limitations in the spec of the spec which may and most likely will render the algorithm that works on a GeForce useless on a Radeon. For instance, explicit LOD texel fetching works on a chipset I tested without having set the mandatory minification filter. Of course this won't work when using a mostly compliant implementation like the one provided by AMD.

On the other hand, I had to face a bug in layered rendering using Catalysts 11.10 to current, which wasn't present in 11.9 or any NVIDIA driver. I checked the code path over and over, verified the absence of errors and it still didn't work. Essentially, the whole omni shadows approach I used was useless due to this flaw. This is a nice case where standardized conformance tests would have ensured proper functionality.

Meteorhead
03-02-2012, 06:59 AM
Thank you Alfonse for the thorough explanation. I don't consider myself hopelessly uneducated in the matter, so I will not take the offense. I have had bits of graphics courses at university (with OpenGL and DX) and have read dozens of samples, and have had to code smaller applications myself too.

Coming to graphics from the GPGPU side, specially OpenCL for that matter, this globally visible context that only shares close relation to the OS device context is a really troubling concept. OpenCL is a lot more flexible and powerful in that sense. CommandQueuues serve as a really good means of synchronizing your code as well as feeding devices with kernels. In fact, with interop applications I will definately integrate OpenGL routines into this mechanism via clEnqueueMarker and event callback functions that will execute drawing in an asynchronous manner. (Yet again there in an obscure, globally visible commandqueue related to a DC that can be Flushed and Finished, but that's about it) Out-of-order queues are even better, coming close to black magic if used properly.

Anyhow, as you have said, OpenGL is a bad C API, while OpenCL is visibly more flexible. (I know this comes from the fact that OpenGL has been evolving, sometimes having to keep backward compatibility, whereas OpenCL mainly wishes to mimic CUDA with a somewhat more flexible host side API) Having that said, would it really be the work of the devil to suggest for OpenGL to expose more of this type of functionality as part of the API (and do some refactoring also)? It is quite a pain that querying interoperable devices is 40-50 lines minimum of platform specific code messing around with window handles, pixel setups and device contexts. I know these have to be dealt with sometime during writing a window application, but it would be a lot more elegant, if the gl_context type existed that can be cast to HDC or whatever OS specific type.

OpenCL 1.2 brings the accessibility of built-in native functions, such as fixed function H.264 encoders for example. This allows simulation output (forgive me for the example, I am a physicist) to be rendered directly as a movie, allowing for offline analysis and saving HEAPS of HDD space. Also, if render is not fast enough to be interactive, this could serve as a last resort. (Not to mention games could capture movies without interfering with actual gameplay) Now, wouldn't it be nice to render to texture and encode to a movie without any windowing system's intervention? Why do I have to ask for a DC from the OS? (Because OpenGL doesn't have it's own.)

About the phylosophical differences... actual use of VAOs came across my path just last week, but yes this is only a drop in the ocean of state modifying calls.

I am well aware that all of this is a dream, but what really surprises me, is that nobody says that: yes, it would be better. The only one statement concerning this part was that ARB dev time can be put to better use. I am no expert, so I don't know how painful ARB extensions are, so I'll believe whatever you say about this.

Alfonse Reinheart
03-02-2012, 11:59 AM
would it really be the work of the devil to suggest for OpenGL to expose more of this type of functionality as part of the API (and do some refactoring also)?

There have been two separate attempts in the last 10 years to "refactor" the OpenGL API.

Both of them failed. Spectacularly.

The ARB is unlikely to do anything of the kind. The closest thing to a new API you might see would be from ES 3.0, and I seriously doubt that it will go off the beaten path either.

kRogue
03-02-2012, 12:05 PM
The bind to edit has been and continues to be regularly bashed. The OpenGL API is slowly (oh so slowly) making it's way out of it and also to avoid multiple-stage construction (get name, bind name, then create backing store).

As for that the OpenGL context is just "there"... in OpenGL, a fixed thread may only have one context active at a time AND a context may only be active in at most one thread at a time. For what it is worth, having lots of OpenGL contexts is a pretty rare thing... in truth, having more than one GL context is not very common at all...

Meteorhead
03-04-2012, 06:01 AM
Thank you all for your time and posts. Seems like if I wish to keep my code portable across all OSs and platforms I'll have to deal with all of OpenGLs pains. (No perfect API exists, I'm aware of that)

I'm curiuos of what functionality will HSA bring. I have a fear although it being an open standard it will not make it to spread across AMD-Intel-NV-ARM as much as AMD wishes it to. (Although AMD and ARM are sure tu support it) It is said that it is no replacement of OpenCL but more an extension of it. All slides about HSA (formerly knows as FSA (Heterogeonious/Fusion System Arhitecture) speak only about obscure tasks being executed. It seems to me as if it were some highly abstract commandqueue for various sorts of executable (presumably x86-ARM binary, OpenCL calls, hopefully OpenGL too).

Thanks again for the feedback. Should you know more about this last part, I'm welcome to hear any info.