Announcement

Collapse
No announcement yet.

GLAMOR Acceleration Might Work On Newer X.Org

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

  • GLAMOR Acceleration Might Work On Newer X.Org

    Phoronix: GLAMOR Acceleration Might Work On Newer X.Org

    The widely-believed thought was X.Org Server 1.13 (or newer) wasn't working with the GLAMOR acceleration library to run 2D over OpenGL. GLAMOR is explicitly needed for AMD Radeon HD 7000 series acceleration support while it's an optional feature to the Intel driver. It turns out, however, that GLAMOR might already work with the latest X.Org Server...

    http://www.phoronix.com/vr.php?view=MTMyNTI

  • #2
    That was funny

    Gave me a good hearty laugh.

    Comment


    • #3
      OMG can't believe it LOL
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Originally posted by duby229 View Post
        That was funny

        Gave me a good hearty laugh.
        But on the other side, it's not funny at all! (Think about it)

        Comment


        • #5
          Well that is another proof rolling release community distros like Arch and Gentoo do more work testing and bugfixing while Canonical claims all the glory. If you notice, this email is an answer to an Arch-related question, i followed it too through the Arch bug tracker.

          The bleeding edge-rolling release model found this out, if we had waited for Ubuntu we would have waited months or even years more... And no, no systems were broken during this discovery and experimentation... That is how a serious distro works, people...

          Now you Ubuntu n00bs and fanbois, go around in other threads and scream "Rolling release model is bad and unstable" again...

          Comment


          • #6
            Arch/Gentoo have for sure more tech-oriented users, and tinkerers. No big deal that they influence upstream developemnt.

            If you want to compare rolling vs fixed point releas strategies you MUST compare distros with equall tech-oriented users numbers. Otherwise you risk basing conclusions on biased data

            Comment


            • #7
              I'm not saying rolling is unstable, but:

              How was your sysVinit-to-systemd migration back in october 2012? :3

              Comment


              • #8
                Originally posted by Calinou View Post
                I'm not saying rolling is unstable, but:

                How was your sysVinit-to-systemd migration back in october 2012? :3
                I was using arch at that time and had no problems.

                Comment


                • #9
                  Perfectly well.

                  Just switched off comp. service for sysvinit

                  But I switched to Arch AFTER it switched to systemd just to look at beautifil KDE 4.10 and to see how systemd performs. (Both experiences went well )

                  Comment


                  • #10
                    Originally posted by Calinou View Post
                    I'm not saying rolling is unstable, but:

                    How was your sysVinit-to-systemd migration back in october 2012? :3
                    Went off without a hitch actually lol :P

                    Comment


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

                              Working...
                              X