From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 57875] Second Life viewer bad rendering with git-ec83535 Date: Thu, 06 Dec 2012 18:52:59 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1063618661==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id E06DEE6970 for ; Thu, 6 Dec 2012 10:52:58 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1063618661== Content-Type: multipart/alternative; boundary="1354819978.8B2BAE0B1.22486"; charset="us-ascii" --1354819978.8B2BAE0B1.22486 Date: Thu, 6 Dec 2012 18:52:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D57875 --- Comment #10 from Stefan D=C3=B6singer --- (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 a= bout 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 do= n'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, particul= arly 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 abo= ut 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 t= he fragment stage. --=20 You are receiving this mail because: You are the assignee for the bug. --1354819978.8B2BAE0B1.22486 Date: Thu, 6 Dec 2012 18:52:58 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Commen= t # 10 on bug 57875<= /a> from Stefan D=C3=B6singer
(In reply to comment #8=
)
> That bit only exists on r5xx asics.  R3xx and r4=
xx don't have that bit.
I'd say it's related to floating point depth buffer support. I don't know a=
bout
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, particul=
arly
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 inste=
ad 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 r3=
00g, 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 abo=
ut
that route.

> 3) We could clamp POS.Z to the range [-POS.W, PO=
S.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 t=
he
fragment stage.


You are receiving this mail because: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1354819978.8B2BAE0B1.22486-- --===============1063618661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1063618661==--