Curious to who is sticking with OpenGL now...

[remdul]

I will for cross-platform reasons.

I do admit that I secretly hope for a new and fresh, true Open cross platform alternative...
Maybe I'm just dreaming, but surely there are plenty of smart people around here now who can write up a 'real' spec for an alternative API ('fork' GL)? Not that it's easy to get vendors along, but hey you have to start somewhere? Vendors have to open up more and more these days...

I mean, if we declare GL dead, there _has_ to be a cross platform alternative in the near future.

[Simon Arbon]

KORVAL: If it was a choice between OpenGL and DX then i would definately choose OpenGL as i have always found it more intuitive, and yes i do like it.
I can churn out OpenGL code fairly effortlessly, but with DX i find myself continuously having to look up the documentation to find how to do something.

Thats not to say i wouldn't switch if someone came up with something better, something like longs peak for example...
Perhaps a new Open3D cross-platform API with added sound, physics, and a language-neutral OpenCL.

We could always write our own API that uses OpenCL as the GPU interface, or get NVIDIA to release hardware specs like ATI did.

[bootstrap]

I have been so busy working on projects, I am way behind the curve on many issues directly and indirectly related to the future state of fast/realtime 3D OpenGL applications. I should also admit (cuz I forgot to previously) that I switch to OpenGL almost exactly when VBOs and FBOs became available, so I am totally oblivious to (read "ignorant of") the problems of OpenGL developers with pre-VBO/FBO engines/architectures/infrastructure.

Anyway, I had also not read anything about CUDA for a long, long time - since the information was vague handwaving. Well, I'm almost half way through a quick skim/read of the cuda programming guide and what do I begin to notice? Well, it appears CUDA has an extremely clean, convenient and efficient connection to OpenGL buffer objects. In fact, at first glance, the interface to OpenGL looks cleaner/better than D3D (? surprise, surprise ?). But that's not the point. The point is, for those several/many people driven nuts by lack of geometry shader support, CUDA seems to provide an excellent (faster, cleaner, more flexible/general/capable) alternative to generate geometry - by spewing procedurally generated geometry straight into VBOs, FBOs, textures!

Since I *am* behind the curve, I may be missing some gotchas. So please set me straight (Michael Gold or anyone who is "ahead of the curve"). For example, perhaps CUDA setup/breakdown and/or CUDA/OpenGL interoperability has too much overhead. From my brief read/skim, however, that doesn't appear to be the case.

This experience has made me *just begin* to seriously grapple with a set of potentially important questions *** for those of us "stuck" with OpenGL *** by inertia, preference, stubbornness, linux-support or platform-independence.

The question is something like this. Since most (actually ALL) of my applications are realtime and will-never-run-fast-enough AND contain physics and other compute-intensive subsystems that will eventually "need" GPU support, is it actually BETTER to shift everything except "explicitly graphical" aspects of my applications out of OpenGL and into CUDA (or OpenCL, assuming OpenCL ~= OpenCUDA).

Off the top of the head, my reaction is "that makes sense".

This does not answer everything people have been complaining about, but I see more and more aspects it might apply to. And I almost wonder if somebody else had similar thoughts, and that led to plans to shift everything non-explicitly graphical OUT of OpenGL. If nothing else, this makes me less worried that "so many people/projects/organizations will abandon OpenGL, and soon no quality fast/realtime linux/multiplatform support will exist".

Anyway, I'm curious what less oblivious OpenGL gurus think of this crazy speculation. Am I just making lemonaide outta lemons?

[Korval]

I can churn out OpenGL code fairly effortlessly, but with DX i find myself continuously having to look up the documentation to find how to do something.

That's just lots of experience talking. You'd have had to do just as much documentation lookup with Longs Peak.

We could always write our own API that uses OpenCL as the GPU interface

Yes, if you like losing 3x or more performance.

[NeARAZ]

Here's a more interesting question: of those sticking with OpenGL, if there were an alternative that was more D3D like in API, one that was supported across platforms and such, would you take it? That is, are you choosing OpenGL because you want to be cross platform, or because you like it?

I don't care about cross platform. I'd choose whatever API works best (as in, stable + supports features I need + supports hardware I need to support) on a particular platform. If it also happens to be best on several platforms, well that's a bonus... On Windows at this time, best API is D3D9 (drivers much more stable than GL, supports everything we care about, supports even ten year old hardware).

On OS X, this is OpenGL, but only because it's the only choice. Would I want to have something that is leaner & meaner? Hell yes. No alternatives are available though.

I don't care about having to port to somewhat changed API (as in D3D), as long as it still is stable + has features + supports hardware. D3D10 slightly fails in this regard as exclusive API I'd support, but I don't mind having D3D9 and D3D10 renderers (I don't have D3D10 at the time, because there's not enough market to validate that yet). D3D8 -> D3D9 transition was a no-brainer though (ok, at that time D3D9 runtimes were not so widespread, as it was before XP SP2).

