Announcement

Collapse
No announcement yet.

The State Of Open-Source Radeon Driver Features

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

  • #46
    Originally posted by log0 View Post
    And this customers/partners don't care about power management, performance and overall feature completeness? Who are this customers btw(I assume this info is not secret)? What are they doing with this open source driver?
    Other than power management, which was a whole lot simpler when we kicked this off back in 2007, I imagine they're pretty pleased with the features and performance. Launch-time support (buy new HW, install a recent distro, use the system) was a higher priority than features and performance.

    The common thread among the customers was that (a) they were building big compute farms with our CPUs, (b) they were running Linux on those farms, (c) they did most of their related SW development on Linux, and (d) they wanted in-box support for the systems used for SW development and related activities.
    Last edited by bridgman; 09-04-2012, 09:21 AM.

    Comment


    • #47
      Originally posted by bridgman View Post
      Other than power management, which was a whole lot simpler when we kicked this off back in 2007, I imagine they're pretty pleased with the features and performance. Launch-time support (buy new HW, install a recent distro, use the system) was a higher priority than features and performance.

      The common thread among the customers was that (a) they were building big compute farms with our CPUs, (b) they were running Linux on those farms, (c) they did most of their related SW development on Linux, and (d) they wanted in-box support for the systems used for SW development and related activities.
      I see. They are not really using your GPUs for computation related tasks, just happened to have them in their systems. But PM should still matter though.

      Comment


      • #48
        Originally posted by log0 View Post
        I see. They are not really using your GPUs for computation related tasks, just happened to have them in their systems. But PM should still matter though.
        They ARE being used for computational task. Cuda & OpenCL are becoming very populair in the scientific community. And we want big clusters with lots of flops. Cooling is an expensive issue with big clusters, so good PM is very welcome.

        On the other hand, most cluster I know, all use Cuda (nvidia) for computations. The bad reputation of Catalyst isn't helping to change that.

        Comment


        • #49
          Originally posted by wpoely86 View Post
          They ARE being used for computational task. Cuda & OpenCL are becoming very populair in the scientific community. And we want big clusters with lots of flops. Cooling is an expensive issue with big clusters, so good PM is very welcome.

          On the other hand, most cluster I know, all use Cuda (nvidia) for computations. The bad reputation of Catalyst isn't helping to change that.
          But not by the customers who wanted the open source driver. This is what I was wondering about.

          And yes from my own experience nvidia is the preferred hardware for (serious) computing.

          Comment


          • #50
            Originally posted by wpoely86 View Post
            They ARE being used for computational task. Cuda & OpenCL are becoming very populair in the scientific community. And we want big clusters with lots of flops. Cooling is an expensive issue with big clusters, so good PM is very welcome.

            On the other hand, most cluster I know, all use Cuda (nvidia) for computations. The bad reputation of Catalyst isn't helping to change that.
            well in hybrid clusters you are right many use nvidia/tesla but still pure CPU cluster are very common and will be for many generations cuz there are workloads than are too expensive or hard to paralelize enough to show any gain on a GPU and in this cases AMD still keep some muscle due to performance/$$$ ratio[bulldozer opteron with optimized codepath[AVX/FMA/XOR/MT/etc] are beasts]

            Comment


            • #51
              Remember this was back in 2007... GPU compute is much bigger now.

              Comment


              • #52
                Originally posted by bridgman View Post
                Other than power management, which was a whole lot simpler when we kicked this off back in 2007, I imagine they're pretty pleased with the features and performance. Launch-time support (buy new HW, install a recent distro, use the system) was a higher priority than features and performance.

                The common thread among the customers was that (a) they were building big compute farms with our CPUs, (b) they were running Linux on those farms, (c) they did most of their related SW development on Linux, and (d) they wanted in-box support for the systems used for SW development and related activities.
                i would like to add than in 2007 linux graphic stack [kernel/memory/FB/GL/etc] were no better than BSD or solaris and mesa supported GLX1.4[or less not sure], so to implement a proper driver first you need a proper graphic stack[Exa/glamor, ttm,kms,mesa,gallium,GL 2.x minimal,etc], so is not like AMD/commnuity r600g did nothing in 5 years but more like it took at least 3 out of those 5 years get the graphic stack in an usable state to begin developing drivers[graphic stack is still WIP tho but mature enough for do most of the work]

                so once the stack is properly upto date drivers will advance faster cuz now devs can focus totally on them and probably beyond massive gpu architecture changes in a near term future drivers will be available very close to release date at least on git and more likely gallium documentation will improve lowering a lot the entry barrier needed to write those drivers

                Comment


                • #53
                  Originally posted by jrch2k8 View Post
                  ...so once the stack is properly upto date drivers will advance faster ...
                  I don't see them advance if I understand @bridgman's comments correctly. It might serve the competitors, can not be in AMD's interest. What Marek & Co are doing is out of their control of course. It is an interesting issue.

                  Comment


                  • #54
                    Nope, that's not what I said -- I was talking about open sourcing the Catalyst code. There is a lot of room for improvement in the open source graphics drivers.

                    Comment


                    • #55
                      Originally posted by log0 View Post
                      I don't see them advance if I understand @bridgman's comments correctly. It might serve the competitors, can not be in AMD's interest. What Marek & Co are doing is out of their control of course. It is an interesting issue.
                      he was referring to fglrx cuz that white mammut has zillion and bazillions of dirty dirty hacks to improve certain games[mostly making hacks in the driver cuz the game is crappy coded but wth] that is what he meant as "competitive advantage" cuz the code is shared between fglrx and catalyst.

                      the OSS driver should not pose any threat cuz AMD assembly is useless for anyone else and Opengl is an standard[so no competitive advantage] and any "competitive advantage" that could exist for GL/DX is blackboxed inside the gpu silicon[same nvidia and intel] so no worries [the only part that seem out of reach is UVD which i suspect is MAFFIA forcing it to be used only by " the approved OS[try to guess ]" or bye bye license ]

                      Comment


                      • #56
                        Originally posted by bridgman View Post
                        Nope, that's not what I said -- I was talking about open sourcing the Catalyst code. There is a lot of room for improvement in the open source graphics drivers.
                        But in the terms of the end result the issue is the same, isn't it? The specific process, whether open sourcing code or bringing the mesa driver up to speed close to the Catalyst, doesn't matter.

                        Comment


                        • #57
                          @bridgeman is there some magic encantation to turn on GL 3.0 support still? I can get 2.1 and GLSL 1.30 but it doesn't report GL 3.0 this is on a radeon 4200 RS880. Catalyst 12.4 reports GL 3.3.

                          That said Mesa git actually works far better than Catalyst even though its s tad slower... for instance in wine with Mesa3d I can run Guild Wars without turning any features off.. while Catalyst requires that I disable dx9 AND shaders so it looks terrible ;P... however on mesa it looks swell at comparable frame rates. (pretty sure its 2x-3x faster on windows though)

                          Comment


                          • #58
                            Originally posted by cb88 View Post
                            @bridgeman is there some magic encantation to turn on GL 3.0 support still? I can get 2.1 and GLSL 1.30 but it doesn't report GL 3.0 this is on a radeon 4200 RS880. Catalyst 12.4 reports GL 3.3.

                            That said Mesa git actually works far better than Catalyst even though its s tad slower... for instance in wine with Mesa3d I can run Guild Wars without turning any features off.. while Catalyst requires that I disable dx9 AND shaders so it looks terrible ;P... however on mesa it looks swell at comparable frame rates. (pretty sure its 2x-3x faster on windows though)
                            you need

                            Kernel 3.6-rc4
                            libdrm git
                            mesa git
                            xf86-video-ati git
                            xorg-xserver and dependencies git[1.13 rcX]
                            will break to hell fglrx though

                            Comment


                            • #59
                              The thing is, that the most important future for a GPU, is to work well on Linux and under WINE. Then comes the LIBRE thing, and then price and others. I tested "TERA-online (Unreal-3)". With NVIDIA GTX275 or GTX460 and closed drivers, works fine. With Radeon HD4670 or HD6970 and CATALYST, doesn't show any graphics and shows multiple D3D errors, doesn't work at all. Intel is not in a much better situation. I have a 15.6" laptop with 32nm Sandy-bridge dual-core PentiumSSE4.2 (8 drystone vs 9.5 the AVX part, vs 4.5 for Core2 or AMD part). With a GT620m@630m 28nm GPU, that has 96shaders*1.6ghz, and gives 300gflops@64bit or 600gflops@32bit(AMD HD7000 comparison) or 900mac-gflops(vs simple MADD GPUs, AMD HD6000 and lower). I paid 350eu(from 400eu) for it NEW, and spared 50eu because I choose to return the Windows7 license (I have this wright in EU). The machine eats everything alive, with Ubuntu 12.04 64bit and WinePPA. With Sabayon and programs entirely compiled for sse4.2 (not i686 and only a 10% stream for SSE4.2) there is not an opponent.

                              Comment


                              • #60
                                Originally posted by artivision View Post
                                The thing is, that the most important future for a GPU, is to work well on Linux and under WINE. Then comes the LIBRE thing, and then price and others. I tested "TERA-online (Unreal-3)". With NVIDIA GTX275 or GTX460 and closed drivers, works fine. With Radeon HD4670 or HD6970 and CATALYST, doesn't show any graphics and shows multiple D3D errors, doesn't work at all. Intel is not in a much better situation. I have a 15.6" laptop with 32nm Sandy-bridge dual-core PentiumSSE4.2 (8 drystone vs 9.5 the AVX part, vs 4.5 for Core2 or AMD part). With a GT620m@630m 28nm GPU, that has 96shaders*1.6ghz, and gives 300gflops@64bit or 600gflops@32bit(AMD HD7000 comparison) or 900mac-gflops(vs simple MADD GPUs, AMD HD6000 and lower). I paid 350eu(from 400eu) for it NEW, and spared 50eu because I choose to return the Windows7 license (I have this wright in EU). The machine eats everything alive, with Ubuntu 12.04 64bit and WinePPA. With Sabayon and programs entirely compiled for sse4.2 (not i686 and only a 10% stream for SSE4.2) there is not an opponent.

                                Fewer parentesis (please).

                                Comment

                                Working...
                                X