• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 134 subscribers
  • Views 5412 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using EglImage in a multi process and with two different apis

Yenks

Hi,

I have a question which is broken into two parts. I'm trying to create EglImageKHR and a process running opengl-es and then use the image to create a texture in another process which may possibly be running GL.

My questions are:

1) is it possible to share EglImageKHR between processes? or is there a way to share graphics data from opengl-es with another process while still maintaining fast graphics? I've tried FBO and just copying the data using glReadPixels but they are slow.

2) can you create graphics with one graphics api (opengl-es for instance) and pass it to another api (GL) for rendering?

I hope to hear from you.

Thanks!

Yenks

  • 0

    Hi Ony,

    Apologies no-one got back to you on this yet, questions can be overlooked unless you check "Mark this discussion as a question" when you create it. I've now changed this into a question and let our team know to get back to you.

  • 0

    Just pulled up the spec to try and answer these questions...

    From the spec: "Context state, including both the client and server state of OpenGL and OpenGL ES contexts, exists in the client’s address space; this state cannot be shared by a client in another process."

    So that's a no on question 1, and makes sense; the application and driver are operating in different address spaces for different processes.

    For question 2: "...some types of state are potentially large and/or expensive to copy, in which case it may be desirable for multiple contexts to share such state rather than replicating it in each context. Such state may only be shared between different contexts of the same API type (e.g. two OpenGL contexts, two OpenGL ES contexts, or two OpenVG contexts, but not a mixture)."

    So that's a no on question 2 as well, according to the spec.

    Any implementation that allowed these things would be operating outside of the core EGL spec, for number 2 there might be an extension that allows this. I'm not aware of one but I'm not an EGL expert, so someone else might comment with an example of one!

    Thanks,

    Chris

    EDIT: Sections 2.3 and 2.4 of the EGL 1.4 spec are the relevant parts for these questions.