Curious to who is sticking with OpenGL now...

[bootstrap]

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.

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.

[Rob Barris]

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.

[Mars_999]

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?

[Rob Barris]

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

[Korval]

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.

[JoeDoe]

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

[bootstrap]

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?

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.

[Seth Hoffert]

There are two major things that we cannot do from shaders right now:

• Control shared memory explicitly.
• Scattered writes.

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

[Mars_999]

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

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

[Korval]

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?