Announcement

Collapse
No announcement yet.

real fglrx 12.3 released

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

  • #16
    Originally posted by zbiggy View Post
    @bridgman - you look like someone who has contact with Linux Catalyst team.
    Can you tell Linux Catalyst team to drop XvBA completely and provide driver for VDPAU api? XvBA is dead. Nobody except XBMC uses it. And on XBMC XvBA causes problems.
    Bridgman is the manager of the open source graphics team at AMD. He's not really supposed to have a whole lot of dealings with the Catalyst team, because they work on two completely separate drivers. No doubt they avoid talking about detailed technical things, because it's possible that the Catalyst team could leak encumbered IP accidentally to the open source team and it might get out {And then AMD would lose their signed contract with The Devil (err, I mean, the MPAA a.k.a. the SS) -- ohnoes! :O :P}

    At best, he's a colleague to the guys who work on the Catalyst driver. But I am really doubtful that he would have any persuasive sway with the Catalyst team when it comes to the features offered by Catalyst, because that's not his driver. He's probably just slightly more persuasive than a random member of the public if he were to blatantly walk up to the Catalyst team and start telling them what he thinks should be included (or not included) in Catalyst.

    I do have some direct contact with the Catalyst team, but I still can't put to-do list items on their plate. They still independently decide what to do (or not do) with their driver.

    Comment


    • #17
      Originally posted by allquixotic View Post
      Bridgman is the manager of the open source graphics team at AMD. He's not really supposed to have a whole lot of dealings with the Catalyst team, because they work on two completely separate drivers. No doubt they avoid talking about detailed technical things, because it's possible that the Catalyst team could leak encumbered IP accidentally to the open source team and it might get out {And then AMD would lose their signed contract with The Devil (err, I mean, the MPAA a.k.a. the SS) -- ohnoes! :O :P}

      At best, he's a colleague to the guys who work on the Catalyst driver. But I am really doubtful that he would have any persuasive sway with the Catalyst team when it comes to the features offered by Catalyst, because that's not his driver. He's probably just slightly more persuasive than a random member of the public if he were to blatantly walk up to the Catalyst team and start telling them what he thinks should be included (or not included) in Catalyst.

      I do have some direct contact with the Catalyst team, but I still can't put to-do list items on their plate. They still independently decide what to do (or not do) with their driver.
      I agree it's really tough to get the attention of company developers, just look at the gaming industry 90% of the time the developers are tied up implementing things to make money and the PR guys get slammed with ideas and suggestions. This is sort of the same here the best thing to do is just keep the notion alive among the Linux community eventually it will get someones attention not as fast as other OS's but their are proud Linux users whom are also developers it just what they're allowed to do and when things get the okay or go ahead. I have feeling if canonical was aware and involved with the issue it might get attention slightly faster, but that's just speculation on my part.

      Comment


      • #18
        @bridgman

        The supported pci-ids did not change at all from 12-2 to 12-3 when you look at the fglrx kernel module. from 12-1 to 12-2 only 2 ids where added (679e and 990a). So the only change could be in the control file to get rid of unsupported hardware. And the devs needed so long to do that, really really bad joke. That whole control/signature file thing is pure crap, give it up!

        Comment


        • #19
          Originally posted by bug77 View Post
          Strange, I was expecting you tested before complaining...
          Sorry if I was complaining. its just that my card has been in a box for a week and I've been using this loud Nvidia card which is driving me crazy.

          Also I did try with the previous catalyst 12.2 and the open source and they didn't work, no support.

          Comment


          • #20
            Originally posted by Kano View Post
            @bridgman

            The supported pci-ids did not change at all from 12-2 to 12-3 when you look at the fglrx kernel module. from 12-1 to 12-2 only 2 ids where added (679e and 990a). So the only change could be in the control file to get rid of unsupported hardware. And the devs needed so long to do that, really really bad joke. That whole control/signature file thing is pure crap, give it up!
            The PCI IDs in the code determine which hardware the driver will *try* to run on. The code might work perfectly, or be buggy, or fail to run at all.

            The PCI IDs in the control file show which hardware the driver has passed QA on.

            Once testing and bug fixing on specific hardware is completed, the IDs in the control file are updated to reflect that these binaries form a production driver for the hardware it's running on, whereas previously it displayed a "hey this might run but be aware it's not a production driver" message.

            The time and effort is not to add IDs to the control file (that's all automated anyways) but to do the testing, bug fixing and re-testing required to pass QA on the hardware and make it appropriate to mark the resulting binaries as production-ready in the control file.

            Comment


            • #21
              Originally posted by bridgman View Post
              The PCI IDs in the code determine which hardware the driver will *try* to run on. The code might work perfectly, or be buggy, or fail to run at all.

              The PCI IDs in the control file show which hardware the driver has passed QA on.

              Once testing and bug fixing on specific hardware is completed, the IDs in the control file are updated to reflect that these binaries form a production driver for the hardware it's running on, whereas previously it displayed a "hey this might run but be aware it's not a production driver" message.

              The time and effort is not to add IDs to the control file (that's all automated anyways) but to do the testing, bug fixing and re-testing required to pass QA on the hardware and make it appropriate to mark the resulting binaries as production-ready in the control file.
              When are they planning to do QA to make sure power management doesn't crash the X server and that creating an OpenGL context doesn't panic the kernel sometimes?

              Both of those are issues on Ubuntu with Catalyst. Can you have one of your devs let his monitor go to sleep a few times and make sure it comes back up? BTW, if you need to know what monitors do it, I have a Westinghouse monitor from 2008 and a Samsung monitor from 2011 that both have the same exact issue.

              Edit, it happens with two cards as well, a 4670 and a 5670.
              Last edited by DaemonFC; 03-29-2012, 03:32 AM.

              Comment


              • #22
                On my aspire with hd4200 I run a java application for charting, the speed difference between this driver and the radeon is so big I don't understand it, fglrx simply is unusable.
                it's probably what you call 2d

                Comment


                • #23
                  gnome-shell random freezes

                  Still random freezes in gnome-shell, back to free radeon driver. One would have thought that by now AMD would have sorted that problem. Apparently not so. Shame....

                  Comment


                  • #24
                    At least we can use xf86-video-intel-2.18 now (those of us on laptops with dual muxless intel + amd GPU). With 12.2 we were stuck on 2.15.

                    Comment


                    • #25
                      found a solution to intel iGP no direct rendering

                      I've found a solution for getting the gnome-shell working when switch to iGP card through aticonfig or CCC. Now I have gnome-shell runing in iGP without tearing and XBMC runing over iGP with an acceptable performance!

                      It's a weird thing done by AMD fglrx driver during installation, but to make sure it'll work, let's verify if you have the same diagnostic:
                      First thing is about glxinfo, if it show no direct rendering, just execute this command:
                      Code:
                       LIBGL_DEBUG=verbose; glxinfo
                      the first output lines, if appears a lot of 'libGL errors' like below:

                      libGL error: dlopen /usr/lib32/fglrx/dri/swrast_dri.so failed
                      libGL error: dlopen /usr/lib32/fglrx/dri/i915_dri.so failed

                      if you saw, there's an i915 dri driver that couldn't be loaded for some reason. As you can see, the directory is /usr/lib32/fglrx/dri/ but, if you ls this directory you will not see more than one driver named
                      fglrx_dri.so

                      So, I've figured out that when fglrx driver installs it changes the LIBGL_DRIVERS_PATH to its own particular path, such that is: /usr/lib/fglrx/dri:/usr/lib32/fglrx/dri

                      if you write the command below you'll see the output like above:

                      Code:
                       echo $LIBGL_DRIVERS_PATH
                      the output will be something like that: /usr/lib/fglrx/dri:/usr/lib32/fglrx/dri

                      if you have the same output as above you just have to add the directory where is the intel dri drivers, lets do that!
                      as you can see in this file : /etc/X11/Xsession.d/10fglrx

                      Code:
                      $ gksu gedit /etc/X11/Xsession.d/10fglrx
                      Code:
                       LIBGL_DRIVERS_PATH=/usr/lib/fglrx/dri 
                      if [ `uname -m` = 'x86_64' ]; then 
                        if [ -d /usr/lib32/fglrx/dri ]; then 
                          LIBGL_DRIVERS_PATH=${LIBGL_DRIVERS_PATH}:/usr/lib32/fglrx/dri
                          if [ ! -z $LD_LIBRARY_PATH ]; then 
                      	LD_LIBRARY_PATH=$LD_LIBRARY_PATH: 
                          fi 
                          LD_LIBRARY_PATH=${LD_LIBRARY_PATH}/usr/lib32 
                          export LD_LIBRARY_PATH 
                        fi 
                      fi 
                      export LIBGL_DRIVERS_PATH
                      in the fourth line you have the LIBGL_DRIVERS_PATH defined as: /usr/lib/fglrx/dri:/usr/lib32/fglrx/dri
                      if you have the same as above, just add the following path in that fourth line:

                      for x86_64 (64 bits): /usr/lib/x86_64-linux-gnu/dri/

                      for x86 (32 bits) linux: /usr/lib32/dri/

                      just add is with a “:” (without quotes) in the end of 4th line to get the direct render working!
                      The file will be like this:
                      File /etc/X11/Xsession.d/10fglrx for 64 bits (x86_64) linux:
                      Code:
                      LIBGL_DRIVERS_PATH=/usr/lib/fglrx/dri 
                      if [ `uname -m` = 'x86_64' ]; then 
                        if [ -d /usr/lib32/fglrx/dri ]; then 
                          LIBGL_DRIVERS_PATH=${LIBGL_DRIVERS_PATH}:/usr/lib32/fglrx/dri:/usr/lib/x86_64-linux-gnu/dri 
                          if [ ! -z $LD_LIBRARY_PATH ]; then 
                      	LD_LIBRARY_PATH=$LD_LIBRARY_PATH: 
                          fi 
                          LD_LIBRARY_PATH=${LD_LIBRARY_PATH}/usr/lib32 
                          export LD_LIBRARY_PATH 
                        fi 
                      fi 
                      export LIBGL_DRIVERS_PATH
                      File /etc/X11/Xsession.d/10fglrx for 32 bits (x86) linux:
                      Code:
                      LIBGL_DRIVERS_PATH=/usr/lib/fglrx/dri 
                      if [ `uname -m` = 'x86_64' ]; then 
                        if [ -d /usr/lib32/fglrx/dri ]; then 
                          LIBGL_DRIVERS_PATH=${LIBGL_DRIVERS_PATH}:/usr/lib32/fglrx/dri://usr/lib32/dri
                          if [ ! -z $LD_LIBRARY_PATH ]; then 
                      	LD_LIBRARY_PATH=$LD_LIBRARY_PATH: 
                          fi 
                          LD_LIBRARY_PATH=${LD_LIBRARY_PATH}/usr/lib32 
                          export LD_LIBRARY_PATH 
                        fi 
                      fi 
                      export LIBGL_DRIVERS_PATH
                      then save the /etc/X11/Xsession.d/10fglrx (must have root privileges) and reboot your system

                      then
                      Code:
                       $ glxinfo | egrep render
                      and check it out if you'll have direct rendering!
                      Voilà! Shaazaam! Works

                      I've got gnome-shell loading and working sweeeeeeeeeetly!! XBMC also are working sweeeeetly and without video tearing! Good bye cruel World!!!!

                      Can someone tell me if Unity 3D works?

                      Comment

                      Working...
                      X