I stumbled upon a bug in the Radeon driver while using Wings 3D. The Modeler
Wings 3D highlights edges with drawing it over normal edges of a model. This
works fine with nvidias binary driver and atis binary driver.
With the Radeon driver the order that the lines are drawn is reverted. This
means that the highlighted (colored) edge is drawn first and the normal edge
above it which results that you cannot see any highlighted line.
Any one else had problem like that?
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
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
Bugzilla Upgrade Mass Bug Change
NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.
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.