Comment # 10
on bug 57875
from Stefan Dösinger
(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:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
