OpenGL 3 Updates

[Jan]

"If you're introducing a new extension, you might as well just introduce the extended draw call. "

Bingo! And that was the question we began with: Will this extended drawcall be introduced in gl 3?

I'd say from now on we will run in circles, so why don't we drop the subject, it's been a boring repetition of the same discussion that we had already a year ago, anyway.

Ah, here is another question for the BOF:

#42 (yes, that one's mine!): Some ATI guy mentioned, that they are waiting for the ARB to standardize the nVidia/DX10 extensions, to then enable those features on ATI hardware, too. Sooo: Are there any plans to extend 2.1 with standardized extensions for DX10 features, at all, or might he only be referring to gl 3. In the first case: what would be the point to introduce a new API AND maintain an old API, although there is obviously not enough man-power to accomplish only one of the tasks. How would the ARB justify such a decision, seeing that all the people who might "need" the high-end features will be the first to happily grab on to gl 3, anyway.

Jan.

[MZ]

What are vertex declarations for when you have GL's flexible setup.

It's about splitting vertex array setup to mutable and immutable parts. It doesn't take away your flexiblity, because majority (but not all) of VA properites are naturally immutable (component offsets relative to each other, types, formats, stream frequency)

In D3D the immutable part is called Vertex Declaration, the mutable part is state vector of VB bindings and their offsets.

GL 2.x desn't make this distinction, so you have to drag the de facto immutable part along with you each time you update the mutable part.

In GL 3.0, as in shape from the last newsletter, at first it looked like everything was going to be immutable(!). Then, from posts by ARB people here, we got vague bits of information that some properties of VA setup will be mutable afterall. Later then, there was "Long Peaks Reloaded" announced, which indicated they are going to address the issue. And then came The Age of Silence. It's unknown what the solution will look like.

[CatDog]

That's not a hack, it's implicit in the fact that OpenGL doesn't give performance guarantees.

But I'd like to have an API that gives performance guarantees. Do I have to switch to D3D now?

CatDog

[EvilOne]

This "base vertex index" and it's counterpart "start index" work in D3D since the stone age. Nice feature... Stuff all into large buffers and then: draw, draw, draw. No need to respecify pointers.

And yes, I think we need something equivalent to D3D vertex declarations... this should make any driver happy. And it's just as flexible as OpenGL's current pointer mania, but very predictable for a driver.

Regarding shaders, I hope they go back to some ARB VP/FP like API... The current compile and link phase is annoying. And those fancy glGetUniformLocation and glGetAttribLocation simply don't belong to the OpenGL RUNTIME, they belong to the (yet to do) TOOLS. And a binary shader representation of some form would be damn nice... Instead of a compiler, just an optimizer and some code transformator (to card specific code) is needed. Come on, a compiler in the driver? The most idiotic decision ever...

And I hope for something like the D3D caps bits... I like to know before resource creation what works, and what not. No trial and error config.

Just make the API simple and clean. If I look at my rendering path in D3D, the code is often three to four time smaller than the equivalent GL path.

And I'd like to know what is the state of GL3 support from Apple? As Apple is my primary reason to keep my GL path alive.

[knackered]

If I look at my rendering path in D3D, the code is often three to four time smaller than the equivalent GL path.

Seeing as though you're talking of caps bits I'll assume you're using d3d9. In which case I don't know what you're talking about - my d3d9 code is quite a bit longer than the equivalent gl code. And a helluva lot uglier.

[bobvodka]

And those fancy glGetUniformLocation and glGetAttribLocation simply don't belong to the OpenGL RUNTIME, they belong to the (yet to do) TOOLS.

I disagree, and so does D3D10 to a degree; the ability for the driver to map streams as makes sense for the underlaying hardware is an important one. Sure, you can force it but letting the driver decide where you should bind things makes sense it knows about the hardware.

It would appear D3D10 works in much the same way; you specifiy the input to the shader and a given semantics name and then you bind inputs to this name (and in D3D10 it is a free form name, as with GLSL) and the runtime links everything together.

[EvilOne]

@knackered

Yeah, my current target is D3D9. Nice and mature API, most of the installed base out there is XP and D3D9. So no need to switch to D3D10 currently.

Hmmm. I have more code in the tools than in the runtime. I preprocess most of the stuff offline into an API-friendly form. To be true, my runtime engine is not very "intelligent" - just designed for simplicity - it's actually really silly :-)

It starts with simple things like renderstates.

Example from the engine runtime:

/// Sets the render states.
static void SetRenderStates(int count, const unsigned int* values)
{
	for(int i = 0; i < count; i++)
	{
		const unsigned int state = *values++;
		const unsigned int value = *values++;
 
		if(Cache[state] == value)
			continue;
 
		Device->SetRenderState(state, value);
		Cache[state] = value;
	}
}

Now do that with current GL...

And now come shaders into play... with ARB VP/FP semantics it was fun, just as simple to wrap as in D3D... but then GLSL shader stuff comes into play. This is the real pain in the arse... btw, thats why I am a happy Cg user. Nice for offline processing even when using GL.

The nice thing for D3D10 is, you can save the structs from the output merger (D3D10_DEPTH_STENCIL_DESC and D3D10_BLEND_DESC) directly with the tools... and on load time, just do some CreateDepthStencilState and CreateBlendState. So render state setup is just two ints into the arrays of blend and depth-stencil states... Equivalent for rasterizer states. Damn, somehow I like to do a D3D10 path now.

[EvilOne]

@bobvodka

I haven't experimented with D3D10 that much. But imho, at the end of the day, you don't have to query anything. Just give the same names in the declaration and the shader, and you are ready to run.

[V-man]

I don't know if this was asked.

Question#Z What's going to happen to GLSL? Is it going to get an offline compiler. Try making 500 relatively complex shaders and compile and measure the time. You'll see that it might take a minute.

Question#2 GLSL : I'm assuming gl_TexCoord and other built in names are getting eliminated.

Question#3 Extensions : there was a time when extensions were great. Everyone offered ARB_Multitexture, EXT_Multitexture, ARB_cubemap, EXT_cubemap, ARB_texture3D, EXT_texture3D. Now in the modern age, many companies are not offering the latest extensions that appear at opengl.org/registry. Strangely still, some extensions don't appear in opengl.org/registry.
====Anyway, get rid of extensions. All extensions are experimental and shitty. D3D programmers like D3D since it doesn't have extensions.
Make features go into core quickly and remove the extension from glGetString(GL_EXTENSIONS).
Why? Because ALL extensions are experimental and you shouldn't release a product that uses it.
All features must go into core quickly and all IHVs should stay up to date with the new GL core.

[bobvodka]

@bobvodka

I haven't experimented with D3D10 that much. But imho, at the end of the day, you don't have to query anything. Just give the same names in the declaration and the shader, and you are ready to run.

Correct, but the query is still required and is still in the runtime; the difference is atm GL splits it into two stages and requires you to make a note of it.

Maybe I got the wrong end of what you were arguing for/against...