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 3 of 173 FirstFirst 123451353103 ... LastLast
Results 21 to 30 of 1724

Thread: OpenGL 3 Updates

  1. #21
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: OpenGL 3 Updates

    I can answer Stephen A's question #4 right here, there is no client side vertex storage in GL3. All vertex data goes in buffer objects.

  2. #22
    Intern Contributor
    Join Date
    Jun 2000
    Posts
    63

    wglSwapIntervalEXT

    I would like to know, if we have something in OpenGL 3 that replaces "wglSwapIntervalEXT".

    It would be very good to have a simple cross platform solution.

    Much appreciated.

  3. #23
    Junior Member Newbie
    Join Date
    Oct 2006
    Location
    Sweden
    Posts
    23

    Re: OpenGL 3 Updates

    Quote Originally Posted by Korval
    In GL 3.0, you simply try to make a format object of the appropriate type. Part of the format object is a specification of what you intend to do with the images you create from it (bilinear filtering, anisotropic, etc). If, when you create this format, GL says, NO, well, you can't do it.
    Seems like a slower, more annoying version of asking questions to me.

    Can I do it this way? No.
    Can I do it this way? No.
    Can I do it this way? No.
    Can I do it this way? No.
    Can I do it this way? Yes, and you just did it.
    vs
    What does the hardware support? This and that.
    Okay, I do it that way. Fine.

    Quote Originally Posted by Korval
    Shouldn't alpha test be removed?
    No. It's much faster to have real alpha test than to do it in shaders. Plus, alpha test can be per render target (eventually). Plus, you can easily mix and match alpha test without having to write shaders for it.
    How is it faster? The card has to run the entire shader anyway to get the alpha value to test on.

    And what's stopping the hardware vendors from extending shaders to support per-target texkill? It's easier to add stuff to shader versions than to add new APIs.

  4. #24
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by Korval
    Yes, some way to ask what level of FP support is available would be vitial imo.
    Asking questions. That's so DirectX

    In GL 3.0, you simply try to make a format object of the appropriate type. Part of the format object is a specification of what you intend to do with the images you create from it (bilinear filtering, anisotropic, etc). If, when you create this format, GL says, NO, well, you can't do it.
    heh, my bad... for some reason I just totally blanked on the new system o.O

  5. #25
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    Seems like a slower, more annoying version of asking questions to me.
    Nonsense. It's much more flexible.

    By taking fully formed formats and returning yes/no, you have the ability to forbid things that are not easily quantifiable.

    Take simple texture size. Yes, there's a maximum size, but a 4096x4096x128-bit float texture takes up 256MB. You can expose a question, "what's the maximum texture size I take", but if the card only has 256MB, you've just told a lie if you said 4096. It's the combination of the size and the format that makes it impossible.

    The GL method is much better, since you can check specific features that you know may be turned down ahead of time.

    How is it faster? The card has to run the entire shader anyway to get the alpha value to test on.
    Because alpha test is part of the hardware.

    And what's stopping the hardware vendors from extending shaders to support per-target texkill?
    Because it's redundant in the face of alpha test?

    You may as well say that you should do depth testing in shaders simply because you can. That alpha test hardware is there, it's fast, and it doesn't require a shader conditional followed by a discard. There's no reason not to expose it.

  6. #26
    Junior Member Regular Contributor
    Join Date
    Feb 2005
    Location
    South Tyrol, Italy
    Posts
    107

    Re: OpenGL 3 Updates

    Quote Originally Posted by Khronos_webmaster
    • - Legacy gl_* GLSL state variables are accessible through a common block.
    Why is that? I thought the legacy stuff like modelview and projection matrices, light parameters etc. would go away!
    I would prefer if these would disappear.

    [ www.trenki.net | vector_math (3d math library) | software renderer ]

  7. #27
    Junior Member Newbie
    Join Date
    Sep 2007
    Location
    Ukraine, Krivoy Rog
    Posts
    25

    Re: OpenGL 3 Updates

    As for me, I would like simple drawing mechanism via glBegin/glVertex2(3)/glEnd. It's very convenient way for drawing, for example, fullscreen quad with texture on it. I do not like an idea, that I must create a vertex buffer, fill it with an appropriate vertex data, and store this object as member in my classes. Or, for example, if I need to change a size of fullscreen quad, I must re-fill the buffer again and so on...

    Don't kill convenient glBegin/glEnd approach, only for convenience!

  8. #28
    Junior Member Regular Contributor
    Join Date
    Jan 2005
    Posts
    182

    Re: OpenGL 3 Updates

    Quote Originally Posted by Khronos_webmaster
    [*]- S3TC is a required texture compression format
    I think that's a really bad idea if you want to release OpenGL 3 before 2017.
    S3TC is patented. It would be impossible to implement OpenGL without a patent licence.
    Example: This means that Mesa can't go do OpenGL 3 and thus all the Linux drivers based on it won't support OpenGL 3.

    If OpenGL 3 requires S3TC the free software community will have to create it's own 3D API instead of using OpenGL.

    Philipp

  9. #29
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: OpenGL 3 Updates

    I think it's a bit late for suggesting big changes, the spec is supposed to be nearly finished

    It's the combination of the size and the format that makes it impossible.
    Sometimes it's even worse, it's not only the format, but the combination of format and usage. For example, some hardware might support 16 bit float textures, but only without filtering and mipmapping. Now, if you would simply have a single flag "supports 16 bit float", then you could not answer yes or no, because in certain specific cases, the implementation does actually support 16 bit float.

    You can't possibly enumerate all allowed combinations, so the approach with just trying to create the object and catching the error is the only sensible way this works. Everything else will either restrict the use more than neccessary, or force software emulation.

    Just look at the current situation with NPOT. Some hardware doesn't support full NPOT, but NPOT with some usage restrictions works. Now the vendors can choose, either not expose NPOT at all, or expose NPOT and provide software fallback for when the (unspecifiable) conditions are not satisfied.

  10. #30
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: OpenGL 3 Updates

    Quote Originally Posted by JoeDoe
    As for me, I would like simple drawing mechanism via glBegin/glVertex2(3)/glEnd. It's very convenient way for drawing, for example, fullscreen quad with texture on it. I do not like an idea, that I must create a vertex buffer, fill it with an appropriate vertex data, and store this object as member in my classes. Or, for example, if I need to change a size of fullscreen quad, I must re-fill the buffer again and so on...

    Don't kill convenient glBegin/glEnd approach, only for convenience!
    It's not just convenience. GL2 has at least 5 ways of uploading vertex data (immediate mode, vertex arrays, display lists, compiled vertex arrays, vertex buffer objects), which is bad for driver writers and confusing for end-users.

    Even in the case you mention, I'm not sure that declaring a VBO is less convenient. Immediate mode needs 10 function calls to define a textured quad, while a VBO needs a simple data array, 3 function calls to create it (enable VBOs, generate a handle, upload data) and 1 to draw it. Plus, it's much more efficient - it seems like a win-win situation to me.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

Posting Permissions

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