Keith, I'm curious to know how you reminded after so long (7 months)! Did you actually writed it now or was it stuck in a mail queue all this time?
By now I got to more or less to those answers, but thanks anyway. As saying goes: it's better late than never! Regards, José Fonseca On Thu, Oct 10, 2002 at 10:17:06AM +0100, Keith Whitwell wrote: >José Fonseca wrote: >>The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth >>test. After assuring that the mach64's z control register was being set >>properly I realized that the vertex buffers had the z in a [0,1] scale >>while the primitive drawing functions expected them in a a [0,0xffff]. >> >>The previous mach64 (mesa 3.x) driver defined the coord setup as >> >>#define COORD \ >>do { \ >> GLfloat *win = VB->Win.data[i]; \ >> v->v.x = win[0] + xoffset; \ >> v->v.y = - win[1] + yoffset; \ >> v->v.z = win[2]; \ >> v->v.rhw = win[3]; \ >>} while (0) >> >>while for example the R128 defined as >> >>#define COORD \ >>do { \ >> GLfloat *win = VB->Win.data[i]; \ >> v->v.x = win[0] + xoffset; \ >> v->v.y = - win[1] + yoffset; \ >> v->v.z = depth_scale * win[2]; \ >> v->v.rhw = v->v.rhw2 = win[3]; \ >>} while (0) >> >>So I removed the 'depth_scale' in calculation of hw_viewport, in >>mach64CalcViewport, and everything worked fine. >> >>But I still don't understand what's the relationship between >>*CalcViewport and the viewport calculations made in _mesa_set_viewport. >>At _mesa_set_viewport, for instance, there is a comment that says "This >>is really driver-specific and should be maintained elsewhere if at >>all.". It seems that _mesa_set_viewport sets the scale to [0,MaxDepth], >>but the *CalcViewport in most DRI drivers "undo" this scaling, rescaling >>to a [0,1]. > >Correct. The _mesa_set_viewport code is really setting things up for how >the software rasterizer likes it's coordinates. In the Mesa 3.x days, Mesa >would multiply things by the viewport (giving VB->Win), whether you wanted >them or not, then you'd have to undo it with code like the above. Now, the >driver still 'fixes up' the viewport, but at least it doesn't have to do it >per-vertex. > >>My question is why the other DRI drivers do this (don't the chips expect >>the depths in integer format as well?) and in what depth scale should >>the vertex buffers be after all? > >No, there's a good mixture. Some want floats scaled to certain values, >lots want floats in 0..1, all sorts of things. > >>This understanding would be important because the current mach64 >>triangle setup engine is able to specify the z values in 16.1 format, >>but only the 16 integer part is being used, so I would like to implement >>that as well. > >Basically the responsibility for the viewport transformation has been >shifted to the driver. You don't see it because it's hidden in the >t_dd_vbtmp (?) template, but it's the driver that really does it. > >So, you can take ndc coords (VB->ProjectedClipPtr), and manipulate them to >whatever twisted format the hardware likes. > >Keith ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel