Bugzilla – Bug 5601
ATI radeon IGP 320M with dri enabled in blender corrupts screen
Last modified: 2009-08-24 12:23:39 UTC
I have an ATI radeon IGP 320M (mobility U1) card which works well with radeon
driver included in xorg-6.8.2. 2d and 3d accellerations are working.
There is a problem with Blender since xorg-6.9. I tried version 2.37a and 2.40.
After selecting an object, display starts to corrupt :
When I add Option "NoAccel" "YES" in my xorg.conf, blender runs well.
Created attachment 4347 [details]
The Xserver log file
Created attachment 4348 [details]
My xorg.conf file
Created attachment 4349 [details]
The output from lspci -vv.
All snapshots after 200506XX don't work.
But, in snapshots archive, 3 packages works :
- common and radeon "200504XX"
- common "20050512" and radeon "20050516"
And I also tried with the 3 previous release but the drm don't build (my kernel
is probably too recent).
So, the problem comes probably from a patch added between 05-16-2005 and 06-18-2005.
I add also that display is corrupted by only a select of object (right click).
But, when I change view with center click (third button) the display is correct.
If I right click many times, blender-bin seg-fault.
(In reply to comment #4)
> So, the problem comes probably from a patch added between 05-16-2005 and
Looks like it is probably caused by the conversion of the radeon swtcl code to
the t_vertex interface (20050531). I've tried it on my radeon 7200 with blender
2.41 and it is really bad, one single mouseclick and the whole screen is a
garbled mess. As expected though, it works fine with hw tcl (which the IGP
lack), only with tcl_mode=0 those problems appear.
This problem is not limited to radeon. R200 has exactly the same problem, if you
switch off tcl. As a guess, I'd say it's because the t_vertex implementation was
ported from r200 to radeon so it shares the same bugs...
Created attachment 4622 [details] [review]
fix the blender weird triangles bug with sw tcl
This ought to fix both radeon and r200. Apparently, there are problems with
reinstating the vertex format after a raster fallback, it looks like it's
necessary to explicitly do this (the raster fallback happens due to the
GL_SELECT rendermode). I'm a little hesitant to put this into cvs, I'm not
really sure it's the right thing to do. The first two lines don't appear to be
strictly necessary for this (copied from savage driver), and I'm not sure if
it's ok to only do it for the tcl fallback case neither (though it _seems_ to
work without it for hw tcl). Any comments from t_vertex wizards?
not sure if you saw but keithw said it seemed that your code should be fine, as
in it shouldn't case any harm..
*** Bug 2365 has been marked as a duplicate of this bug. ***
commited to both HEAD and 6.4 branch. I hope there aren't any more bugs in the
rasterization fallback, this was not the first.
Mass version move, cvs -> git