[Bug 57875] Second Life viewer bad rendering with git-ec83535

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 10 on bug 57875 from
(In reply to comment #8)
> That bit only exists on r5xx asics.  R3xx and r4xx don't have that bit.
I'd say it's related to floating point depth buffer support. I don't know 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.

(In reply to comment #9)
> I don't remember having anything useful besides some quick hacks and I don't
> have them anymore.
I've written a kernel hack, now the broken geometry is mostly behind the
correct parts. I guess this is where you stopped last time.

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 and the
interaction with the depth buffer format, maybe something like
73856817973caab283427c52152672f524c49a07 is needed. Furthermore I'd like to
find out if this application uses a floating point depth buffer.

> 1) Wine shouldn't use ARB_depth_clamp, but instead it should use an
> extension that exposes CLIP_DISABLE as defined by D3D9 to the user. The
> problem is such an extension doesn't exist.
You could do something like MESA_depth_clamp_hack which uses the entrypoints
and enums of ARB_depth_clamp but only has an effect with GL_DEPTH_TEST off.

> 2) We could agree on a wine-specific hack for r300g, which would expose
> ARB_depth_clamp for Wine only. We already blacklist certain apps for
> Hyper-Z, this would be no different.
Sounds ugly. I'd like to invest a few more days before I start thinking about
that route.

> 3) We could clamp POS.Z to the range [-POS.W, POS.W] in the vertex shader.
> The problem with this approach is the clamping should be per-pixel, not
> per-vertex.
I've been thinking about doing this in Wine before NV_depth_clamp became
ARB_depth_clamp. Claming the Z value in the fragment shader would be easier,
but I think won't work as the geometry would be clipped before it reaches the
fragment stage.


You are receiving this mail because:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux