I was wondering if running OpenCL Kernel and OpenGL Compute shader would not cause any problem excessing the GPU.
I could Use Different EGL but it look like i cannot share EGL context between C++ JNI and Java OpenGL Renderer thread.
So the Question is. Do i need to create an EGL context for the OpenCL kernel or there would be no problem to send a Kernel instruction than OpenGL instruction in asynchronized way. Or it may have some problem in case or Kernel instruction and OpenGL instruction could be superposed.
So at some time it may be possible that Kernel instruction and OpenGL instruction could be interlaced " entrelacer in french ". And that is this case make some problem. Or will i need to do some flush after each kernel instruction and OpenGL instruction.
Sorry for my english. But i hope the question is anderstandable ;))
To interleave (interlace, entrelacer, etc.), you’re going to want to look at what OpenGL / OpenCL interop synchronization that your target GPUs/GPU drivers support.
Method #1: The absolute most inefficient method is when the drivers don’t support any efficient synchronization and you basically have to flush all of the work out of the GPU pipeline (via clFinish() / glFinish()) before you can flip to queuing commands with the other API.
To use the GPU more efficiently, you do not want to have to do these flushes. In fact, many modern GPUs support parallel graphics and compute queues on the GPU, and this sledgehammer approach to synchronization I believe precludes use of this capability.
Method #2: A more efficient alternative to this is to use pipeline events to synchronize work between CL and GL via:
So check and see if the GPU driver(s) you’re targeting support these event sharing extensions in both their OpenCL and OpenGL implementations.
Years ago when I was first trying to interleave OpenCL and OpenGL use of the GPU in a single program, I hit this problem. On NVIDIA GeForce GPUs/drivers, I had to (and would still have to AFAIK!) use the first, ugly sledgehammer flush method (clFinish() / glFinish()) of synchronization. This because NVIDIA did not (and still does not AFAICT) support the above OpenCL/OpenGL event sharing extensions in their drivers for most GeForce GPUs:
It would seem, NVIDIA really does not want you to use OpenCL in an OpenGL program on their consumer GPUs, providing their proprietary CUDA compute language/libs as an option instead.
As far as OpenGL Compute Shaders, I don’t know whether they (by contrast) are supported efficiently on NVIDIA GeForce GPUs/drivers, or whether NVIDIA has tied one or both of their hands behind their back too. If anyone does know more about this though, I’d love to hear from you!
If i creta an EGL context on the C part. MAy the that the synchrinization could be done automaticly. Like when i am using WebGL and openGL at the same time. Both got their own EGL context. And their seems to be able to work together. I have already tried it when displying in OpenGL the output frame of a WebGL, jThree, and OpenGL url.
In fact i can use an openGL URL inside my openGL app. And can even perform action on the openGL URL. Like rotation if the openGL url has impleted it.
Is that sound like possible. Bacause i am sure that 2 EGL context will be synchronized. And than use buffer out from compute shader and send it to C openCL.
It is a trick for sure. But if it can work, why not ;))
I hadn’t really gone looking for it. But yes, it appears there is. Try this markup:
[color=blue]Blue text[/color]
[color=#0000ff]Blue text[/color]
[bgcolor=yellow]Yellow background[/bgcolor]
[color=blue][bgcolor=yellow]Blue text on yellow background[/bgcolor][/color]
Blue text Blue text Yellow background color Blue text on yellow background
As you can see, it isn’t honored in multiline code block markup (``` … ``` or “Preformatted text” toolbar button). But it does work in block quote markup.
cl_khr_gl_event is supported, there is an implicit synchronization between your runtimes, that is if you can make that OpenGL context current that affects their state when you acquire/release the resources. You can read more about this in the extensions spec HTML in section 12.6 (sry, can’t post links). Actually synchronizing via events is only required when your engine is structured in such a way that your OpenGL context is current on another thread (render work is being enqueued) or the symbol isn’t in scope to your compute module.
It look like on ARM mali G72 there is more than one GPU heart. So they may not need any synchronization. It is like double buffering they may switch from one heart to another. And i think that OpenCL do not need to use Context like OpenGL. I not sure of how it works. But it look like it is working well.