Test application for ATI cards. Bug reproduced

Hello, at last, I’ve reproduced an annoying bug that happens in the Shader Designer but only with ATI cards. I really don’t know what is wrong in my code (I think that it is OK) and I want to see if is a driver bug or a bug in my gl code. (The bug is related with the uniforms variables in the fragment shader. They doesn’t seem have correct values)
I’m asking for help to discover what causes this behaviour, and I need ATI users, maybe somebody can inspect the source code and discover what is happening, because I ran out of ideas to solve this problem (I’ve spent many weeks trying to isolate/reproduce this problem)

To see the bug, ATI users must run the application from a console and run this shader:
sampleImplementation.exe ./shaders/dimple.gdp

They probably will see a golden sphere (not bumped) while it should looks like this one:
Screenshot

The source code could be grabbed from here:
Source code

Probably unreated but I noticed this bug:

Line

void ApplyBuiltInStates()
{
  glLightModelfv(GL_LIGHT_MODEL_AMBIENT,LightAmbient);  

  glMaterialfv(GL_FRONT,GL_AMBIENT,FrontMaterial.ambient);
  glMaterialfv(GL_FRONT,GL_AMBIENT,FrontMaterial.diffuse);
  glMaterialfv(GL_FRONT,GL_AMBIENT,FrontMaterial.specular);
  glMaterialfv(GL_FRONT,GL_AMBIENT,FrontMaterial.emission);
  glMaterialf(GL_FRONT,GL_AMBIENT,FrontMaterial.shininess);
  
  glMaterialfv(GL_BACK,GL_AMBIENT,FrontMaterial.ambient);
  glMaterialfv(GL_BACK,GL_AMBIENT,FrontMaterial.diffuse);
  glMaterialfv(GL_BACK,GL_AMBIENT,FrontMaterial.specular);
  glMaterialfv(GL_BACK,GL_AMBIENT,FrontMaterial.emission);
 glMaterialf(GL_BACK,GL_AMBIENT,FrontMaterial.shininess);

Should probably be:

void ApplyBuiltInStates()
{
  glLightModelfv(GL_LIGHT_MODEL_AMBIENT,LightAmbient);  

  glMaterialfv(GL_FRONT,GL_AMBIENT,FrontMaterial.ambient);
  glMaterialfv(GL_FRONT,GL_DIFFUSE,FrontMaterial.diffuse);
  glMaterialfv(GL_FRONT,GL_SPECULAR,FrontMaterial.specular);
  glMaterialfv(GL_FRONT,GL_EMISSION,FrontMaterial.emission);
  glMaterialf(GL_FRONT,GL_SHININESS,FrontMaterial.shininess);
  
  glMaterialfv(GL_BACK,GL_AMBIENT,FrontMaterial.ambient);
  glMaterialfv(GL_BACK,GL_DIFFUSE,FrontMaterial.diffuse);
  glMaterialfv(GL_BACK,GL_SPECULAR,FrontMaterial.specular);
  glMaterialfv(GL_BACK,GL_EMISSION,FrontMaterial.emission);
  glMaterialf(GL_BACK,GL_SHININESS,FrontMaterial.shininess);

That last “shininess” value was generating GL errors…

ops! that’s a copy paste error, too many hours writting this example. I’ve just uploaded an updated version at the web.

Well I’m almost out of ideas.
The only think that I did noticed was my shader editor was getting a little confused. (I have fixed it now)

What was happening is that you specify the length of the GLSL string including the NULL terminator(s). I don’t think this should confuse the ATI compiler, but who knows, try just specifying the length excluding the trailing NULL’s.

I’ve just uploaded a new version, with those little changes in the shader loading code you’d told me. I don’t think that now will work, but I have no ideas of what could be the problem…

I noticed this line

glEnable(GL_POINT_SMOOTH);

ATI drivers don’t like it.

Originally posted by V-man:
[b]I noticed this line

glEnable(GL_POINT_SMOOTH);

ATI drivers don’t like it.[/b]
Incredible, The bug is caused by this single line. 3 versions of the Shader Designer affected by a bug caused only by this line… Now I want to see how many time will take ATI in reply my bug report (I sent it one week ago and I have no answer yet). Moreover, with latest Catalyst drivers, the Shader Designer crashes (in a glDrawElements line, with a shader activated), bug report sent too, but no reply…
I’ve sent them to Humus, but he must be out…

This week I’ll upload a revision of the SD with an option to disable point smooth…

P.D: Advice to new OpenGL programmers: If you want to be a good OpenGL programmer, you MUST know ALL VERSIONS of ALL DRIVERS of ALL GFX VENDORS, better than their own developers.

And thanks to V-man and sqrt[-1] :slight_smile:

Originally posted by Ffelagund:
Incredible, The bug is caused by this single line. 3 versions of the Shader Designer affected by a bug caused only by this line…
Yep, I know what you are talking about. I have spent severals hours today finding why my shaders run terribly slow on ATIs ( on NVIDIAs there were no problems ). Finaly I have discovered that somewhere in my code I have enabled GL_LINE_SMOOTH …when I removed this line everything was OK…
I just cant see any connection between shaders and GL_LINE_SMOOTH but ATI probably can :slight_smile:

I’ve had the same problem with gl_point_smooth and point sprites. The code worked until I upgraded the drivers. This was almost a year ago and I’ve upgraded the drivers several times since then but it was only lately I found that it was the enable gl_point_smooth line that ruined it all. Evil stuff.

Leif…

Hi,

i’ve sent a bug report too, maybe a month ago. It was a memory leak that appears when enabling/disabling GL_POINT_SMOOTH while using a shader.
If i switch the state, my app starts eating memory, but if i don’t call glDisable(GL_POINT_SMOOTH) there is no memory leak.
I’ve tested in other cards and with Catalyst drivers from 3.8 to 5.4 and found that:

  • With Intel cards there is no memory leak (so it seems an ATI related problem)
  • With Catalyst 3.8 to 3.10 and 4.2 to 4.5 there is no memory leak.
  • The bug is related with the change in the state, there is no need to draw points, just enabling and disabling GL_POINT_SMOOTH.

Still waiting for ATI answer…

I just found out for myself that line_smooth throws it into software rendering although I don’t render any lines.
Enabling point_smooth caused a consistent crash.

I also had a couple of other shaders that would crash on linking, although they would fit the hw Ok.
No problem with these on NV.

I’m just glad most of my shaders are ok.

I’ve received news from Humus. He confirmed me that this is bug in ATI drivers (thanks to the repro application), and the GL_POINT_SMOOTH and GL_LINE_SMOOTH issue is now in the fix queue, so I hope that will be fixed soon.

It seems what in Catalyst 6.1 this bug still didn’t fixed. I get “Access violation reading location 0x00000130.” with this simple shader:

/// vertex shader
void main()
{
	gl_Position = gl_MultiTexCoord0*vec4( 2., 2., 1., 1. ) - vec4( 1., 1., 0., 0. );
}

/// fragment shader
uniform float fill;
void main()
{
	gl_FragColor.x = fill;
}

and enabled GL_LINE_SMOOTH.

The repro case that was sent to us still works fine. This was fixed quite a while ago.
I tried grisha’s shader and it didn’t crash, but caused software rendering. Are you drawing lines using this shader?

No, I’m rendering triangles.

Here is a full test:

#include <GL/glew.h>
#include <GL/glut.h> 

GLuint fb_, color_rb_[2], object_;

void init_app()
{
	glewInit();

	glEnable( GL_LINE_SMOOTH );

	glGenFramebuffersEXT( 1, &fb_ );
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, fb_ );

	glGenTextures( 2, color_rb_ );

	glBindTexture( GL_TEXTURE_2D, color_rb_[0] );
	glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB32F_ARB, 1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, color_rb_[0], 0 );

	glBindTexture( GL_TEXTURE_2D, color_rb_[1] );
	glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB32F_ARB, 1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, color_rb_[1], 0 );

	GLenum status = glCheckFramebufferStatusEXT( GL_FRAMEBUFFER_EXT );

	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 );

	char const vshader[] =
		"void main()
