OpenGL 3 Updates

[n00body]

Firstly, not 100% happy that certain promised features were cut, but I can understand the reasoning for it. Better to have it out when it's "done".

Secondly, I'm happy that much of the cruft has been stripped out, and many features that needed to be core functionality have been made so.

Thirdly, I'm curious, will there be code examples soon after BoF? It's impossible to make an informed judgment without working code in front of me.

Thanks.

EDIT:
In particular, I'd like to see actual code usage of the new direct_access extension. Since it looks like the most dramatic change to arrive with OGL 3.0, I'd like to see how to use it.

EDIT2:
My only other comment, to any Khronos members is this: Dropping an iron curtain on all outgoing info for two years was both painful and unnecessary. A mistake that shouldn't be repeated.

[ector]

EDIT2:
My only other comment, to any Khronos members is this: Dropping an iron curtain on all outgoing info for two years was both painful and unnecessary. A mistake that shouldn't be repeated.

Yup, it's pretty sad to see that Microsoft is very open, shares information a year in advance and looks for feedback, and also DELIVERS ON SCHEDULE, while ARB/Krhonos, well, you know what I mean...

[tanzanite]

Firstly, not 100% happy that certain promised features were cut, but I can understand the reasoning for it. Better to have it out when it's "done".

I think we are done with that dance.

[Lumooja]

[*] OpenGL 3 will not have support for the GL_DOUBLE token. This means it will not be possible to send double precision vertex data to OpenGL.

I wonder how many people know that double is almost 3 times faster than float (2.875 to be exact).

Try it yourself:

// doublespeed.cpp
 
#include <stdio.h>
#include <time.h>
 
 
inline void floatrun(void)
{
	float m=0.0f;
	float n=0.0f;
	long t1=0;
	long t2=0;
	long i=0;
	printf("Counting 1.4 billion floats...\n");
	t1=clock();
	while(m<1000.0f)
	{
		n=0.0f;
		while(n<1000.0f)
		{
			n+=0.01f;
			i++;
		}
		m+=0.01f;
	}
	t2=clock();
	printf("Done. i=%ld, n=%f, time=%fs.\n",i,n,
	(double)(t2-t1)/CLOCKS_PER_SEC);
}
 
 
 
inline void doublerun(void)
{
	double m=0.0;
	double n=0.0;
	long t1=0;
	long t2=0;
	long i=0;
	printf("Counting 1.4 billion doubles...\n");
	t1=clock();
	while(m<1000.0)
	{
		n=0.0;
		while(n<1000.0)
		{
			n+=0.01;
			i++;
		}
		m+=0.01;
	}
	t2=clock();
	printf("Done. i=%ld, n=%f, time=%fs.\n",i,n,
	(double)(t2-t1)/CLOCKS_PER_SEC);
}
 
 
int main(int argc, char** argv)
{
	floatrun();
	doublerun();
	floatrun();
	doublerun();
	return 0;
}

[bobvodka]

That benchmark looks like junk, but aside from that current GPU hardware has very little double support (iirc the GTX series can do double in hardware at around 1/4 the speed of a floating point operation and using more resources) and previous generations had none at all.

In short; what you wrote was utter rubbish.

[Jan]

You are doing the printf AFTER you started your timer. That is complete crap.

[Lumooja]

ATI is releasing next month 2 new cards which use double precision:

http://ati.amd.com/technology/stream...ream_9250.html

Maybe there I would get similar results like on my CPU double vs float speed test. And it's not only about speed, the horrible accuracy of float is a big problem with large distance objects (like shadows of directional lights) in games and applications.

[Lumooja]

You are doing the printf AFTER you started your timer. That is complete crap.

I moved the printf before the timer start, but it didn't make any difference since it was done the same way for both functions.

But you're right, now the timing results have more reference value.

[bobvodka]

ATI is releasing next month 2 new cards which use double precision:

http://ati.amd.com/technology/stream...ream_9250.html

Maybe there I would get similar results like on my CPU double vs float speed test.

No, because double is also just "crippled" in AMD's hardware.

And it's not only about speed, the horrible accuracy of float is a big problem with large distance objects (like shadows of directional lights) in games and applications.

In games it's all about the speed vs accuracy tradeoff; more speed at the cost of accuracy is acceptable and losing 1/4 of your ALU power for a gain in accuracy is NOT good for games.

[bobvodka]

You are doing the printf AFTER you started your timer. That is complete crap.

I moved the printf before the timer start, but it didn't make any difference since it was done the same way for both functions.

But you're right, now the timing results have more reference value.

Your test is still junk, certainly without knowing what compiler and settings you used.

For example, with SSE you can process 4 floats vs 2 double (and that double is 64bit) without SSE you take a possible speed hit due to 32bit -> 80bit conversion when things get punted to the FPU and then back again.