Summary: | r300: (RS480) Some OpenGL applications have strange rendering characteristics | ||
---|---|---|---|
Product: | Mesa | Reporter: | Jesse Burt <avsa242> |
Component: | Drivers/DRI/r300 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Example testcase of rendering problem
Fglrx's busy-spheres rendering Mesa's busyspheres rendering fglrx's fogcoord rendering Mesa's fogcord rendering Fglrx's fog rendering Mesa's fog rendering Fglrx's 'wave' rendering Mesa's 'wave' rendering |
Description
Jesse Burt
2007-06-26 15:14:44 UTC
Created attachment 10465 [details]
Example testcase of rendering problem
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. 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.... 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. 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..) Created attachment 10561 [details]
Fglrx's busy-spheres rendering
Created attachment 10562 [details]
Mesa's busyspheres rendering
Created attachment 10563 [details]
fglrx's fogcoord rendering
Created attachment 10564 [details]
Mesa's fogcord rendering
Created attachment 10565 [details]
Fglrx's fog rendering
Created attachment 10566 [details]
Mesa's fog rendering
Created attachment 10567 [details]
Fglrx's 'wave' rendering
Created attachment 10568 [details]
Mesa's 'wave' rendering
(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. (In reply to comment #14) **snip** Disregard; update from this morning has results identical to Phillips'. The fog and wave demos should now be fixed by the recent back facing color commit. (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. 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... 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. (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 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. 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). 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.