[bootstrap]

Here's a more interesting question: of those sticking with OpenGL, if there were an alternative that was more D3D like in API, one that was supported across platforms and such, would you take it? That is, are you choosing OpenGL because you want to be cross platform, or because you like it?

I cannot give a clean, simple answer to that [good, interesting] question. If D3D was multiplatform, I would NOT switch to D3D - at this point. In fact, I did just the opposite 2 or 3 years ago, and I have been extremely happy that I did. Would I switch to a totally new/cleaner all-platform API at this point? Yes, but ONLY if it really was substantially cleaner AND [20%+] faster AND added *important* GPU features quickly. I might even switch if the API was nvidia-only or amdati-only (whichever has the best GPUs at that moment). In fact, I guess if I adopt cuda I have more-or-less done that (which makes me hope we don't end up having the same problem with cuda versus opencl (or whatever the alternative really is/becomes)). I'm not sure whether I am alone in this, but I am willing (if necessary) to tell our customers "you must buy nvidia (or amdati) video cards to run our application", but I am not willing to tell my customers AND MYSELF "you cannot run our application on your linux/mac/other computers, only windoze".

In other words, being forced to abandon your entire platform (OS) is in a totally different category (in my mind) than being forced to select one brand of video-card. Though sure, I really don't want to do that either. In fact, that's one reason I'd like to procedurally generate geometry (in the CPU and/or GPU) with something other than a gemoetry shader tied to the GPU. The case is being made for us, right in front of our eyes, that we should avoid adopting GPU features that can be done [~just as well or better] elsewhere (cuda/opencl/other).

Good question. But the simplistic answer is, "I definitely like OpenGL more than D3D, but I'd like a super faster/cleaner/more-up-to-date API even better (that has DRIVERS and is STABLE). Who wouldn't.

[Mars_999]

Not to get off topic but this probably will, IMO OpenCL will take over and CUDA will become Cg, and honestly if Nvidia wants to push GPGPU they should stand aside and help ATI push the OpenCL standard to get it to market and more users onboard. Plus if OpenGL can talk to OpenCL and grab whatever data is need, this would be nice... What about doing some really nice Noise() calculations with the GPGPU? and sending that data to OpenGL? Would this be possible? Could this open up the door to having more texture creation assets that are more random then they are now? Procedural content would be a viable option?

[Komat]

I would like to move to DX9 however I do not have time to convert all our OGL dependent tools (ingame editor, plugins) to it nor time to maintain more renderers than I need to. Plus few co-workers are using Linux which complicates that even more.

[bootstrap]

Not to get off topic but this probably will, IMO OpenCL will take over and CUDA will become Cg, and honestly if Nvidia wants to push GPGPU they should stand aside and help ATI push the OpenCL standard to get it to market and more users onboard. Plus if OpenGL can talk to OpenCL and grab whatever data is need, this would be nice... What about doing some really nice Noise() calculations with the GPGPU? and sending that data to OpenGL? Would this be possible? Could this open up the door to having more texture creation assets that are more random then they are now? Procedural content would be a viable option?

What I read of the CUDA documentation before I got distracted seemed to say quite clearly and explicitly that it can write directly into OpenGL or D3D buffer objects. This means you can generate vertices and indices into VBOs, you can generate noise/images/textures directly into FBOs (and textures/depth-buffers/anything attached to FBOs). This is totally *fantastic* in my opinion, especially since my engine was designed and optimized primarily for procedurally generated content (geometry/objects, textures, sound, etc).

I have not even peeked at OpenCL yet, but I would assume it *must* be able to work the same way - or it won't be accepted over CUDA. Because of these facts, the future looks great for graphics applications even if OpenGL continues to look the way it does today, and never gets a total makeover.

Less and less of our applications will be performed by OpenGL, though the graphics still will. As you see, the 3D math is being moved to the CPU or GPU via CUDA already. In my case I crunch matrices and vectors on the quad-core CPU because I need super-efficient double precision for many physical processes (nobody talking about how many physical processes go bad/haywire/imprecise rather quickly in single precision). Of course I still do the final steps of matrix and vector math in the GPU shaders, which works fine in single precision.

[Korval]

you can generate noise/images/textures directly into FBOs (and textures/depth-buffers/anything attached to FBOs).

A buffer object is not anything that ends in BO. The "vertex buffer object" extension is fundamentally different from "framebuffer object" (one word: framebuffer). The FBO extension even has an issue about people confusing the two.

So while you can write to an OpenGL buffer object, you cannot write directly to an OpenGL framebuffer.