Bug 74939

Summary: xf86-video-ati: [regression] glitches on the graphical interface on ppc64
Product: xorg Reporter: Kleber Sacilotto de Souza <klebers>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: brking, greg
Version: git   
Hardware: PowerPC   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Example of app with the driver before 94d0d14
none
Example of app with the driver after 94d0d14
none
Example of app with the driver after 94d0d14 (with Gnome3 window decoration)
none
Fix ?
none
possible fix
none
Fix constant upload none

Description Kleber Sacilotto de Souza 2014-02-13 16:25:25 UTC
Commit 94d0d14914a025525a0766669b556eaa6681def7 (EXA/evergreen/ni: fast solid pixmap support) introduced a regression on ppc64, after this change some graphical elements are not being drawn correctly on the interface. This is probably due to endianness issues.

I will attach some pictures of the monitor with examples of apps running before and after 94d0d14.
Comment 1 Kleber Sacilotto de Souza 2014-02-13 16:26:42 UTC
Created attachment 94010 [details]
Example of app with the driver before 94d0d14
Comment 2 Kleber Sacilotto de Souza 2014-02-13 16:27:08 UTC
Created attachment 94011 [details]
Example of app with the driver after 94d0d14
Comment 3 Kleber Sacilotto de Souza 2014-02-13 16:28:22 UTC
Created attachment 94013 [details]
Example of app with the driver after 94d0d14 (with Gnome3 window decoration)
Comment 4 Jerome Glisse 2014-02-20 22:57:50 UTC
Created attachment 94463 [details] [review]
Fix ?

Does this helps ? Can you try different combination ?
Comment 5 Michel Dänzer 2014-02-21 03:08:06 UTC
(In reply to comment #4)
> +#if X_BYTE_ORDER == X_BIG_ENDIAN
> +    buf[0] = pix_a;
> +    buf[1] = pix_b;
> +    buf[2] = pix_g;
> +    buf[3] = pix_r;
> +#else
>      buf[0] = pix_r;
>      buf[1] = pix_g;
>      buf[2] = pix_b;
>      buf[3] = pix_a;
> +#endif

These values are floats, so their order is not subject to endianness. If this change helps, the extraction of pix_r/g/b/a from the packed fg value should be fixed instead.
Comment 6 Kleber Sacilotto de Souza 2014-02-21 17:00:43 UTC
(In reply to comment #4)
> Created attachment 94463 [details] [review] [review]
> Fix ?
> 
> Does this helps ? Can you try different combination ?

Unfortunately, this change, neither different combinations, helped.
Comment 7 Grigori Goronzy 2014-02-22 20:43:21 UTC
Created attachment 94587 [details] [review]
possible fix
Comment 8 Grigori Goronzy 2014-02-22 20:43:38 UTC
It's not correct to swap the values late, they are mangled in various ways before. They need to be swapped right at extraction. Does the attached patch help?
Comment 9 Kleber Sacilotto de Souza 2014-02-24 14:11:12 UTC
(In reply to comment #8)
> It's not correct to swap the values late, they are mangled in various ways
> before. They need to be swapped right at extraction. Does the attached patch
> help?

This doesn't fix the issue either. I have tried something similar as well before.

Thanks.
Comment 10 Jerome Glisse 2014-02-24 16:28:33 UTC
Do you have Xorg log with the faulty commit ?
Comment 11 Jerome Glisse 2014-02-24 19:54:19 UTC
Created attachment 94679 [details] [review]
Fix constant upload

Ok attach patch do fix the issue can you test on your config that it works for you too.
Comment 12 Kleber Sacilotto de Souza 2014-02-24 20:42:58 UTC
(In reply to comment #11)
> Created attachment 94679 [details] [review] [review]
> Fix constant upload
> 
> Ok attach patch do fix the issue can you test on your config that it works
> for you too.

This patch fixed the issue on my ppc64 setup as well.

Thank you!
Comment 13 Jerome Glisse 2014-02-24 23:09:56 UTC
Pushed upstream closing

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.