Official feedback on OpenGL 3.1 thread

[JoshKlint]

Regarding my instance shader suggestion:
When you are dealing with vegetation, why is there a need to send the data of each instance to the GPU at all? Why not just draw all you need and let a pre-pass instance shader discard instances based on parameters like vegetation density, etc. The terrain heightmap could be uploaded as a texture to be used to make grass appear only within certain height or slope constraints. You could add a density texture to paint grass onto a terrain with no overhead, and without ever storing all those 4x4 matrices in memory. You could just evaluate 100,000 trees using the parallel pipeline and do a frustrum test for each one, discarding those instances that are not in the camera view.

It makes sense to let the parallelized hardware handle this because a large number of concurrent simple operations are what a GPU is best at.

The instance shader would get run for the number of instances you specify in glDrawElementsInstanced(). It might look something like this:

#define terrainwidth 1024
 
uniform sampler2D heightmap;
uniform sampler2D bumpmap;
uniform sampler2D densitymap;
uniform vec3 terrainscale;
uniform vec4 frustumplane[6];
uniform float maxslope;
uniform float aabbradius;
 
varying mat4 instancematrix;
 
void main( void ) {
 
	//Get the x and y positions and texture coordinate
	float x = gl_InstanceID / terrainwidth;
	float y = gl_InstanceID - x * terrainwidth;
 
	vec2 terraincoord = vec2( x / float(terrainwidth), y / float(terrainwidth) );
 
	x = x - terrainwidth/2.0;
	y = y - terrainwidth/2.0;
 
	//Get terrain height
	float terrainheight = texture2D( heightmap, terraincoord ) * terrainscale.y;
 
	//Create 4x4 matrix for instance varying, gets passed to vertex program
	instancematrix[3][0]=x;
	instancematrix[3][1]=terrainheight;
	instancematrix[3][2]=z;
 
	//Check density map
	if (texture2D( densitymap, terraincoord ).x<0.5) {
		discard;
	}
 
	//Check terrain slope
	float slope = texture2D( bumpmap, terraincoord ).y * 2.0 - 1.0;
	if ( slope > maxslope ) {
		discard;
	}
 
	//Culling test
	for ( int i = 0; i <= 6; i++ ) {
		if (PlanePointDistance( instancematrix[3].xyz, frustumplane[i] )<-aabbradius) {
			discard;
		}
	}
 
	//If the instance hasn't been discarded by this point then it will be drawn!
 
}

[Brolingstanz]

IMO the distinction between making the geometry shader feature core or not would be more significant, if there were vendors that were avoiding implementation of the extension. i.e. if you as a developer wanted to use it but found out that a particular IHV had not implemented it, this could pose a real problem. But my understanding is that it is readily available on both AMD and NVIDIA implementations. So since the actual hard work of implementing it is complete, I would expect that extension to be around as long as the feature still exists in the hardware. Whether that interval is "forever" or "a couple of generations" I do not know.

Yes and perhaps it's safe to say the idea of data amplification will be with us indefinitely, whereas the the form it may take from one hw generation to the next is up for grabs and relatively unimportant to some of us besides. If we don't get too attached to the form but rather the overall function, there's less to lose when the form does finally change -- needless to say it will, eventually. ♫

[Brolingstanz]

Kudos to the ARB on the 3.1 spec!

Really digging the uniform blocks in particular, some really nice changes and additions there.

[LaBasX2]

Hmm, I really like OpenGL but I think we are in a quite bad situation now. For me the worst thing is that OpenGL 3 supports exclusively D3D10 level hardware. It is nice to see that there are some improvements to the API coming up now but we can't really profit from them if we want to continue supporting "older" (mainstream) hardware. If I want my engine to run on an actually great GF 7900 I need to stick to GL 2.1 with all its flaws. Well, as you all know one of the most serious of them is the lack of binary shaders which makes using übershaders quite inefficient since you can't create a shader cache.

I must also say that I think this deprecation thing will not bring anything in practice. None of the current applications would run with a driver which does not expose the deprecated stuff. And which hardware vendor would write a driver which is useless in practice?

The original idea was great and well reasoned: make a GL 3 which runs on all shader-compatible hardware just with a better API and provide a compatibility layer for legacy applications. But now things appear like a real muddle to me

[Rob Barris]

LaBasX2, which features do you see in OpenGL 3.x that you would want to use in your applications ?

Some of them which can be implemented on pre-GL3 hardware are being released and implemented as ARB extensions. So if you can be more specific about which ones you want to use on the older hardware, you might find there's an answer that will work for your code.

edit: I see you explicitly mentioned binary shader caching, you're quite right in that this is not possible with 3.x yet.

[LaBasX2]

Rob, thanks for your reply.

One of the most important topics is certainly the shader system. As others stated before, it should be possible to bind vertex and fragment shaders separately. This in combination with the binary shaders would help fighting the permutation explosion in visually complex games. In theory it would be the best to have a common compiler which compiles code for a profile (as in D3D) so that a prebuilt shader cache can be shipped with the title. But I see that a centralized compiler is difficult with OpenGL's philosophy, so it would also be ok if the shader cache were compiled at the user.

Another thing very useful for deferred shading would be the depth bounds test promoted as core feature (although I'm not sure if ATI can support it natively).

Support for geometry instancing and more control over maximum mipmap levels (for texture streaming) would be other things.

I understand that the features can be exposed as ARB extensions to pre-GL3 hardware but then we will continue having all the problems that we have now: extensions not implemented on some hardware and unstable drivers. Probably it will become even worse since vendors need to support a GL2 and a possibly quite different GL3 path.

The idea of introducing the new API in GL3 and adding D3D10 features in GL4 was a very natural thing. You know that D3D11 is adding backwards compatibility for older hardware again. I think the same needs to happen with the next version of GL. Different hardware generations should be supported by profiles which define a certain feature set. If GL3 will remain limited to D3D10 hardware I don't see how it should have any chance to compete against D3D11 for professional game development.

[skynet]

If I want my engine to run on an actually great GF 7900 I need to stick to GL 2.1 with all its flaws.

Just don't use the "bad" stuff that is marked as deprecated and you'll get decent performance. It seems, most recent extensions will also be available in a 2.1 context, so people can stick with 2.1 for a long time if they really want.

None of the current applications would run with a driver which does not expose the deprecated stuff.

I'm getting tired repeating this over and over again. This statement is just plain wrong. When is the day that people finally understand, that 3.0+ (formerly "Longs Peak") has NEVER been about ditching GL2.1 from one day to another? Both versions would have co-exististed in peace for quite a while. While the old one would mainly get bug fixes, keeping the old API stable, the new one would have got the nice new features.

I don't know how good the deprecation model will work out, but probably not as good as a new API would have done. I'm currently trying to port an engine over to "pure" GL 3.1. I'm facing these problems:

1. The spec language gets confusing and inconstent. There are dozens of binding points for everything. A more "object oriented" approach would have been better. Sometimes there are several ways to retrieve the same information. As a reader, one clearly sees that the spec is a patchwork of many former extensions. It just doesn't look "monolithic". The PDF needs much more hyperlinks in between the document. It is currently very hard to gather information on specific commands, because it can be spread throughout the whole document. A second MSDN-like documentation would be very helpful.

2. The header/libs are not separated from pre-GL3.0 ones. This means, that a) the compiler won't moan about using deprecated commands/enums b) code-suggestion tools like VisualAssist are much less effective (sometimes you have to choose between a vendor/EXT/ARB/core version for _one_ enum!)

3. Even though I requested a forward-compatible 3.1 context, I still get a huge list of extensions, where most of them refer to either deprecated (GL_NV_register_combiners or GL_EXT_texture_env_add anyone?) or superseeded-by-core functionality. What is the advice here? Use them? Do not use them? Prefer corresponding core functionality? It would be good to cut down the extension list as much as possible in order to force people using the preferred way of doing things.

[LogicalError]

LaBasX2 ... I see you explicitly mentioned binary shader caching, you're quite right in that this is not possible with 3.x yet.

... yet?
Hmmm, interesting ...

[Brolingstanz]

I thought so too ;-)

[Brolingstanz]

Skynet, I just put on my 3.1 blinders and that's all I see. Anything not in the 3.1 frustum gets culled, simple as that.

And don't tell me register combiners have been deprecated - I'm just now getting used to them.