Bug 11384 - r300: (RS480) Some OpenGL applications have strange rendering characteristics
Summary: r300: (RS480) Some OpenGL applications have strange rendering characteristics
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-26 15:14 UTC by Jesse Burt
Modified: 2009-05-19 06:21 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Example testcase of rendering problem (333.50 KB, image/png)
2007-06-26 16:48 UTC, Jesse Burt
Details
Fglrx's busy-spheres rendering (79.85 KB, image/png)
2007-07-02 21:56 UTC, Phillip Ezolt
Details
Mesa's busyspheres rendering (10.13 KB, image/png)
2007-07-02 21:57 UTC, Phillip Ezolt
Details
fglrx's fogcoord rendering (497.78 KB, image/png)
2007-07-02 21:58 UTC, Phillip Ezolt
Details
Mesa's fogcord rendering (32.27 KB, image/png)
2007-07-02 21:58 UTC, Phillip Ezolt
Details
Fglrx's fog rendering (8.43 KB, image/png)
2007-07-02 21:59 UTC, Phillip Ezolt
Details
Mesa's fog rendering (7.91 KB, image/png)
2007-07-02 22:00 UTC, Phillip Ezolt
Details
Fglrx's 'wave' rendering (6.90 KB, image/png)
2007-07-02 22:01 UTC, Phillip Ezolt
Details
Mesa's 'wave' rendering (1.91 KB, image/png)
2007-07-02 22:02 UTC, Phillip Ezolt
Details

Description Jesse Burt 2007-06-26 15:14:44 UTC
Various OpenGL applications (e.g., Scorched 3D, Neverball, D2X-XL) render scenes incorrectly, with strange results. As an example, the landscape in Neverball is partially (to at times completely) obscured from view by other parts of the scene rendered in smaller pieces that may be described as having been shattered by a hammer in many pieces, scattered all over the window. The results of Scorched3D are the same, though in addition, the menus are not rendered in their entirety. D2X-XL (an implementation of Descent) differs in that most of the scene is black with a small number of lines at the top of the window being rendered in patches of small squares. Example screenshots can be found at:
http://home.comcast.net/~genecide/neverball.png
http://home.comcast.net/~genecide/scorched3d.png
http://home.comcast.net/~genecide/d2x-xl.png

glxinfo output http://home.comcast.net/~genecide/glxinfo


I'm wondering if the three use an extension which simply hasn't been implemented yet in the r300 (or XPress 200M)? D2X-XL mentions when started: Software fallback: ctx->Multisample.Enabled

This is a Presario V5303NR w/an XPress 200M 5955 PCIE on Gentoo x86-32, 2.6.20-gentoo-r7, X.Org 7.2, git mesa & drm (started using git trees about one month ago...has exhibited this behavior since then)

I realize how very very alpha (if even) the 200M support is...I just didn't know if this was something anyone else has run into yet (Through searching I wasn't able to find a bug that sounded satisfactorily similar to this)
Comment 1 Jesse Burt 2007-06-26 16:48:12 UTC
Created attachment 10465 [details]
Example testcase of rendering problem
Comment 2 Adam K Kirchhoff 2007-06-26 17:07:07 UTC
This is definitely Xpress 200 related as I see the same on my laptop but not my x700 or x850.  On all three machines, this i using mesa git from this afternoon.
Comment 3 Dave Airlie 2007-06-26 17:09:12 UTC
I'm trying to get swtcl support for the rs200, but it locks up with too many apps to merge yet, gears and ipers work mostly, but manytex locks the card.. I most of the problem are due to the lack of clipping....
Comment 4 Phillip Ezolt 2007-06-27 06:24:08 UTC
A few weeks ago, I ran some of the demos against the latest X server on my Radeon 200M. 

