MRT error on Catalyst 10.4 (continue)

Regarding my post here

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=277315#Post277315

I have written small test program to demonstrate my MRT error in ATI catalyst 10.4

The program are written in c++ and required GLFW and GLEW which already include/link in to source
folder.

The code are program using OpenGL 3.2 forward compatibility profile and contain no deprecate function.

The program contain some simple wraping class.

FBO ---> encapsulate basic FBO function and initialization function
Shader ----> encapsulate basic shader loading,activate,deactivate function
TestMRTShader -----> derived from class "Shader" and implement some basic MRT (detail below)
TestModule -----> contain OpenGL initialization and rendering loop

the class TestMRTShader implement some basic MRT function.
the source code of shader are store in folder “./source/STEngineNew/shader/test MRT”
It bind output location in following manner (see TestMRTShader::bindOutputLocation)


	glBindFragDataLocation(this->program,0,"redChannel");
	glBindFragDataLocation(this->program,1,"greenChannel");
	glBindFragDataLocation(this->program,2,"blueChannel");
	glBindFragDataLocation(this->program,3,"yellowChannel");

in TestModule::render has the following code


void TestModule::render(){

	//activate FBO
	this->fbo.activateFBO();

	//select target color buffer
	GLenum targetBuffer[] = {GL_COLOR_ATTACHMENT0,GL_COLOR_ATTACHMENT0+1,GL_COLOR_ATTACHMENT0+2,GL_COLOR_ATTACHMENT0+3};
	this->fbo.selectMultipleDrawBufferByID(targetBuffer,4);

	//clear color
	glClearColor(0.0f,0.0f,0.0f,1.0f);
	glClear(GL_COLOR_BUFFER_BIT);
	
	//activate test mrt shader (glUseProgram)
	this->testMRTShader.activateShader();

	//draw color to target buffer 
	this->testMRTShader.testMRT();
	
	//deactivate shader
	this->testMRTShader.deactivateShader();

	//deactivate FBO
	this->fbo.deactivateFBO();

	//blit selected display color attachment to back buffer 
	glBindFramebuffer(GL_READ_FRAMEBUFFER,this->fbo.fboID);
	this->fbo.selectReadBufferByIndex(displayColorAttachmentIndex);
	glBindFramebuffer(GL_DRAW_FRAMEBUFFER,0);
	glViewport(0,0,this->screenWidth,this->screenHeight);

	glBlitFramebuffer( 0, 0,fbo.width,fbo.height,
	0, 0,this->screenWidth,this->screenHeight,
	GL_COLOR_BUFFER_BIT, GL_LINEAR);
			
	glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
	glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);

	//swap buffer
	glfwSwapBuffers();
	
	//report error
	OGLControl::reportError();

}

at runtime the program select target buffer as
location 0 = GL_COLOR_ATTACHMENT0
location 1 = GL_COLOR_ATTACHMENT1
location 2 = GL_COLOR_ATTACHMENT2
location 3 = GL_COLOR_ATTACHMENT3

and then render fullscreen quad using TestMRTShader.
after the MRT operation the program perform blitting by selecting target color attachment using
variable “displayColorAttachmentIndex”

user can press button 0,1,2,3 to select which target color buffer to display at runtime (initial value is 0).

The correct result as running on Catalyst 10.1-10.3 and GF9800GT should be

press 0 —> display color attachment 0 = red screen
press 1 —> display color attachment 1 = green screen
press 2 —> display color attachment 2 = blue screen
press 3 —> display color attachment 3 = yellow screen

but on Catalyst 10.4 the result are

press 0 —> display color attachment 0 = blue screen
press 1 —> display color attachment 1 = green scrren
press 2 —> display color attachment 2 = red screen
press 3 —> display color attachment 3 = yellow screen

the test program can be download here

http://www.mediafire.com/download.php?zji0yyyhg3t

Anybody know how can I send bug report to AMD/ATI ?

At least I want to be confirmed if this is a bug or not to continue my development.

Please.

I guess you just did in a perfect manner.
Sometime, both AMD and nVidia lack of feedback from bug report beside bug fixed.

I will help to verify it. As the download link is unavailable, could you please provide the test program?

Thanks
Frank

This is the new link that fix archive’s CRC error

http://www.mediafire.com/download.php?wdikfxrmnhm

The website “http://www.mediafire.com/” is forbidden in our network. Could you please send me the program? I have send my email by PM. It seems you missed it:)

Thanks
Frank

Look like the this strange bug/change in behavior is still presents in catalyst 10.5 and I still don’t recived any comment from ATI :sorrow:

This bug could be reproduced. It’s a regression according to what you said. We are going to looking into it. I will tell you if the bug is fixed.

Thanks
Frank

Thanks , Mr. frank. :slight_smile:

Hi MR frank.

Are you an ATI driver developer ?

If you are , I have some question about OpenGL 3.3.
Is this bug also in OpenGL 3.3 core profile ?
I would like to port my APP from OpenGL 3.2 core profile to OpenGL 3.3 core profile but if this bug also in 3.3 I will wait for the next release of driver instead.

Thanks in advance.

UPDATE

I have found the cause of problem.
It look like I call glBindFragDataLocation in the wrong place.

I alway call this function after linking which is suppose to be wrong.

May be in old version of the driver the predefined output location accidently match my parameter (redChannel = 0,greenChannel = 1 1 etc…).

Calling the function before linking as it suppose to be totally fix the problem.

Still have to test this on my brother’s NVIDIA 9800GT card

Ah, of course. Funny how none of us noticed that! glBindFragDataLocation must indeed be called before the program is linked. If nVidia allows it after binding, you were probably lucky it worked on nVidia, or it is a driver bug on their side that they allow calling the function after linking.

In my other topic about transform feedback not working on GF9800GT , I also do the same mistake by calling glTransformFeedbackVarying after linking which is allowed on ATI catalyst 10.3 but generate error
on NVIDIA 197.45 (hadn’t test with newer version so I dont know if catalyst 10.4/10.5 still allow this)

Hi Somboon,
That’s great that you have found the root cause and it won’t block your work right now. I’m an ATI driver developer. We will give you better feedback next time:)
The reason it works on nVidia is luck. If you swap the locations of “greenChannel” and “yellowChannel”, it fails on nVidia too.

I think it’s allowed that we call glTransformFeedbackVarying after linking, but without any effect. Why did you say it’s disallowed?
It’s also strange to generate an error against it, could you please tell me what kind of error is generated.

Thank
Frank