Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: PBuffer & Texture Sharing

  1. #1
    Intern Contributor
    Join Date
    Aug 2002
    Location
    SomeWhere Lost In France
    Posts
    75

    PBuffer & Texture Sharing

    Is there a way to share Textures loaded in GL memory between Standard Rendering Context and the PBuffer Context ?

    I currently load texture once for the Standard Context and a second one for the PBuffer Context, to avoid this problem.

    Thanks.
    I'm 4 and I draw

  2. #2
    Junior Member Regular Contributor
    Join Date
    May 2003
    Location
    Germany
    Posts
    229

    Re: PBuffer & Texture Sharing

    wglShareLists does exactly that, although it's name won't suggest it

  3. #3
    Intern Contributor
    Join Date
    Aug 2002
    Location
    SomeWhere Lost In France
    Posts
    75

    Re: PBuffer & Texture Sharing

    Arff!

    It seems not working correctly.

    I use Vertex & Fragment with textures.
    Using wglShareLists display textures but randomly...
    GL_Id of texture doesn't match...
    It's also the same problem with V/F programs...
    Sometimes it works with randomly sorted program.

    So I spot the fact that I load now, only once the textures and the programs when the main Context is Active.

    It's Strange....
    I must be wrong somewhere.

    I would like just select when rendering Objects between ColorBuffer and PBuffer destination.

    I'm lost.

    Thanks
    I'm 4 and I draw

  4. #4
    Intern Newbie
    Join Date
    Mar 2003
    Location
    France
    Posts
    36

    Re: PBuffer & Texture Sharing

    Try to check the return value of wglShareLists it should be TRUE if things went right.

    How are you using it ? personally I do something like that :
    Code :
    	m_hPBuffer = wglCreatePbufferARB (m_hGLDC, pixelFormat, width, height, pBufferAttributes);
     
    m_hDC = wglGetPbufferDCARB (m_hPBuffer);
    m_hRC = wglCreateContext (m_hDC);
    wglShareLists(m_hGLRC, m_hRC);
    Nothing extraordinary, PBuffer isn't really difficult to setup (even if it's a pain to do that if what you want is just rendering to a texture, but soon things will change). In this code m_hGLDC is the window device context and m_hGLRC is the window rendering context. I load shaders and texture only once and things are perfectly right. Moreover I think (need to check thoug) that if the pixel format of your PBuffer and your FrameBuffer match you don't need to create a new one for your PBuffer, you can share it.

    Hope that helps

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    2,411

    Re: PBuffer & Texture Sharing

    wglShareLists() works just fine, assuming you haven't already allocated other things in the context. Thus, you should call it right after creation. The texture Ids you should use are the same as you had in the original context.

    Edit: remember also that the two contexts have different state. Thus, if you bind a texture in one context, it does not mean that it's bound in the other. The same for every other non-shared state (matrices, enables, texenv, etc).
    "If you can't afford to do something right,
    you'd better make sure you can afford to do it wrong!"

  6. #6
    Intern Contributor
    Join Date
    Aug 2002
    Location
    SomeWhere Lost In France
    Posts
    75

    Re: PBuffer & Texture Sharing

    It's Exacly what I've done.

    Jwatte:
    You're right it works fine.

    I've noticed that everything works till I don't use Fragment or Vertex Program on PBuffer...

    I may be wrong somewhere in my implementation.

    I'm little confused between pbuffer and V/F programs..

    Thanks
    I'm 4 and I draw

  7. #7
    Intern Contributor
    Join Date
    Aug 2002
    Location
    SomeWhere Lost In France
    Posts
    75

    Re: PBuffer & Texture Sharing

    Deeper Inside...

    I've noticed something strange:
    Using wslShareLists allows vertex/fragment program ID to be shared between main rendering context and pbuffer rendering context.
    BUT programs are not accessible from pbuffer if not loaded from it.

    So I've tried to load the programs on both rendering context (with each "Made Current Before" of course) and now it works nice with the program Id of one of them (both Id aim it's own copy program)...

    So I gone further,I tried to load an EMPTY fragment program in pBuffer while loading the good fragment program in the main context (EMPTY means : "!!ARBfp1.0 END")
    And everything is stil rendered by using the Fragment Program ID of the main context (wich seems to be shared correctly).

    But if I don't load (with glProgramStringARB) something in the pBuffer context, programs are not reachable from pBuffer...

    Any Idea?

    Thanks.
    I'm 4 and I draw

  8. #8
    Intern Contributor
    Join Date
    Aug 2002
    Location
    SomeWhere Lost In France
    Posts
    75

    Re: PBuffer & Texture Sharing

    I've finaly found the problem.
    But I don't know if it's normal:

    Using wglsharelists with multiple pBuffer (in my case 10) and one Main rendering Context, leads to a program binding problem.
    When using several v/f programs, rendering contexts shared lose the Programs IDs generated in the main context if you generate & delete programs several times.

    I must bind an empty or default program ID "0" in all pBuffers before deleting the program.
    In that case, the program deleted is deleted in all shared context, with all Program ID matches.

    I don't know if it's an obvious problem or if I don't understand the behaviour of wglShareLists with v/f programs.
    But I put here what I've Noticed.

    If someone can tell me if it's part of wglShareLists or VERTEX/FRAGMENT_PROGRAM_ARB specs...

    I used several Driver (53.03 to 56.72 on my GForceFX5200) to be sure that's not a bug driver.

    Thanks.
    I'm 4 and I draw

  9. #9
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Re: PBuffer & Texture Sharing

    No one truly knows what's the correct behavior. Only MSDN documents it but it isn't well explained.

    It is my understanding that if you have a shareable bound in one of the contexts, and you attempt to delete it, it won't be deleted but it will become inaccessible in the context in which you deleted it.

    I think there is something like a reference count similar to COM objects.

    When the final context unbinds the shareable and calls delete on it, the shareable gets deallocated.

    This bevavior would respect the glDeleteXXXXXXX function and at the same time would respect wglShareLists.

    By shareable, I mean display lists, textures, programs, shaders, buffer objects.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  10. #10
    Advanced Member Frequent Contributor plasmonster's Avatar
    Join Date
    Mar 2004
    Posts
    739

    Re: PBuffer & Texture Sharing

    When you create an OpenGL rendering context, it has its own display-list space. The wglShareLists function enables a rendering context to share the display-list space of another rendering context; any number of rendering contexts can share a single display-list space. Once a rendering context shares a display-list space, the rendering context always uses the display-list space until the rendering context is deleted. When the last rendering context of a shared display-list space is deleted, the shared display-list space is deleted. All the indexes and definitions of display lists in a shared display-list space are shared.

    You can only share display lists with rendering contexts within the same process. However, not all rendering contexts in a process can share display lists. Rendering contexts can share display lists only if they use the same implementation of OpenGL functions. All client rendering contexts of a given pixel format can always share display lists.

    All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.
    This is fresh from MSDN. The last paragraph is interesting.

Posting Permissions

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