Curious to who is sticking with OpenGL now...

OpenGL
21

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.

22

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.

23

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?

24

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.

25

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).

26

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.

27

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?

28

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.

29

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.

30

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.

31

Hmmmm. I will double check that when I get back to reading/studying it. I hope you are mistaken, but even if not, the same results are still possible, just somewhat less direct and/or efficient [in some scenarios]. Plus, I bet something equivalent/similar to writing directly to the entities attached to an FBO is either possible already, or will become possible soon (next upgrade). It just makes too much sense, and it already does things very similar. Still, thanks for making me study and experiment more carefully.

32

Interoperability between OpenCL and OpenGL is a high priority; this was discussed briefly at the BoF. i.e. ability for CL kernels to read/write GL buffer objects and textures in an orderly fashion.

33

So as it stands, we will be able to use OpenCL seamlessly with GL as long as we used FBO,VBO,PBO to move the data to GL, what about moving data back from GL to OpenCL?

34

Which class of data do you have in mind ? In general I think there will be symmetry, but in some cases there may not (I am thinking of the case where CL wants to write into a compressed texture).

35

Honestly, I think OpenCL writing to anything more than a buffer object is too much. Or at least, more low-level than is needed.

I wouldn’t want OpenCL to have to somehow figure out how to write to a particular format of texture, for example. We already have PBO (is that core yet? I don’t recall seeing it in the spec, but I didn’t look that hard) for taking in-memory buffer objects and formatting them into textures.

Let OpenCL write to buffer objects, and then let OpenGL do its job.

36

I’ll switch to D3D10, OpenGL stay for second renderer only.

37

You know what? CUDA and OpenCL may be the direction things move, but maybe the opposite is possible too. Given the highly efficient ways OpenGL [vertex and] fragment shaders can read from and write to images/objects/buffers/textures, and also transfer data back and forth to-and-from CPU memory, it is already possible to do CUDA/OpenCL-like processing the way things are now.

Whether this is close to as efficient as CUDA/OpenCL is a question I cannot answer. But this raises a question about the CPU architectures, namely “how many shaders can a GPU run simulataneously”? I ask because “conceptually” anyway, I assume the vertex and fragment shaders are running simultaneously, but I am not entirely certain. The same goes for geometry shaders and CUDA/OpenCL programs. Can the GPU run vertex, fragment and geometry shaders all simultaneously? Yes? Then can the GPU run vertex, fragment, geometry, CUDA and OpenCL shaders/programs simultaneously? I guess the answer implied by the CUDA documentation is “yes” - apparently modern GPUs can run several sets of programs simultaneously.

This still leaves me wondering whether we can do virtually everything CUDA can do already with vertex and fragment shaders (plus the various features in OpenGL that let us operate on VBOs/FBOs/PBOs/etc, including glBufferSubData() and glMapBuffer() type functions to transfer data to-and-from our shader programs.

One advantage of faking vertex/fragment shaders and OpenGL functions into doing our “other” processing is — we get guaranteed support and compatibility from every modern GPU that functions at all.

38

There are two major things that we cannot do from shaders right now:
[ul][]Control shared memory explicitly.[]Scattered writes.[/ul]Because of this, implementing a convolution in CUDA will be more efficient than using shaders since you can control shared memory instead of having to rely on texture cache. This is why I am somewhat excited about DX11 compute shaders: a shader that uses a similar language as the other shaders, but with less restrictions… :smiley:

39

Correct, I wouldn’t expect compressed textures to be supported, as I can’t think of why that would be useful when you are trying to represent accurate data…

But PBO, FBO, VBO, all of these are good candidates for writing data back to GL, I can see vertex, texture data being generated procedurally vs. hard coded data, or even dynamic data that changes at run-time such as deformable terrain, model meshes, animations… :slight_smile:

40

PBO, FBO, VBO

Um, you can’t write to a framebuffer object. Because it’s just a collection of images (textures or framebuffers). And PBOs and VBOs are simply specific uses of the same thing: buffer objects. Calling them different things is like differentiating between an image texture and a look-up table texture; the only difference is how they’re used.

Most important of all, if you can write directly to a texture, why would you want to right to a buffer object you use for storing pixel data?