| Summary: | r200 Radeon driver and Wings 3D | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Christoph Brill <egore> |
| Component: | Drivers/DRI/r200 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | aet |
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| URL: | http://www.wings3d.com | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Christoph Brill
2004-10-25 10:58:11 UTC
Small update: I guess it depends on the Z-Buffer (not sure about that). But lines that should be infront of other which are drawn behind is mostly a problem with the Z-Buffer. Maybe the ordering in Z-Buffer is wrong (meaning the front lines are drawn first and the the back ones, resulting in the back ones being the front ones) or the calculation is different zu ATi's driver (which does it right in wings), meaning that a it you got a something in your Z-Buffer and find something new at the same position you do not overlay it while ATi does ... or the other way around. Forgot to say: Same happens for Radeon 9700Pro as happens for 9000Mobility Hope someone will understand my weird explainations. If not, feel free to ask :D Assigning to dri, since it I think it's their part of responsibility. If I'm wrong, feel free to correct me. the right way to do that is to change the Product to Mesa, and the component to Drivers / DRI / R200. however, if you see this bug on a 9700 without fglrx, then it may be a core Mesa bug... Sorry, I got to correct this: Radeon 9700 Pro on X.org X11 6.8.0 with "radeon" driver (no direct rendering): works Radeon 9000 Mobility Pro on X.org X11 6.8.0 with "radeon" driver (direct rendering): doesn't work => should be a R200 bug Take a look at http://homepages.vype.de/egore/r200-dri.png for how it looks on an r200 and at http://homepages.vype.de/egore/r300-nodri.png for how it looks like on an r300. I hope these examples are quite helpful. The second image shows how it should look like (especially look at the green lines), bit the first one shows typical z-buffer "I-don't-know-what's-in-front" problems. Does it work with tcl_mode=0? I set tcl_mode=0 in my ~/.drirc Nothing changed, problem still persists. Likely causer can be found in r200_state.c starting around line 1995. I dont see why GL_POLYGON_OFFSET_POINT and GL_POLYGON_OFFSET_LINE wouldnt work if hardware renders lines and points, so you are better of just testing it. I dont suppose any of the r200 developers have any info about R200_VF_PRIM_3VRT_POINTS and/or R200_VF_PRIM_3VRT_LINES so that I can fix this for r300 without too much trouble? Aapo, is this bug since long dead and forgotten or do you still need this information? Bugzilla Upgrade Mass Bug Change
NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.
- benjsc
fd.o Wrangler
Do you still have this issue with recent mesa ? Sorry, I can't tell that. My notebook died 2 years ago and the R200 with it. Mass version move, cvs -> git |
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.
