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
