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 > RGBA8888 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=lnk&kid=120709&bid=263057&dat=121642 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
