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 : http://aprovin.linux62.org/others/screenshots/dri1.png http://aprovin.linux62.org/others/screenshots/dri2.png 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 06-18-2005. 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
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.