Commen=
t # 14
on bug 57875<=
/a>
from Marek Ol=C5=A1=C3=A1k
(In reply to comment #=
10)
> > That bit only exists on r5xx asics. R3xx a=
nd r4xx don't have that bit.
> I'd say it's related to floating point depth buffer support. I don't k=
now
> about the capabilities of the GPUs though and have to read up the
> interactions between depth_clamp and depth_buffer_float again, but I'd
> expect the limited depth buffer range to clamp the values.
There's no floating-point depth buffer support in r500.
> > I don't remember having anything useful bes=
ides some quick hacks and I don't
> > have them anymore.
> I've written a kernel hack, now the broken geometry is mostly behind t=
he
> correct parts. I guess this is where you stopped last time.
>=20
> Before I give up on this I'd like to investigate some more things,
> particularly the interaction with glDepthRange(something similar to
> 92e7c6a2581b5f612a84587500399bb00318c6f0) and the interactions with an=
d the
92e7c6a258 fixes a piglit test which passes with r300g, so it's most probab=
ly
unrelated.
glDepthRange is packed in the Z component of the vectors in
pipe_viewport_state, which is applied after clipping and converts coordinat=
es
from the clip space to the window space.