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 6 of 6 FirstFirst ... 456
Results 51 to 59 of 59

Thread: Official feedback on OpenGL 4.2 thread

  1. #51
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Groovounet
    If we have to create a window for each thread
    This was never the case, though i recall seeing msdn article that says separate HDC's should be used to make contexts current on their threads if you draw to the same window.

    Quote Originally Posted by Alfonse Reinheart
    But that's my point: we already have one. wglCreateContextAttribs.
    wglCreateContext works just as well here (unless you care for, well, context attributes).

  2. #52
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.2 thread

    wglCreateContext works just as well here (unless you care for, well, context attributes).
    wglCreateContext doesn't take a HGLRC to share with, so if you want sharing, you have to explicitly call wglShareLists afterwards. It's always good to be up-front about sharing.

  3. #53
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    456

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Alfonse Reinheart
    One of the early ideas with wglCreateContextAttribsARB was that you would be able to pass NULL for the device context and thus create a display-less GL context. The 3.0 and above specs even have language that previous versions didn't for such eventualities.

    Indeed, it may actually work now. You might be able to create multiple contexts from the same DC, but pass NULL for the DC when using wglMakeCurrent. According to the spec, this ought to be able to work. I'm not sure if I buy it though; someone ought to test it out.
    If you look at issue 4) in the WGL_ARB_create_context extension specification , it reads:
    4) Should there be a way to make a context current without binding
    it to a window system drawable at the same time?

    RESOLVED: Yes, but only in OpenGL 3.0 and later. This results in a
    context with an invalid default framebuffer, the meaning of which is
    defined in the OpenGL 3.0 specification.

    NOTE: Apparently on Windows, opengl32.dll makes use of the drawable
    argument to identify the namespace of the driver, so we may not be
    able to work around it.
    I guess this means that if you have 2 cards from different vendors with different drivers, then the hdc is being used to identify the driver to create the context using, which if you provide NULL it can no longer do (without guessing).

    Whether this is something Microsoft can solve, or an unsolvable problem without using a different platform API (EGL or new OpenCL-like platform layer) I'm not sure.

    Maybe some extra attribute in the context creation flags would be enough.

    Code :
    wglGetPlatforms(NULL, &num_platforms);
    *allocate platforms buffer*
    wglGetPlatforms(platforms, &num_platforms);
    *choose a platform*
    *free platforms buffer*
     
    attributes[0] = WGL_CONTEXT_PLATFORM;
    attributes[1] = chosen_platform;
    attributes[2] = WGL_CONTEXT_MAJOR_VERSION_ARB;
    attributes[3] = 4;
    attributes[4] = WGL_CONTEXT_MINOR_VERSION_ARB;
    attributes[5] = 0;
    attributes[6] = WGL_CONTEXT_PROFILE_MASK_ARB;
    attributes[7] = WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB;
    attributes[8] = 0;
     
    wglCreateContextAttribsARB(NULL, NULL, attributes);

  4. #54
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by mbentrup
    I sometimes wished that GLX/WGL would have a function that could create a new context, given just another GL context as input (compatible/shareable with the input context of course).
    It's there as the shareList parameter:

    GLXContext glXCreateContext(Display *dpy, XVisualInfo *vis, GLXContext shareList, Bool direct);
    (usually just hobbyist) OpenGL driver developer

  5. #55
    Junior Member Newbie
    Join Date
    Feb 2012
    Posts
    1

    Re: Official feedback on OpenGL 4.2 thread

    The quick reference card describes non-existent functions: DrawArraysOneInstance and DrawElementsOneInstance.

  6. #56
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129

    Re: Official feedback on OpenGL 4.2 thread

    The spec clearly states that these functions are not part of the API but are merely used to explain the behaviour of actual functions.

  7. #57
    Junior Member Newbie
    Join Date
    Sep 2011
    Location
    Florence, Italy
    Posts
    14

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by thokra
    The spec clearly states that these functions are not part of the API but are merely used to explain the behaviour of actual functions.
    This makes sense in the spec, but he's talking about the quick reference card. Why are these functions displayed there?

  8. #58
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129

    Re: Official feedback on OpenGL 4.2 thread

    On second thought, that's actually unnecesseary.

  9. #59
    Junior Member Newbie
    Join Date
    May 2009
    Posts
    12
    Need of context creation for multiple threads is because of loading objects from files as I understand. Like 3d model or scene files, or shader files etc. But I have a basic problem about that besides context creation too.

    If I want to load a model file containing vertex attributes or indices I'd rather want to save attribute info into OpenGL state...(ie. VAO).
    Similarly for scene files there may be some render-to-texture effects so I will need to generate some framebuffers for that need while loading the file...
    When I begin to load shader files I need to generate my pipelines...

    And here is my problem: None of VAO, framebuffers or pipelines are sharable among contexts. Just because they refer to other objects. I still dont understand why they need to be client state and not server state. Because we are not holding onto object pointers or such. We are holding some object names which are given by the driver and being recognized across threads.

    Display lists (ironically core profile is removing lists but DX is introducing lists for multiple threads) might be a solution if using buffers/shaders was valid.

Posting Permissions

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