Hi,
I'm developing gl sharing for Open Cl 1.1 implementation. My current solution
is to
use the existing interface and extension to export a gl texture/buffer object
to the
OpenCL domain, and create an cl memory object from the same buffer object(drm
level).
But I met some gaps with current mesa implementation.
First, I want to talk about the gl 2d/3d texture sharing problem.
The basic idea is to use EGL_KHR_gl_texture_3D_image and
EGL_KHR_gl_texture_2D_image
extension to create an EGL image from the 2d/3d textures, then use EGL API to
get the
image's attribute and the image's bo's name. But I found there is no way to get
the
image's detail attributes which are width/height/format/... . I also found that
this
is as desgiend according KHR_image_base spec:
3. Should attributes (width, height, format, etc.) for EGLImages
be queriable?
SUGGESTION: No. Given the wealth of attributes that we would
need to specify all possible EGLImages (and possible
memory layout optimizations performed by implementations), we
can dramatically simplify the API without loss of key
functionality by making EGLImages opaque and allowing
implementations to make the correct decisions internally.
But we do need to query these attributes when we want to create a CL memory
object
from a gl texture/egl image. Another reason is that GLES doesn't provide APIs to
get a texture's width/height/internal format neighter.
I just wonder is there any possibility to provide such functions at the image
extensions layer?
If no, then one alternative solution is to leverage gbm's capability. And we do
need to
extent the GBM's interface to create a GBM device from a existing egl dri2
display. Then
we can use GBM's API to query those attributes. Current GBM only support to
create a new
GBM device as a new dri loader. Thus it can't be used to access the images
created from
the existing EGL context. Is it doable/acceptable to add a new way to create a
GBM device
from an existing egl dri2 display?
Or is there any other way to achieve the same goal more gracefully?
Second, back to the gl buffer object sharing problem.
If either the above two issues get fixed(extent EGL image extension or extent
gbm
library), we can achieve the goal to share a gl 2d/3d texutres with Open CL. But
we still can't achieve the same goal with buffer object. As there is no any
extension to export
a buffer object. I don't have any good idea about this point. Is there any
suggestion
for the buffer object sharing with OpenCL in mesa?
Looking forward to your valuable suggestion/feedback.
- Zhigang
Thanks.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
