Bug 27312 - glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB
Summary: glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha compo...
Status: RESOLVED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-25 10:17 UTC by Karthik Hariharakrishnan
Modified: 2011-03-02 06:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
vertex shader used with above code snippet (310 bytes, application/octet-stream)
2010-03-25 10:17 UTC, Karthik Hariharakrishnan
Details
fragment shader used to reproduce bug (220 bytes, application/octet-stream)
2010-03-25 10:18 UTC, Karthik Hariharakrishnan
Details
Source code for reproducing the problem. (12.74 KB, text/plain)
2010-03-26 10:44 UTC, Karthik Hariharakrishnan
Details
header file included from source (1.43 KB, text/plain)
2010-03-26 10:44 UTC, Karthik Hariharakrishnan
Details
Makefile for building app (330 bytes, application/octet-stream)
2010-03-26 10:45 UTC, Karthik Hariharakrishnan
Details

Description Karthik Hariharakrishnan 2010-03-25 10:17:22 UTC
Created attachment 34438 [details]
vertex shader used with above code snippet

In the following code snippet we are using RGBA color buffer which means,

glGetIntegerv(GL_RED_BITS, &red_bits);
glGetIntegerv(GL_GREEN_BITS, &green_bits);
glGetIntegerv(GL_BLUE_BITS, &blue_bits);
glGetIntegerv(GL_ALPHA_BITS, &alpha_bits);

All of the above return 8. 

The shaders are attached. I am unable to give complete code at the moment.

<Code Snippet starts>
projMat_loc = glGetUniformLocation(uiProgram, "mvpMatrix_uni");
glUniformMatrix4fv(projMat_loc, 1, 0, matProjection);

vertices_loc = glGetAttribLocation(uiProgram, "vertex_att");
colors_loc = glGetAttribLocation(uiProgram, "color_att");
txtCoord_loc = glGetAttribLocation(uiProgram, "multiTexCoord_att");
txtSampler = glGetUniformLocation(uiProgram, "texture0");

glEnableVertexAttribArray(vertices_loc);
glEnableVertexAttribArray(colors_loc);
glEnableVertexAttribArray(txtCoord_loc);

glClearColor(0.0f, 0.0f, 0.0f, 0.0f);

texCol[0] = 0.56;
texCol[1] = 0.56;
texCol[2] = 0.56;
texCol[3] = 0.56;

glClear(GL_COLOR_BUFFER_BIT);

glVertexAttribPointer(txtCoord_loc, 2, GL_FLOAT, GL_FALSE, 0, texCoords1);

vertex[0] = 4.5;
vertex[1] = 4.5;

glVertexAttribPointer(vertices_loc, 2, GL_FLOAT, GL_FALSE, 0, &vertex[0]);
glVertexAttribPointer(colors_loc, 4, GL_FLOAT, GL_FALSE, 0, texCol);

glDrawArrays(GL_POINTS, 0, 1);

glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 4, 4, 1, 1, 0); 

glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, (GLfloat)GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, (GLfloat)GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, (GLfloat)GL_CLAMP_TO_EDGE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, (GLfloat)GL_CLAMP_TO_EDGE);

glActiveTexture(GL_TEXTURE0);

glUniform1i(txtSampler, 0); 
glVertexAttribPointer(txtCoord_loc, 2, GL_FLOAT, GL_FALSE, 0, texCoords0);

vertex[0] = 12.5;
vertex[1] = 12.5;
 
col[0] = col[1] = col[2] = col[3] = 1; 

glVertexAttribPointer(vertices_loc, 2, GL_FLOAT, GL_FALSE, 0, &vertex[0]);
glVertexAttribPointer(colors_loc, 4, GL_FLOAT, GL_FALSE, 0, col);

glDrawArrays(GL_POINTS, 0, 1);

tmpBuf = (GLubyte *)malloc(4*sizeof(GLubyte));
glReadPixels(12, 12, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, tmpBuf);  

/*##############################################################
##############################################################
##############################################################
tmpBuf[0]=tmpBuf[1]=tmpBuf[2] = 143 //Expected
tmpBuf[3] = 143 //Not expected - This should be 255 as we are not using this component. I have checked this with other vendors NVIDIA and ATI and they indeed report correct behavior (tmpBuf[3] = 255)
##############################################################
##############################################################
##############################################################*/
</Code Snippet ends>
Comment 1 Karthik Hariharakrishnan 2010-03-25 10:18:05 UTC
Created attachment 34439 [details]
fragment shader used to reproduce bug
Comment 2 Brian Paul 2010-03-25 17:17:14 UTC
Which driver are you using?  swrast or softpipe or other?

I could probably look into this as soon as you provide a (glut) test program.
Comment 3 Karthik Hariharakrishnan 2010-03-26 09:22:01 UTC
(In reply to comment #2)
> Which driver are you using?  swrast or softpipe or other?
> 
> I could probably look into this as soon as you provide a (glut) test program.
> 

Hi,

 I am using the egl driver for window management. I built egl_softpipe.so in src/gallium/winsys/egl_xlib. And am linking with the gallium libraries. I will try uploading the source file soon. 

Comment 4 Karthik Hariharakrishnan 2010-03-26 10:44:37 UTC
Created attachment 34494 [details]
Source code for reproducing the problem.
Comment 5 Karthik Hariharakrishnan 2010-03-26 10:44:59 UTC
Created attachment 34495 [details]
header file included from source
Comment 6 Karthik Hariharakrishnan 2010-03-26 10:45:37 UTC
Created attachment 34496 [details]
Makefile for building app
Comment 7 Karthik Hariharakrishnan 2010-03-26 10:47:04 UTC
(In reply to comment #2)
> Which driver are you using?  swrast or softpipe or other?
> 
> I could probably look into this as soon as you provide a (glut) test program.
> 

I have uploaded the source that uses egl. The LD_LIBRARY_PATH I have used is

<blah>Mesa-7.7/lib/gallium:<blah>/Mesa-7.7/lib.
Comment 8 Chia-I Wu 2010-03-28 01:51:22 UTC
(In reply to comment #0)
> tmpBuf = (GLubyte *)malloc(4*sizeof(GLubyte));
> glReadPixels(12, 12, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, tmpBuf);  
> 
> /*##############################################################
> ##############################################################
> ##############################################################
> tmpBuf[0]=tmpBuf[1]=tmpBuf[2] = 143 //Expected
> tmpBuf[3] = 143 //Not expected - This should be 255 as we are not using this
> component. I have checked this with other vendors NVIDIA and ATI and they
> indeed report correct behavior (tmpBuf[3] = 255)
> ##############################################################
> ##############################################################
> ##############################################################*/
I've tested the demo with current git head, using egl_x11_swrast driver and libGLESv2.  It has the correct behavior (tmpBuf[3] is 255).  Do you want to try again with git head or the to-be-released 7.8?
Comment 9 Marek Olšák 2011-03-02 06:05:07 UTC
No feedback for a year. Closing as invalid.

Anyway, Chia-I Wu said it worked for him.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.