Re: [Mesa3d-dev] Texture function opengl specification
Roland Scheidegger wrote: Jerome Glisse wrote: According to fragment program extension, TEX, TXP, ... should give you the right A value (Ap depending on which texture unit you are using). That's not how I read that. TEX,TXP,... refer to texture sampling only, there is no thing as previous unit there. Thus, for an RGB texture, A should be always 1. What induced me to this , is that in fragment program extension description they say to look at table 3.21 and in this one there is reference to Ap for A in RGB. Anyway i think you are right here. What version of the spec are you using? Table 3.21 only lists the component mapping here. Well, if my theory is sound, then the glean pixelFormats test is wrong. I don't think the test is wrong as-is. It's just that GL_COMBINE mode exercises things in a different way. A better way, in fact. I'll clean up your patch, Roland, and check it in. I'll check if GL_ARB_texture_env_combine is supported at run time. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Texture function opengl specification
Brian Paul wrote: Well, if my theory is sound, then the glean pixelFormats test is wrong. I don't think the test is wrong as-is. It's just that GL_COMBINE mode exercises things in a different way. A better way, in fact. I'll clean up your patch, Roland, and check it in. I'll check if GL_ARB_texture_env_combine is supported at run time. Sorry I didn't express that clearly. The test was ok, but not if you use USE_FRAG_PROG (which is what caused the errors on r300), which should behave the same as when using GL_COMBINE mode unless I'm missing something. This still appears to be wrong (when the GL_REPLACE path is executed with USE_FRAG_PROG set), maybe the test should just be run 3 times instead (fixed function GL_REPLACE, GL_COMBINE and fragment prog, if the extensions are supported). Roland - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Texture function opengl specification
Roland Scheidegger wrote: Brian Paul wrote: Well, if my theory is sound, then the glean pixelFormats test is wrong. I don't think the test is wrong as-is. It's just that GL_COMBINE mode exercises things in a different way. A better way, in fact. I'll clean up your patch, Roland, and check it in. I'll check if GL_ARB_texture_env_combine is supported at run time. Sorry I didn't express that clearly. The test was ok, but not if you use USE_FRAG_PROG (which is what caused the errors on r300), which should behave the same as when using GL_COMBINE mode unless I'm missing something. This still appears to be wrong (when the GL_REPLACE path is executed with USE_FRAG_PROG set), maybe the test should just be run 3 times instead (fixed function GL_REPLACE, GL_COMBINE and fragment prog, if the extensions are supported). OK, I'll look at the frag prog path. I really just threw that in for a quick test, not thinking it would actually be used thereafter... -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture function opengl specification
Jerome Glisse wrote:
According to fragment program extension, TEX, TXP, ... should
give you the right A value (Ap depending on which texture unit
you are using).
That's not how I read that. TEX,TXP,... refer to texture sampling
only, there is no thing as previous unit there. Thus, for an RGB
texture, A should be always 1.
What induced me to this , is that in fragment program extension
description they say to look at table 3.21 and in this one there is
reference to Ap for A in RGB. Anyway i think you are right here.
What version of the spec are you using? Table 3.21 only lists the
component mapping here.
Well, if my theory is sound, then the glean pixelFormats test is wrong.
I've tried to trivially fix it up and also made it possible to use tex
env combine mode. I think this might break the glDrawPixels tests but
oddly enough that didn't happen. I did get a lots of failures though
with an old radeon (and I'm sure r200 will fail too), turns out it
uncovers some driver bugs... radeon and r200 only have an i8
single-component format, and you can't use that for a8 or l8 as the
alpha (or rgb respectively) values will be wrong - guess there was a
reason those formats weren't used initially... (not sure exactly why it
doesn't work for L8, as I'd think if the ALPHA_IN_MAP isn't set this
should work). I'm not quite sure how to fix that, the by far easiest
method is to just use al88, but it would be possible to hack up tex env
instead (and for the r200, fragment shader progs too - ugh). Anyway,
r300 shouldn't have that problem with its native texture sampling
swizzling/component replace.
Roland
Index: tpixelformats.cpp
===
RCS file: /cvsroot/glean/glean/src/glean/tpixelformats.cpp,v
retrieving revision 1.8
diff -u -r1.8 tpixelformats.cpp
--- tpixelformats.cpp 2 Oct 2006 19:50:53 - 1.8
+++ tpixelformats.cpp 15 Oct 2006 13:58:59 -
@@ -39,6 +39,7 @@
#define USE_FRAG_PROG 0
+#define USE_TEXENV_COMBINE 1
namespace GLEAN {
@@ -840,7 +841,11 @@
exp[1] = 0;
exp[2] = 0;
exp[testChan] = 255;
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_ALPHA:
exp[0] = 0;
@@ -852,7 +857,11 @@
exp[0] =
exp[1] =
exp[2] = testChan == 0 ? 255 : 0;
- exp[3] = 0; // fragment's alpha
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
+ exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_LUMINANCE_ALPHA:
exp[0] =
@@ -888,7 +897,11 @@
exp[1] = 0;
exp[2] = 0;
exp[testChan] = 255;
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_ALPHA:
exp[0] = 0;
@@ -900,7 +913,11 @@
exp[0] =
exp[1] =
exp[2] = testChan == 0 ? 255 : 0;
- exp[3] = 0; // fragment's alpha
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
+ exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_LUMINANCE_ALPHA:
exp[0] =
@@ -933,7 +950,11 @@
exp[0] = 255;
exp[1] = 0;
exp[2] = 0;
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_ALPHA:
exp[0] = 0;
@@ -945,7 +966,11 @@
exp[0] =
exp[1] =
exp[2] = 255;
- exp[3] = 0; // fragment's alpha
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
+ exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_LUMINANCE_ALPHA:
exp[0] =
@@ -979,7 +1004,11 @@
exp[0] = 0;
exp[1] = 255;
exp[2] = 0;
+#if USE_FRAG_PROG || USE_TEXENV_COMBINE
+ exp[3] = 255;
+#else
exp[3] = 0; // fragment's alpha
+#endif
break;
case GL_ALPHA:
exp[0] = 0;
@@ -991,7 +1020,11 @@
exp[0] =
Texture function opengl specification
Hi,
I am wondering if i am fully understanding how texture value
should be computed. I am refering here to section 3.8.13
of opengl specification and specialy to table 3.21.
My understanding is that when you got an RGB texture the
As = 1 but when computing you use Ap which equal to the
primary color component of incoming fragment if you are
texture 0, or to the previous A value if you are texture 0
ie if you are texture 1 you use A from texture 0, if you are
texture 2 you use A from texture 1 right ?
According to fragment program extension, TEX, TXP, ... should
give you the right A value (Ap depending on which texture unit
you are using). I got the feeling that r300/r400 hardware doesn't
follow this. At least fglrx driver (one packaged in ubuntu edgy)
fail at pixel format test using TEX instruction. I also attach a
small app which should test that. If you launch it res should
be (255, 0, 0, 0) but i will be (255, 0, 0, 255). If anyone could
test that on a windows with r300 hardware.
I may also don't fully understand this part of the specification :)
Btw the Ap value seems a bit hard things to follow i guess that
ATI might have choose to save some silicon and simplify design
than to conform to this specification.
best,
Jerome Glisse
#include assert.h
#include stdio.h
#include stdlib.h
#include string.h
#define GL_GLEXT_PROTOTYPES
#include GL/glut.h
#define W 64
#define H 64
static GLubyte my_image[W*H*4];
static GLuint alphaBits;
#define USE_FRAG_PROG 1
void makeCheckImages(void)
{
int i, j, c;
for (i = 0; i H; i++) {
for (j = 0; j W; j++) {
c = i0x8)==0)^((j0x8)==0)))*255;
c = 255;
my_image[j * 4 + i * W * 4 + 0] = (GLubyte) c;
my_image[j * 4 + i * W * 4 + 1] = (GLubyte) 0;
my_image[j * 4 + i * W * 4 + 2] = (GLubyte) 0;
my_image[j * 4 + i * W * 4 + 3] = (GLubyte) 0;
}
}
}
void init(void)
{
glGetIntegerv(GL_ALPHA_BITS, alphaBits);
printf(GL_ALPHA_BITS: %d\n, alphaBits);
glDrawBuffer(GL_FRONT);
glReadBuffer(GL_FRONT);
glClearColor(0.0, 0.0, 0.0, 0.0);
makeCheckImages();
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, W, H, 0,
GL_RGBA, GL_UNSIGNED_BYTE, my_image);
#if USE_FRAG_PROG
{
GLuint prog;
static const char *progText =
!!ARBfp1.0\n
TEX result.color, fragment.texcoord[0],
texture[0], 2D; \n
END \n
;
if (!glutExtensionSupported(GL_ARB_fragment_program)) {
printf(Error: GL_ARB_fragment_program
not supported!\n);
exit(1);
}
glGenProgramsARB(1, prog);
glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, prog);
glProgramStringARB(GL_FRAGMENT_PROGRAM_ARB,
GL_PROGRAM_FORMAT_ASCII_ARB,
strlen(progText),
(const GLubyte *) progText);
if (glGetError()) {
fprintf(stderr, Bad fragment program, error: %s\n,
glGetString(GL_PROGRAM_ERROR_STRING_ARB));
exit(0);
}
}
#endif
}
void display(void)
{
GLubyte *res = (GLubyte *)malloc(W * H * 4);
glClear(GL_COLOR_BUFFER_BIT);
glViewport(0, 0, W, H);
glColor4f(0.0, 0.0, 0.0, 0.0);
glEnable(GL_TEXTURE_2D);
#if USE_FRAG_PROG
glEnable(GL_FRAGMENT_PROGRAM_ARB);
#endif
glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0); glVertex2f(-1.0, -1.0);
glTexCoord2f(1.0, 0.0); glVertex2f( 1.0, -1.0);
glTexCoord2f(1.0, 1.0); glVertex2f( 1.0, 1.0);
glTexCoord2f(0.0, 1.0); glVertex2f(-1.0, 1.0);
glEnd();
#if USE_FRAG_PROG
glDisable(GL_FRAGMENT_PROGRAM_ARB);
#endif
glDisable(GL_TEXTURE_2D);
glFlush();
// glutSwapBuffers();
glReadPixels(0, 0, W, H, GL_RGBA, GL_UNSIGNED_BYTE, res);
printf(pixel(0,0)=(%d, %d, %d, %d)\n,
my_image[0],my_image[1],
my_image[2],my_image[3]);
printf(-res(0,0)=(%d, %d, %d, %d)\n,
res[0],res[1],
res[2],res[3]);
free(res);
}
void reshape(int w, int h)
{
glLoadIdentity();
}
void keyboard(unsigned char key, int x, int y)
{
switch ( key ) {
case 27:
exit(0);
break;
default:
break;
}
}
void idle(void)
{
// glutPostRedisplay();
}
int main(int argc, char** argv)
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_RGBA);
glutInitWindowSize(W, H);
glutCreateWindow(BUG 7235);
init();
glutDisplayFunc(display);
glutReshapeFunc(reshape);
glutKeyboardFunc(keyboard);
glutIdleFunc(idle);
glutMainLoop();
return 0;
}
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture function opengl specification
Jerome Glisse wrote: Hi, I am wondering if i am fully understanding how texture value should be computed. I am refering here to section 3.8.13 of opengl specification and specialy to table 3.21. My understanding is that when you got an RGB texture the As = 1 but when computing you use Ap which equal to the primary color component of incoming fragment if you are texture 0, or to the previous A value if you are texture 0 ie if you are texture 1 you use A from texture 0, if you are texture 2 you use A from texture 1 right ? yes, though not A from texture 0/1 but A from texture environment 0/1. However, this is only true if you use the fixed texture environment modes, this has no relevance if you use combine mode, where you specify all args directly. So at least for the combine mode, it is really necessary that As is indeed 1 for RGB textures. According to fragment program extension, TEX, TXP, ... should give you the right A value (Ap depending on which texture unit you are using). That's not how I read that. TEX,TXP,... refer to texture sampling only, there is no thing as previous unit there. Thus, for an RGB texture, A should be always 1. I got the feeling that r300/r400 hardware doesn't follow this. Well, apparently r300 should not only support swizzling, but also replacing some args with 1 or 0. For the case of RGB888 textures, those aren't supported anyway, so there is absolutely no difference to a RGBA texture for the hw - the mesa texstore function should fill in the 1's. At least fglrx driver (one packaged in ubuntu edgy) fail at pixel format test using TEX instruction. I also attach a small app which should test that. If you launch it res should be (255, 0, 0, 0) but i will be (255, 0, 0, 255). If anyone could test that on a windows with r300 hardware. Maybe the test could be broken? I think at least for your app, (255,0,0,255) is the right answer. If you'd not use frag progs but instead of GL_REPLACE a tex combine function you'd get the same. I may also don't fully understand this part of the specification :) Btw the Ap value seems a bit hard things to follow i guess that ATI might have choose to save some silicon and simplify design than to conform to this specification. As said, I don't think that previous environment needs to be tracked. table 3.21 defines how the component mapping works, and the rest is left up to the fragment program without the opengl implementation trying to change the meaning of the arguments depending on what type of texture is bound. Roland - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture function opengl specification
On 10/14/06, Roland Scheidegger [EMAIL PROTECTED] wrote: Jerome Glisse wrote: Hi, I am wondering if i am fully understanding how texture value should be computed. I am refering here to section 3.8.13 of opengl specification and specialy to table 3.21. My understanding is that when you got an RGB texture the As = 1 but when computing you use Ap which equal to the primary color component of incoming fragment if you are texture 0, or to the previous A value if you are texture 0 ie if you are texture 1 you use A from texture 0, if you are texture 2 you use A from texture 1 right ? yes, though not A from texture 0/1 but A from texture environment 0/1. However, this is only true if you use the fixed texture environment modes, this has no relevance if you use combine mode, where you specify all args directly. So at least for the combine mode, it is really necessary that As is indeed 1 for RGB textures. I guess i still don't fully get all the subtle difference that happen when you are in fixed pipeline or in vp/fp one. I will study this again :). According to fragment program extension, TEX, TXP, ... should give you the right A value (Ap depending on which texture unit you are using). That's not how I read that. TEX,TXP,... refer to texture sampling only, there is no thing as previous unit there. Thus, for an RGB texture, A should be always 1. What induced me to this , is that in fragment program extension description they say to look at table 3.21 and in this one there is reference to Ap for A in RGB. Anyway i think you are right here. I got the feeling that r300/r400 hardware doesn't follow this. Well, apparently r300 should not only support swizzling, but also replacing some args with 1 or 0. For the case of RGB888 textures, those aren't supported anyway, so there is absolutely no difference to a RGBA texture for the hw - the mesa texstore function should fill in the 1's. At least fglrx driver (one packaged in ubuntu edgy) fail at pixel format test using TEX instruction. I also attach a small app which should test that. If you launch it res should be (255, 0, 0, 0) but i will be (255, 0, 0, 255). If anyone could test that on a windows with r300 hardware. Maybe the test could be broken? I think at least for your app, (255,0,0,255) is the right answer. If you'd not use frag progs but instead of GL_REPLACE a tex combine function you'd get the same. I may also don't fully understand this part of the specification :) Btw the Ap value seems a bit hard things to follow i guess that ATI might have choose to save some silicon and simplify design than to conform to this specification. As said, I don't think that previous environment needs to be tracked. table 3.21 defines how the component mapping works, and the rest is left up to the fragment program without the opengl implementation trying to change the meaning of the arguments depending on what type of texture is bound. Roland Thx for helping me on that, i was a bit confuse on how all this should work. Jerome Glisse - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
