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.
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.
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.
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.
heh, my bad… for some reason I just totally blanked on the new system o.O
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.
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 ]
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!
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
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.
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.
There’s no place for that in OpenGL any more. Convenience stuff can go into GLU (and I hope it will instead of just disappearing).
Philipp
I thought the legacy stuff like modelview and projection matrices, light parameters etc. would go away!
They are. But glslang compilers can still recognize these bits of state, should the user of legacy glslang code wish to use that legacy state.
What there won’t be is actual context state for these. You have to provide the data as uniforms if you want to use them.
No, it’s faster to kill fragments in the shader. I’m not aware of any reason why alpha test should be faster. Alpha test forces the shader to be executed in full. With discard it can be optimized to various degrees. If you issue the discard at the top of the shader the hardware could potentially early-out. I believe for instance GF 8000 series do this. ATI cards do run the entire shader, however, at least all texture lookups are killed for dead fragments which saves bandwidth. That’s supported in the X1000 series and up IIRC (might be supported in the X800 generation too, don’t remember exactly).
It’s worth noting that DX10 has removed alpha test. I think it’s a good candidate for removal from OpenGL as well.
Alpha test is the redundant feature. It’s less flexible and offers no advantage of shader controlled fragment kills. With alpha test you burn an output channel that could be used for something useful. Alpha test is a legacy from the fixed function days.
Except that kills z-optimizations and is incompatible with multisampling. There are no particular “alpha-test optimizations” that the hardware does, it’s rather the case that alpha-test is more of a headache for the hardware.
The conditional could be removed if OpenGL exposed a clip() equivalent that’s available in DX, if the compiler isn’t smart enough to convert your conditional to a clip() under the hood anyway. Btw, I disagree with the “fast” part. It’s slow and provided for compatibility with legacy applications. It’s a good candidate for removal from hardware as well.
Indeed, S3TC is a strange requirement. Who is actually using it by the way ? I am sincere.
Every major game out there for the last 5 years. The performance increase it offers over uncompressed textures is pretty dramatic, and as a bonus consumes less memory. The slight quality loss is very often worth it.
Indeed, S3TC is a strange requirement.
Not really.
Take a good look at this forum. How many developers mistakenly look on extensions as something to be avoided where possible? They look at extensions as conditionally supported, even those that are commonly supported by virtually all implementations.
S3TC is basic functionality, whether patented or not. It is expected of any hardware, and not having it be a core feature suggests to people that it is not widely available. This is not the image that GL 3.0 needs to project.
Every major game out there for the last 5 years.
Oh, I think longer than that.
S3TC started showing up around the transition to the GeForce 2. And it was such a popular idea that Quake 3 was patched to allow for it. Even today, most games use S3TC where they can. Plus, S3TC artifacts aren’t nearly as noticeable on higher-resolution textures.
A format object has to be specified per texture attachment when a Program Environment Object is created. This helps minimize the shader re-compiles the driver might have to do when it discovers that the combination of shader and texture formats isn’t natively supported by the hardware.
Hmmm.
Now, I understand perfectly well why this is done. Instances of programs (I really wish you would call them instances rather than “environment objects”) may provoke recompilation based on what format of texture you use. And you don’t want to allow for the possibility of provoking recompilation during times that aren’t conceptually setup (like using a program instance rather than simply building one).
That being said… there’s got to be a better way. The problem here is simple: I have to create an entirely new instance if I want to switch a texture from RGBA32 to, say, S3TC. The problem is that things that don’t make a difference with regard to program recompilation are being swept up with things that do.
Maybe you could have it so that attaching a texture object/sampler pair to a program instance slot can fail. That way, you can mix and match formats so long as it isn’t “too different”, which is implementation defined.
Alpha test is the redundant feature. It’s less flexible and offers no advantage of shader controlled fragment kills. With alpha test you burn an output channel that could be used for something useful. Alpha test is a legacy from the fixed function days.
Except that kills z-optimizations and is incompatible with multisampling. There are no particular “alpha-test optimizations” that the hardware does, it’s rather the case that alpha-test is more of a headache for the hardware.
The conditional could be removed if OpenGL exposed a clip() equivalent that’s available in DX, if the compiler isn’t smart enough to convert your conditional to a clip() under the hood anyway. Btw, I disagree with the “fast” part. It’s slow and provided for compatibility with legacy applications. It’s a good candidate for removal from hardware as well. [/QUOTE]
Alpha test and fragment kill is not the same.
With alpha func, you have control over the function (AlphaFunc) and can provide a reference alpha.
With discard, it depends on the GPU, but the first spec that came out (ARB_fragment_shader), a fragment was killed if a component was negative.
Is alpha func actually a hw or is it simulated with shaders?
Why is DOUBLE being dropped? We know that future hardware will be able to support it, regardless. Isn’t OpenGL supposed to be a forward looking standard?
Will EXT framebuffer object be core?
Nevertheless, I am looking forward to GL3, and see how much it parallels OpenGL ES 2.