On an up-to-date fedora rawhide, the xfc4 panel is not rendered properly with a radeon southern islands. It is rendered properly with a radeon evergreen.
Created attachment 95866 [details] evergreen renderer panel
Created attachment 95867 [details] southern islands rendered panel
How about on Evergreen with Option "AccelMethod" "glamor"?
Created attachment 95958 [details] evergreen rendered panel with glamor accelmethod Indeed, it's glamor.
fedora rawhide revision based on git: 8.20140117git2ac2fc0d.fc21
Still not fixed
Does this still happen with glamor from xserver 1.16.0 or later?
up-to-date fedora rawhide with Xorg server 1.16.0 and linux kernel 3.16.0 (recent mesa and llvm) Still wrongly rendered.
Note that xserver 1.16.0 doesn't have the possibly relevant http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.16-branch&id=3c0431b8911241552a15a43e4279c50658b50a18 . What snapshot of glamor were you using when you posted comment 6?
On Tue, Aug 05, 2014 at 06:47:55AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=76213 > > --- Comment #9 from Michel Dänzer <michel@daenzer.net> --- > Note that xserver 1.16.0 doesn't have the possibly relevant > http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.16-branch&id=3c0431b8911241552a15a43e4279c50658b50a18 Ok. Then, I'll test the next release of the xserver once it's landed in fedora rawhide repo (that patch will probably be in). > What snapshot of glamor were you using when you posted comment 6? It was the xserver from fedora rawhide at that time. It was a snapshot right before 1.16, I guess 1.15.xxx something. What's the point of knowing that since it's still not rendered properly in 1.16 ?
(In reply to comment #10) > What's the point of knowing that since it's still not rendered > properly in 1.16 ? I thought it might be fixed by http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.16-branch&id=4e9aabb6fc15d8052934f20c6a07801c197ec36a , which entered xserver 1.15.99.903 but was reverted for the 1.16.0 release because it caused a regression. However, looking at your screenshots more closely again, I suppose your problem is the wrong bevel lines at the bottom of the panel, which I'm still seeing with glamor from current xserver Git.
Created attachment 104134 [details] attachment-25971-0.html Sehr geehrte Damen und Herren, ich befinde mich vom 06.08. bis einschließlich 01.09.2014 im Urlaub. In dieser Zeit lese ich keine Mails. Melde mich nach meinem Urlaub bei Ihnen. Die Mails werden nicht weitergeleitet. Mit freundlichen Grüßen Sancho Dauskardt HERTZ Systemtechnik GmbH Herr Sancho Dauskardt Reinersweg 68 27751 Delmenhorst Germany Telefon: +49 4221 97230-50 Fax Zentrale: +49 4221 97230-19 Fax Einkauf: +49 4221 97230-39 E-Mail: sancho.dauskardt@hertz.st Geschäftsführer: Dipl. Ing. Gerhard Richter Firmensitz: Delmenhorst Registergericht: AG Oldenburg, HRB 140351 Umsatzsteuer-Identifikationsnummer gem. § 27a UStG: DE 152357780 www.hertz.st https://bugs.freedesktop.org/show_bug.cgi?id=76213 --- Comment #11 from Michel Dänzer <michel@daenzer.net> --- (In reply to comment #10) > What's the point of knowing that since it's still not rendered > properly in 1.16 ? I thought it might be fixed by http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.16-branch&id=4e9aabb6fc15d8052934f20c6a07801c197ec36a , which entered xserver 1.15.99.903 but was reverted for the 1.16.0 release because it caused a regression. However, looking at your screenshots more closely again, I suppose your problem is the wrong bevel lines at the bottom of the panel, which I'm still seeing with glamor from current xserver Git.
Created attachment 104135 [details] attachment-25971-1.dat
Created attachment 104136 [details] Textpart.txt
A patch to disable shader-based trapezoids in glamor has been posted to the xorg-devel list which fixes this for me.
commit 7e6bd546846964fd9b8c2a06dea4782a552b62d7 Author: Keith Packard <keithp@keithp.com> Date: Wed Aug 6 12:58:38 2014 -0700 glamor: Remove shader-based trapezoid implementation. Fixes Bug 76213.
what are the implications of disabling shader-based trapezoids? Doesn't that mean all the coverage-data has to be created by the CPU and pushed to VRAM again - making it as slow as it once was?
ping
Keith measured the shader-based trapezoids to be significantly slower than what we have now.
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.