Announcement

Collapse
No announcement yet.

GLAMOR Acceleration Might Work On Newer X.Org

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

  • #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


            • #21
              Originally posted by jrch2k8 View Post
              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
              my friend please share the mentioned flags you use. Others like me for instance would like to try them as well I believe to see how their millage varies.

              Personally on my install I usually go conservative like -O2 on system libs, -O3 --ffasth-math (or -Ofast) on multimedia & archive compression stuff and few more tweaks here and there

              Comment


              • #22
                Originally posted by ryszardzonk View Post
                my friend please share the mentioned flags you use. Others like me for instance would like to try them as well I believe to see how their millage varies.

                Personally on my install I usually go conservative like -O2 on system libs, -O3 --ffasth-math (or -Ofast) on multimedia & archive compression stuff and few more tweaks here and there
                The only sane reason I can think of doing this is that if you use something a lot it might help. E.g. like giving the lame encoder 30 CFLAGS to make it faster if you encode a lot of audio. Why on earth do this insanity system-wide?

                Seriously, you don't want coreutils with lto and ffast-math.

                Comment


                • #23
                  Originally posted by Rexilion View Post
                  The only sane reason I can think of doing this is that if you use something a lot it might help. E.g. like giving the lame encoder 30 CFLAGS to make it faster if you encode a lot of audio. Why on earth do this insanity system-wide?

                  Seriously, you don't want coreutils with lto and ffast-math.
                  Whatever gave You the idea that I use that for coreutils??? Have You actually read what You comment on? I said I use conservative settings -O2 for system libs, then there is comma in the sentence...

                  Comment


                  • #24
                    Why wouldn't one want LTO for coreutils? ~10% smaller binaries for free.

                    Comment


                    • #25
                      Originally posted by ryszardzonk View Post
                      Whatever gave You the idea that I use that for coreutils??? Have You actually read what You comment on? I said I use conservative settings -O2 for system libs, then there is comma in the sentence...
                      Apologies, I mistook you for jrch2k8.

                      Originally posted by jrch2k8 View Post
                      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]
                      What I want to say is that you notice the speed improvements. But packages can break in subtle ways. Packages could change their behaviour in corner cases which do not get as much production testing. These optimizations are 'ready when they are ready'.

                      Furthermore, multimedia packages are already by default mostly optimized with CFLAGS deemed appropiate by it's original author.

                      Finally, in Gentoo a lot of packages are silently substituting your CFLAGS out of the equation to prevent breakage. The speed improvement is between your ears. However, jrch2k8 mentioning QT4 could be a speed increase. But that is about it.

                      Comment


                      • #26
                        Originally posted by Rexilion View Post
                        Apologies, I mistook you for jrch2k8.
                        no offence taken.


                        Originally posted by Rexilion View Post
                        What I want to say is that you notice the speed improvements. But packages can break in subtle ways. Packages could change their behaviour in corner cases which do not get as much production testing. These optimizations are 'ready when they are ready'.
                        That is true but in my experience I does not happen all that often as it is believed. In years with Linux I reported quite a number of bugs and only like 1/10 of them where flag related and some of those few could be fixed by small changes in the code. In one case for example in this very forum in thread about llvm I reported problem with -DG_DISABLE_ASSERT and it turned out it was fixed with adding just one appropriate ifdef to the code already in place.

                        Originally posted by Rexilion View Post
                        Furthermore, multimedia packages are already by default mostly optimized with CFLAGS deemed appropiate by it's original author.
                        This might be true, but once in the past I tested decompressing speed of apps such as bzip2 and gzip once compiled with different flags -Os, -O2, -O3, -O3 + ffmath, etc and difference between slowest and fastest was 10-15%, where like 2-3% was betwwen -Os and -O2, 7-10% from -O3 and then the rest, so replacing default -O2 with -O3 for apps that use a lot of computations I believe to be very appropriate.

                        Originally posted by Rexilion View Post
                        Finally, in Gentoo a lot of packages are silently substituting your CFLAGS out of the equation to prevent breakage. The speed improvement is between your ears. However, jrch2k8 mentioning QT4 could be a speed increase. But that is about it.
                        Yes it does replace it and one might not harness its full potential when simply is going with the default like the above test reveled for me. Going system wide with all the flags available is just plain wrong and will create problems, but saying they optimization are not to be tried on app by app or lib by lib is just as wrong and IMHO it is not only QT that will gain from it.

                        Personally I would love to now what would be the best way to test speed of flags for libjpeg-turbo, mesa or x264 both encoding and decoding and others like it or better yet someone said that on their specific machine certain flag gives additional boost of "%" with no noticed problems.

                        Comment


                        • #27
                          Originally posted by ryszardzonk View Post
                          Personally I would love to now what would be the best way to test speed of flags for libjpeg-turbo, mesa or x264 both encoding and decoding and others like it or better yet someone said that on their specific machine certain flag gives additional boost of "%" with no noticed problems.
                          I agree with the above statements. However, I want to add that, libjpeg-turbo is mostly handwritten asm. I do not believe that compiler flags will change much about it's performance.

                          Comment

                          Working...
                          X