Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: OpenGL + OpenVG

  1. #11
    Senior Member
    Join Date
    Feb 2006
    Posts
    115

    Re: OpenGL + OpenVG

    No - surfaces are sharable (think of them as just a handle to a framebuffer). When you create them, you need to make sure the config supports both ovg and ogl rendering, but I don't see that as much of a problem for any driver which supports both ovg and ogl rendering - chances are high that all valid configs will (but it never hurts to check).

    The reason for the NULL makecurrent is that some egl implementations might return errors if the surface you are making current is the same surface that's bound to the context that you are replacing (giving some surface in use error or something). It shouldn't happen IMHO, but I think I have run into a bug like that once in some driver or other at some point.

  2. #12
    Senior Member
    Join Date
    May 2008
    Posts
    100

    Re: OpenGL + OpenVG

    Quote Originally Posted by Ivo Moravec
    The reason for the NULL makecurrent is that some egl implementations might return errors if the surface you are making current is the same surface that's bound to the context that you are replacing (giving some surface in use error or something). It shouldn't happen IMHO, but I think I have run into a bug like that once in some driver or other at some point.
    I think the EGL specification enforces this behavior, so it would be a bug if you didn't get an error when trying to make current a surface that's already bound to another context. So if you want to write portable EGL code, it's probably safer to make current with NULL, however it's possible doing this could have a negative impact on perforce as it could trigger some expensive state updates. So, I would say the decision depends if you're focused on a particular platform or not.

  3. #13

    Re: OpenGL + OpenVG

    Below is my sequence of code.

    1. create ovg context
    2. make ovg context current to the thread
    3. create ovg image object, load with image data and bind ovg image to pbuffer using eglCreatePbufferFromClientBuffer
    pbuffer = eglCreatePbufferFromClientBuffer(dsp, EGL_OPENVG_IMAGE,
    (EGLClientBuffer)ovgimage, config, attrib_list);
    4. create shared context
    5. bind ogles
    6. make shared context current to the thread
    7. Bind ovg texture (pbuffer) to ogl primitives using eglBindTexImage
    glBindTexture(GL_TEXTURE_2D, pbuffer);
    eglBindTexImage(dsplay, pbuffer, EGL_BACK_BUFFER);

    In the above implementation eglBindTexImage returns EGL_BAD_MATCH. surface, display are shared and created only once.

    Can anybody help me find the problem.

  4. #14
    Senior Member
    Join Date
    Feb 2006
    Posts
    115

    Re: OpenGL + OpenVG

    If in 4) and you're creating a context, the bound api is still openvg - you'll be creating an openVG context.
    Thus your make current will bind a openvg context.

    Other than that, as I said in some other post, I have not used eglBindTextImage(), so I'm afraid the EGL spec can help you more than I can there. Did you set/leave the EGL_TEXTURE_FORMAT surface attribute to EGL_NO_TEXTURE?

  5. #15

    Re: OpenGL + OpenVG

    I just swapped 4 and 5 code, this leads to crash while creating the shared context. So i doubt if i can really share a context across client APIs !

    Also calling eglmakecurrent with egl_no_surface and egl_no_context after 3) did not help!

    the pbuffer is created in ovg context hence i do not touch EGL_TEXTURE_FORMAT attribute. I think EGL_TEXTURE_FORMAT is ogles attribute.

  6. #16
    Senior Member
    Join Date
    Feb 2006
    Posts
    115

    Re: OpenGL + OpenVG

    No you can't share a context across different APIs. Internally, what a context is an instance of the current API state (everything from what paints are created and bound, to attributes like VG_LINE_WIDTH, to internal state you never see). Contexts by their very nature are API specific (GL state is very different from VG state afterall). So sharing a VG context with an OpenGL ES context is a mistake.

    To render to a texture, you should be trying to transform a VGImage (OpenVG) into pbuffer (EGL), after you do this, the pbuffer should still be valid (because it's EGL) even after the OpenVG context is made not current (and you wont be able to use the VGImage again until the pbuffer is destroyed). You should then be able to use the pbuffer as a normal rendering surface for any API (if your implementation crashes doing this, it's a bug).

Page 2 of 2 FirstFirst 12

Similar Threads

  1. Using OpenGL, ON, OpenVG
    By Zamaster in forum OpenGL ES general technical discussions
    Replies: 1
    Last Post: 01-06-2012, 08:09 PM
  2. Using OpenGL ES with OpenVG
    By jrabbani in forum OpenGL ES general technical discussions
    Replies: 0
    Last Post: 11-29-2010, 12:29 AM
  3. OpenGL ES 2.0 + OpenVG 1.1
    By jrabbani in forum OpenVG and VGU
    Replies: 0
    Last Post: 11-24-2010, 10:44 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •