Announcement

Collapse
No announcement yet.

GLAMOR Acceleration Might Work On Newer X.Org

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Well, Michel wasn't the only one who ran into this. I was able to reproduce this issue on my work machine, which forced me to either downgrade my graphics drivers and kernel or switch to the catalyst blob. In the interests of expediency, I decided to install catalyst until glamor worked again... Maybe I'll try to switch back one of these days.

    For anyone interested:
    I've got a Radeon 5400-series, but there were weird graphical artifacts in any kernel newer than 3.5 (I was testing 3.8 rc's when I finally switched to catalyst), although I don't remember the 3.6 series too well. Switching to glamor helped to fix this (I'm assuming that EXA/2D is to blame), but then when 1.13 showed up in xorg-edgers it broke glamor.

    Comment


    • #12
      The transition to systemd was long and painful for me. Took about 2 months, and I had to fix another problem recently. Just saying so that people donít believe it was easy for everybody (and Iím afraid itís not the end of it as they keep changing systemd).

      Comment


      • #13
        Originally posted by stqn View Post
        The transition to systemd was long and painful for me. Took about 2 months, and I had to fix another problem recently. Just saying so that people donít believe it was easy for everybody (and Iím afraid itís not the end of it as they keep changing systemd).
        well in gentoo is and was easy for me and counting the fact i use gcc 4.7.2 and my make.conf pass around 30 flags to gcc including LTO/Graphite/bulldozer specifics/etc.[have a regular set of flags too without lto for some problematic packages maybe 30 in my whole emerge world] and i compile using 24 threads and 1 lto instance per cpu[6/AMD Fx 6100 <-- my little monster] and my /var/tmp/portage is entirely on a Ram disk[not bragging though just saying my gentoo is very bleeding edge in every sense and never failed me with openrc or systemd unlike upstart that gaved me some headaches when i was in the dark side]

        about changes in systemd so far 0 problems if i do dispatch-conf before restart[if you don't i agree can get ugly], portage is kinda awesome to solve this issues but lot more complex than apt if you are not familiar with compilers/C/C++ and patch/dev utilities

        Comment


        • #14
          Originally posted by jrch2k8 View Post
          my make.conf pass around 30 flags to gcc
          That's insane...

          Comment


          • #15
            Originally posted by Rexilion View Post
            That's insane...
            jajajaja yes but is pretty much rock solid even so[kdelibs+lto still bitch a lot tho], this urban legends that claim that flags make software unstable is from the gcc 4.2-4.5 era, so far gcc 4.7.2[and 4.8-9999 for testing] have proved to me that it can produce very clean binaries regardless the flags and things like FMA/Graphite/autovectorization/LTO/PGO[pending in most packages] can improve responsiveness and performance quite high if you remove the hardware bottlenecks[SSD and at least 4gb ram].

            and i have to admit AMD hit it out of the stadium with zambezi+ architectures, i mean yeah sure if you are ever going to run 1 app in 1 thread is not awesome but if you like me do 100 thing and mostly are well threaded is a freaking workhorse, in fact my gentoo box can compile Qt4 using 128thread/12LTO threads while im reaping a video(WMV/mpg to WebM) and amarok/pulseaudio never skip and firefox/kdevelop stay 100% responsive the whole time and playing with flags little by little i got to improve it.

            for example
            Qt-gui with -o2 native is fast ofc but you notice few Ms delay between click and apps opening
            Qt-gui with my 30 flags is almost open when you take your finger of the mouse
            Qt-gui with my 30 flags + PGO[<-- not easy] is instant i mean freaking instant

            so if you dare to play with your compiler setting you can gain some free perfomance and squeze some additional responsiveness

            Comment


            • #16
              Originally posted by jrch2k8 View Post
              well in gentoo is and was easy for me and counting the fact i use gcc 4.7.2 and my make.conf pass around 30 flags to gcc including LTO/Graphite/bulldozer specifics/etc.[have a regular set of flags too without lto for some problematic packages maybe 30 in my whole emerge world] and i compile using 24 threads and 1 lto instance per cpu[6/AMD Fx 6100 <-- my little monster] and my /var/tmp/portage is entirely on a Ram disk[not bragging though just saying my gentoo is very bleeding edge in every sense and never failed me with openrc or systemd unlike upstart that gaved me some headaches when i was in the dark side]

              about changes in systemd so far 0 problems if i do dispatch-conf before restart[if you don't i agree can get ugly], portage is kinda awesome to solve this issues but lot more complex than apt if you are not familiar with compilers/C/C++ and patch/dev utilities
              In my case, on the device I have systemd on, I never used OpenRC to begin with. It was all GRUB2+systemd from the get-go. On the second device where I have Gentoo, it is still running OpenRC, as I don't really care enough about it to update it one way or another.

              Comment


              • #17
                Originally posted by jrch2k8 View Post
                so if you dare to play with your compiler setting you can gain some free perfomance and squeze some additional responsiveness
                Well actually the flags beyond "-march=native -o2" don't necessarily improve application performance. It might help for some, but hurt for others. From my experience, it's mostly kernel settings that improve responsiveness (PREEMPT and a few others).
                IMHO what's most interesting about Gentoo is the flexibility. You can choose (almost) exactly what is installed, and you know why. You can mix stable/unstable software with incredible ease as long as you know what you're doing.

                Back on topic, this is probably great news for Radeon HD 7000 open source support. Might come in handy when I upgrade my 5850 sometime in the future.

                Comment


                • #18
                  Or maybe not

                  Chris Wilson is claiming it's still broken.

                  Maybe it's just partially working, or is worse on Intel or something.

                  http://lists.x.org/archives/xorg-dev...ch/035730.html

                  Comment


                  • #19
                    Originally posted by smitty3268 View Post
                    Chris Wilson is claiming it's still broken.

                    Maybe it's just partially working, or is worse on Intel or something.
                    On 1.14, not 1.13, and it at least runs, if I understand that message correctly.

                    Comment


                    • #20
                      Originally posted by GreatEmerald View Post
                      On 1.14, not 1.13, and it at least runs, if I understand that message correctly.
                      Resolved. glamor is up and running tests right now on SandyBridge.

                      Comment

                      Working...
                      X