Here are the results: (If I get a chance, I'll run them against the latest version tonight.)

...
I ran some of the Mesa samples in: '/progs/samples'

Visually Identical:
accum, blendeq, depth, star, stencil

Minor Problems:
line:
 R300 is not pixel identical to fglrx, but they generally look the same.

nurb:
 R300 is not pixel identical to fglrx, but they generally look the same.

olympic:
 R300 is not pixel identical to fglrx, but they generally look the same.

bitmap1:
 fgrlx seems broken.. 'GL' is not shown in the middle.

tri:
 R300 is not pixel identical to fglrx, but they generally look the same.

 I did notice that in the R300 version, the color gradient inside box
 starts a line below the fglrx version.

I did get this warning:

*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 494
Software fallback:ctx->Line.StippleFlag
***************************************************************************

Major Problems:

logo:

 It appears as if the clip plane is completely different, but the
basic geomtery is the same.

point:
 On the R300 version, The crosshairs is one pixel lower.

prim:
 On the R300 version, The openGL crossharis is one pixel lower

fogtest:
 On the R300 version, the end of the tube is not red.

 (In the source, the only thing that is red is:
  static float back_mat_diffuse[] = {1.0, 0.0, 0.0, 1.0};
  glMaterialfv(GL_BACK, GL_DIFFUSE, back_mat_diffuse); )

quad:
 On the R300 version, the interior of the cone is not green.

sphere:

 On the R300 version, the grid lines are missing, and there is a strip
 missing on the cyclinder.

wave:
 On the R300 version, the checkerboard is completely missing. If I
 turn off lighting, the checkerboard appears.

....
progs/demos:

fire:
 On the R300, the trees are corrupt... They're in front of the fire.

cubmap:
 On the R300, This has a wierd corruption as it spins.

terrain:
 On the R300, This has triangles flying everywhere. ;-)

ipers:
 On the R300, Triangles intersect the main geometry.

tunnel:
 On the R300, Triangles intersect the main geometry.
Comment 5 Phillip Ezolt 2007-07-02 21:55:26 UTC
Ok.  I tried the latest mesa+drm+xserver, and things are light years better.

Many of the apps that failed before, now work. (most of the  rss-glx-0.8.1.p-6.fc6 screensavers work, neverball works, neverputt works, nexuiz works)

