Bug 755 - Polygons disappear when using glDepthFunc and glPolygonOffset
Summary: Polygons disappear when using glDepthFunc and glPolygonOffset
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r128 (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Eric Anholt
QA Contact:
URL: http://ozlabs.org/~paulus/glbug.c
Depends on:
Reported: 2004-06-15 15:22 UTC by Paul Mackerras
Modified: 2004-07-03 20:49 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Patch to fix glPolygonOffset on r128 (567 bytes, patch)
2004-06-20 16:58 UTC, Paul Mackerras
Details | Splinter Review

Description Paul Mackerras 2004-06-15 15:22:25 UTC
Running emilia pinball on a Rage 128, the floor and walls aren't drawn.

I distilled down the GL calls that pinball does into the glbug.c test program at
http://ozlabs.org/~paulus/glbug.c.  If you run it with no arguments it should
put up a window with a white background and one grey quad visible.  If you run
it with an argument (it doesn't matter what) it will do two additional GL calls:

        glPolygonOffset(1, 1);

and on a Rage 128 the quad is no longer drawn, but with software rendering or on
a radeon the quad is still visible.  I have verified that the bug shows up on a
PowerMac G4 cube running Linux with a Rage 128 PF, a PC with a Rage 128 Pro
Ultra TR, and a titanium PowerBook G4 running Linux.

There are two other GL calls in the test program that are also needed to show
the bug:


If I take those out the quad is rendered even if I do the glPolygonOffset call.
Comment 1 Paul Mackerras 2004-06-20 16:58:11 UTC
Created attachment 391 [details] [review]
Patch to fix glPolygonOffset on r128

In my test program, the glPolygonOffset call changes the Z values given to
r128_draw_triangle from about 0.9 to about 1.9.  Since Z values at this point
are supposed to be scaled to between 0 and 1, this explains why the polygons

The problem seems to be that ctx->MRD, the minimum resolvable depth, is still
1.0.  Setting it to rmesa->depth_scale, which is 1/65536 when using a 16-bit
depth buffer, looks right to me and in fact fixes the problem.

Could this go into CVS please?
Comment 2 Eric Anholt 2004-06-20 17:16:11 UTC
DEPTH_SCALE looks like the thing to be setting for that.  I'll whack this one
with the t_vertex.c conversion.
Comment 3 Eric Anholt 2004-07-04 13:49:38 UTC
Committed.  Sorry for the delay -- r128 t_vertex.c conversion is not working out
like expected.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.