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