However, there are still some failures (I'll attach pictures):

mesa/progs/samples/wave:
(The checkerboard pattern doesn't show up.)
However, if you press 'l' (to disable lighting), the checkerboard
pattern shows up. 

...
     case 'l':
        lighting = !lighting;
        if (lighting) {
            glEnable(GL_LIGHTING);
            glEnable(GL_LIGHT0);
            if (rgb) {
                glEnable(GL_COLOR_MATERIAL);
            }
        } else {
            glDisable(GL_LIGHTING);
            glDisable(GL_LIGHT0);
            if (rgb) {
                glDisable(GL_COLOR_MATERIAL);
            }
        }
...
Upon startup, 'lighting' is true, and 'rgb' is true. 


mesa/progs/samples/fog:
The end of the cone is red with fglrx, but not with mesa.
  glMaterialfv(GL_BACK, GL_DIFFUSE, back_mat_diffuse);


mesa/progs/samples/fogcoord:
  This appears as a brown square. (It also has some complaints about not 
supporting 'GL_EXT_fog_coord')

From rss-glx-0.8.1.p-6.fc6:
/usr/bin/busyspheres

A single sphere is visible in the lower left handcorner. (no cool pattern..)


Comment 6 Phillip Ezolt 2007-07-02 21:56:41 UTC
Created attachment 10561 [details]
Fglrx's busy-spheres rendering
Comment 7 Phillip Ezolt 2007-07-02 21:57:23 UTC
Created attachment 10562 [details]
Mesa's busyspheres rendering
Comment 8 Phillip Ezolt 2007-07-02 21:58:17 UTC
Created attachment 10563 [details]
fglrx's fogcoord rendering
Comment 9 Phillip Ezolt 2007-07-02 21:58:53 UTC
Created attachment 10564 [details]
Mesa's fogcord rendering
Comment 10 Phillip Ezolt 2007-07-02 21:59:36 UTC
Created attachment 10565 [details]
Fglrx's fog rendering
Comment 11 Phillip Ezolt 2007-07-02 22:00:47 UTC
Created attachment 10566 [details]
Mesa's fog rendering
Comment 12 Phillip Ezolt 2007-07-02 22:01:25 UTC
Created attachment 10567 [details]
Fglrx's 'wave' rendering
Comment 13 Phillip Ezolt 2007-07-02 22:02:11 UTC
Created attachment 10568 [details]
Mesa's 'wave' rendering
Comment 14 Jesse Burt 2007-07-03 15:51:29 UTC
(In reply to comment #5)
> Ok.  I tried the latest mesa+drm+xserver, and things are light years better.
> 
> Many of the apps that failed before, now work. (most of the 
> rss-glx-0.8.1.p-6.fc6 screensavers work, neverball works, neverputt works,
> nexuiz works)

Most of the rss stuff works for me as well. Neverball is still broken, haven't tried neverputt, haven't tried nexuiz in months (though only tried it once on this machine with fglrx and remember it being _way_ too much for it to handle)

> mesa/progs/samples/wave:
> (The checkerboard pattern doesn't show up.)
> However, if you press 'l' (to disable lighting), the checkerboard
> pattern shows up. 

Ditto
 
> mesa/progs/samples/fog:
> The end of the cone is red with fglrx, but not with mesa.
>   glMaterialfv(GL_BACK, GL_DIFFUSE, back_mat_diffuse);

Ditto
 
> mesa/progs/samples/fogcoord:
>   This appears as a brown square. (It also has some complaints about not 
> supporting 'GL_EXT_fog_coord')

Don't have this in my tree for some reason (updated today Jul 3)

> From rss-glx-0.8.1.p-6.fc6:
> /usr/bin/busyspheres
> 
> A single sphere is visible in the lower left handcorner. (no cool pattern..)

This works perfectly on mine, on the other hand

The demo of Descent 3 in portage seems to work perfectly fine as well, provided the resolution is set to 640x480; nothing lower, nothing higher (else it exhibits some still different problems like seeing through walls) and with great framerate.
Comment 15 Jesse Burt 2007-07-04 08:25:31 UTC
(In reply to comment #14)

**snip**

Disregard; update from this morning has results identical to Phillips'.
Comment 16 Oliver McFadden 2007-07-12 20:33:52 UTC
The fog and wave demos should now be fixed by the recent back facing color commit. 
Comment 17 Jesse Burt 2007-07-13 06:46:42 UTC
(In reply to comment #16)
> The fog and wave demos should now be fixed by the recent back facing color
> commit. 
> 

No luck here- no detriment but these both seem to behave as they had before the commit; rebuilt both drm and mesa trees.
Comment 18 Oliver McFadden 2007-07-14 11:14:47 UTC
Are you sure that you have compiled and installed correctly from git? I can clearly see the fog and wave demos working now.  RS480 could have another bug preventing it from working, though... 
Comment 19 Phillip Ezolt 2007-07-16 06:50:02 UTC
I think that the RS480 might need some additional setup (or something) for the back facing color to work. 

I tried with Mesa+drm+Xserver from last night, and I still see the problem. Since a bunch of R300 changes went in SINCE last night, I'm giving it another try. 
Comment 20 Jesse Burt 2007-07-24 06:03:23 UTC
(In reply to comment #18)
> Are you sure that you have compiled and installed correctly from git? I can
> clearly see the fog and wave demos working now.  RS480 could have another bug
> preventing it from working, though... 
> 

(been out of the loop for a week or two) - Yup...just to make sure though I wiped out both trees and re-cloned them, deleted all the installed libs and kernel modules and started fresh and had the same results.
On another note do any of you get this as drm is init'd?:
PCI: Unable to reserve mem region #1:4000000@d4000000 for device 0000:01:05.0
(1:5.0 is of course the 200m).
Also I can try it again but I believe since one of the last commits I had to reduce the sideport memory from 128 to 64MB in the BIOS, else X wouldn't start. I'll see if someone else has reported something similar before.

Cheers,
Jesse
Comment 21 Nigel Cunningham 2007-08-14 04:38:06 UTC
I just tried the wave demo (current git), and get the pattern if I toggle the lighting, but get the same as Phillip by default.
Comment 22 Maciej Cencora 2009-04-07 06:24:13 UTC
Could you check latest radeon-rewrite branch of mesa?
I fixed twosided lighting there (wave prog was affected).

Fogcoord have been fixed about two months ago (the fix in master).
Comment 23 Maciej Cencora 2009-05-19 06:21:26 UTC
The last failing app (busyspheres) is fixed with 	2240c0d33365189f975b84b06792e2a5ecb8b13a in radeon-rewrite branch. Closing.


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.