OpenGL 3 Updates

[Rob Barris]

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.

[glDesktop]

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.

[ector]

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.

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.

[bobvodka]

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

[Korval]

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.

[Trenki]

• - 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 ]

[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!

[PkK]

[*]- 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

[Overmind]

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.

[Stephen A]

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.