"
		"{
"
		"	gl_Position = gl_MultiTexCoord0*vec4( 2., 2., 1., 1. ) - vec4( 1., 1., 0., 0. );
"
		"}
";

	char const fshader[] =
		"uniform float fill;
"
		"void main()
"
		"{
"
		"	gl_FragColor.x = fill;"
		"}
";

	object_ = glCreateProgram();
	GLuint shader_object = glCreateShader( GL_VERTEX_SHADER );
	GLchar const * text = vshader;
	GLint length = sizeof(vshader)-1;
	glShaderSource( shader_object, 1, &text, &length );
	glCompileShader( shader_object );

	GLint compiled = 0;
	glGetShaderiv( shader_object, GL_COMPILE_STATUS, &compiled );
	if( compiled )
		glAttachShader( object_, shader_object );

	glDeleteShader( shader_object );

	shader_object = glCreateShader( GL_FRAGMENT_SHADER );
	text = fshader;
	length = sizeof(fshader)-1;
	glShaderSource( shader_object, 1, &text, &length );
	glCompileShader( shader_object );

	compiled = 0;
	glGetShaderiv( shader_object, GL_COMPILE_STATUS, &compiled );
	if( compiled )
		glAttachShader( object_, shader_object );

	glDeleteShader( shader_object );

	glLinkProgram( object_ );
	GLint linked = 0;
	glGetProgramiv( object_, GL_LINK_STATUS, &linked );

	glUseProgram( object_ );
	GLuint fill_uni = glGetUniformLocation( object_, "fill" );
	glUseProgram( 0 );

	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, fb_ );
	glDrawBuffer( GL_COLOR_ATTACHMENT0_EXT + 1 );
	glReadBuffer( GL_COLOR_ATTACHMENT0_EXT + 1 );
	glActiveTexture( GL_TEXTURE1 );
	glBindTexture( GL_TEXTURE_2D, color_rb_[0] );
	glActiveTexture( GL_TEXTURE0 );

	glViewport( 0, 0, 1024, 1024 );

	glUseProgram( object_ );
	glUniform1f( fill_uni, -1.f );

	glBegin( GL_TRIANGLE_STRIP );
	glTexCoord2f( 0.f, 1.f );
	glVertex2f( 0.f, 1.f );
	glTexCoord2f( 0.f, 0.f );
	glVertex2f( 0.f, 0.f );
	glTexCoord2f( 1.f, 1.f );
	glVertex2f( 1.f, 1.f );
	glTexCoord2f( 1.f, 0.f );
	glVertex2f( 1.f, 0.f );
	glEnd();

	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 );
	glUseProgram( 0 );
}

int main( int argc, char* argv[] )
{
	glutInit( &argc, argv );
	glutInitDisplayMode( GLUT_DOUBLE | GLUT_DEPTH | GLUT_RGB );
	glutCreateWindow( "test" );
	glutReshapeWindow( 800, 600 );
	init_app();

	return 0; 
} 

I get AV on glBegin call. This happens on RADEON 9550.

Originally posted by grisha:
No, I’m rendering triangles.
So why do you enable GL_LINE_SMOOTH?

Originally posted by Humus:
So why do you enable GL_LINE_SMOOTH?
This code snipped is only to demonstrate this bug. In my app I draw lines (without shaders) - and all of them drawn with GL_LINE_SMOOTH, so I just enabled it at startup.

Can I ask why line smooth state affects drawing of triangles?

Because glPolygonMode() can turn triangles into lines. Now of course, the driver could validate based on derived primitives, but it’s a significant amount of work to fix this.
For now you should just disable GL_LINE_SMOOTH when you don’t need it.

not a significant amount of work for the nvidia implementation, obviously.

If bug X in Internet Explorer takes Y amount of time to fix, does it follow that an equivalent bug X in Firefox also takes Y amount of time to fix?