I do not know is i choose the rigth place to post it. I am new ;))
I would like to be able to share Image betwwen java OpenGL ES and C++ OpenCL. I fact there is no problem sending data from C++ to Java Opengl ES but the opposite way seems not to be working cause of Java OpenGL Context not shared or very slow using MakeCurrent.
So i thought about using Vulkan to make a bridge between both. But it is just an idea. So before starting i think that asking a question about the faesability i not a bad idea.
So the question is :
does anyone could tell me if the bridge option could be possible to implement. And what could be the approch of the problem. Some other idea are of course welcomed ;))
My approch would be to mix java openGL ES and java vulkan and send the buufer adresse of the Image to C++ to preform OpenCL work. So traitement could be done in Opencl then send to OpenGL shader and back to OpenCL.
I know taht it could be easyer to do everithing in C++ directly. But I have a game motor already running in Java and i do not want to rewrite it in C++. Java IDE is very much easyer to practice than C++ code. And i am using VR in JAva already. So it is a lot of work going back to pure C or C++.
The Khronos APIs often call sharing of resources “interop”, it is about enabling access to a resource (texture, buffer) created in one API from a second API in a way that makes it look (almost) as if the resource was created in the second API to begin with. For OpenGL (ES) - OpenCL Interop I found this tutorial - I’m sure there are others out there.
Thanks for the help. But i forgot to say that i am working on Android Mobile with ARM G72 GPU. And traht my problem is to get rid off the concpet of Android EGL context attached to thread. I need to find an other way to acces the OpenGL ES (java) texture or image. From openCL to JAVA GLES there is no problem using glSubTexture, it is fast. It is from OpelgL ES to C++ openCL that i have a problem of getting acces to the Texture, image or buffer. That is way i am tryng to find other way. I do not know how to get Texture from java OpenGL ES and use it in C++. I even dont know if it is possible ;))
I sepend already 1 month on that problem and still no cloud. May be another 1 months ;))
Hmm, not sure what EGL contexts and threads have to do with this, surely you must have one EGL context for your JAVA OpenGL ES rendering work?
If you are using glSubTexture to share image data that sounds like you are actually copying the bytes that make up the texture image around instead of sharing a single texture object between both APIs. That is likely slower (but also simpler) than sharing the texture object. In that case this boils down to correctly sharing (or passing) a block of memory between the garbage collected JAVA world to the explicit memory management C world and has nothing that is specific to OpenGL ES or OpenCL - it is purely about memory ownership transfer.
Also, there are JAVA bindings for OpenCL, can’t you make use of those to avoid the mixing of programming languages (and memory management paradigms) on top of using two APIs?
Thanks, i was not aware of this Java OpenCL library in android. But in C++ i am not only using OpenCL but also multithreading CPU computation. So android got 4 UC and i use the 4 other with OpenCL. And i do not want to increase the work in Java how is already slow compare to native work. And i could Use Compute shader with is some kinde of openCL.
In fact i just need to retreive in a byteBuffer the result of the fragment shader. Then i can use the buffer with C++. I just have to pass the pointer.
The use of EGL context was just mandatory if i wanted to use EGL_KHR_image_base and try to share it between GL thread and C++. But in fact i am not able to get the context in C++ for some reason ?.
I try PBO but it is quite slow. So as i only need to get a pointer to a buffer i though that vulkan bridge could be the faster way. But there is may be some other like compute shader to image. I need an easy solution and avoiding data transfert or copy.
Just an output fragment shader to a bytebuffer or whatever accesible outside OpenGl context.
Sharing data using subTexture is quite fast if you do not abuse of it? As i process camera it is only 20 image per seconde and it is fine using glSubTexture. I will try again PBO in OpenGL ES but i am not sure that it execute outside og GL rendering bacause it was slow. May be some bad use ;))
Ok, I see. When I was talking about GL - CL interop initially I was referring to CL_KHR_gl_sharing extension and functions like clCreateFromGLTexture which allow you to create CL objects from GL objects provided you create the CL context in a specific way, see this section of the OpenCL spec for details.
Well, kind of. The fragment shader writes its output to a (layer of a) texture, which is not necessarily a linearly organized block of memory - that is one reason why in OpenGL you cannot map a texture unlike a buffer. In Vulkan you can map the memory associated with a texture, but unless you transition it’s tiling to VK_IMAGE_TILING_LINEAR the contents of that memory are undefined.
In general transferring image data from GPU memory to CPU memory is slow because it introduces synchronization and interferes with the driver’s parallelization attempts. If things are too slow doing it this way my suggestion would be too look into keeping all computation on the GPU - as long as you share the resources between the APIs it should not matter that much if you do some of your computation in CL and some in GL.
That right i could do soma work in OpenCL C++ and soeme in JAVA OpenGL. That what i am already working on ;)). And ARM MALI G72 do not have `CL_KHR_gl_sharing only CL_KHR_egl_image. I have never use any KHR it yet :))
But you say “hat is one reason why in OpenGL you cannot map a texture unlike a buffer”
Do know How to send Texture to Buffer ? i will try to see the output ;))
But i am suprised that ByteBuffer to OpenGL work but not the reverse. Using Mobile the GPU and CPU share the same memorie. I though that the FrameBuffer could redirect is output to a ByteBuffer. So the problem look like fedding OpenGL work but not getting from.
In fact it is really easy to get Data back from Opengl. It is the last possibility that i didint tested. An of course that was the right one ;)). Anyway i did leaned a lot from this error ;))
What i do is using framebuffer and PBO readpixel. It is in fact fast enough for what i need. It look like ARM mali G72 as done good job in pixel transfer, specially for mobile architecture.
In fact i think i know why i completly was my way. My first answer concerning this problm was to use KHR_Image and of course EGL context Sharing do do interop OpenCL/OpenGL. So i just jump to this issue, but wrong one.
I am still wondering if i could get same performance using compute shader SSBO rather than FrameBuffer/PBO/ReadPixel.
So no need to EGL context or vulkan, but i stiil will have a look to vulkan ;))
Think for the help. It is much better support than Stackoverflow :)) I adopte the Khronos forum ;))
One day off after 1 month running in all direction to find an answer. ;))