Bug 76213

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.