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 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 59

Thread: Official feedback on OpenGL 4.2 thread

  1. #41
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935

    Re: Official feedback on OpenGL 4.2 thread

    The OpenGL 4.2 and GLSL 4.20 specification has been updated:
    http://www.opengl.org/registry/

  2. #42
    Junior Member Newbie Closed's Avatar
    Join Date
    Sep 2011
    Location
    Moscow
    Posts
    8

    Re: Official feedback on OpenGL 4.2 thread

    Good day! I was found some errors in OpenGL 4.2 (2011.08.22) spec:

    1) section 2.14, page 155:

    Original:
    The state required to implement the viewport transformation is four integers and two clamped floating-point values for each viewport.

    Error description:
    Wrong! 6 floating values are required (4 - viewport, 2 - depth range), see glViewportIndexed* and GL_VIEWPORT_SUBPIXEL_BITS)

    2) section 3.9 (Texturing), page 213

    Format RGB565 is missing in table 3.12. So, it is unusable because missed sized internal format.

    Sorry! If i'm wrong (:

  3. #43
    Junior Member Newbie Closed's Avatar
    Join Date
    Sep 2011
    Location
    Moscow
    Posts
    8

    Re: Official feedback on OpenGL 4.2 thread

    Updated NVIDIA/AMD driver status, introduced new bugs not included in article from www.g-truc.net.

    http://www.steelratsoftware.com/inde...58#addcomments

  4. #44
    Junior Member Newbie
    Join Date
    Oct 2011
    Posts
    1

    Re: Official feedback on OpenGL 4.2 thread

    John Carmack of ID SOFTWARE says this about OPENGL

    http://twitter.com/#!/ID_AA_Carmack/status/126421181069918208

  5. #45
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268

    Re: Official feedback on OpenGL 4.2 thread

    Nice of Carmack to provide some advocacy (took him a while to notice the problem though
    But what does this have to do with multiple threads?

  6. #46
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935

    Re: Official feedback on OpenGL 4.2 thread

    Because in we could use work threads to process meshs, textures anythings and upload them into the GPU memory. If we have to create a window for each thread, then we are wasting the framebuffer memory attached to this window.

  7. #47
    Junior Member Regular Contributor
    Join Date
    Dec 2009
    Posts
    212

    Re: Official feedback on OpenGL 4.2 thread

    While I don't think that it is a big restriction that you need a window to create an OpenGL context (note that you don't need a window per thread), 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).

    Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

  8. #48
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.2 thread

    Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.
    That doesn't make sense. If you want to create an off-screen context for doing uploading and so forth, pixel formats are completely irrelevant. You don't want a default framebuffer. You don't even have a window or DC to set the pixel format into. All you want is a new context that is shared with the old one.

    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.

  9. #49
    Junior Member Regular Contributor
    Join Date
    Dec 2009
    Posts
    212

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Alfonse Reinheart
    Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.
    That doesn't make sense. If you want to create an off-screen context for doing uploading and so forth, pixel formats are completely irrelevant. You don't want a default framebuffer. You don't even have a window or DC to set the pixel format into. All you want is a new context that is shared with the old one.
    Exactly. Unfortunately the HDC is required and WGL specifies that two contexts may only share resources if they use the same pixel format. (You may not even get the same results if you call wglGetProcAddress in contexts with different pixel format).

    GLX does not explicitly state this requirement, but the driver may return BadMatch, if the contexts are "incompatible" for whatever unspecified reasons.

    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.
    That language refers afaik to the case when you pass a NULL DC to wglMakeCurrent, but for the context creation the DC was always required.

    In practice you won't find OpenGL apps that use *only* windowless contexts and any windowless contexts are probably for uploading textures or using transform-feedback to fill buffers etc, which are then later used in the 'main' context, so I think a specific function to create a shareable context for a given GL context would be very useful.

  10. #50
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.2 thread

    In practice you won't find OpenGL apps that use *only* windowless contexts and any windowless contexts are probably for uploading textures or using transform-feedback to fill buffers etc, which are then later used in the 'main' context, so I think a specific function to create a shareable context for a given GL context would be very useful.
    But that's my point: we already have one. wglCreateContextAttribs. Just pass it the same DC you used to create your windowed context. It also has a parameter for a HGLRC that it will be shared with.

Posting Permissions

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