Announcement

Collapse
No announcement yet.

Three Priorities For Open-Source Radeon Graphics

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

  • #16
    I agree with what has been said, power management is the #1 reason I am stuck with Catalyst.

    Comment


    • #17
      I wish they'd make power management a bigger priority.
      I wish they'd just put all the power management directly into the card firmware, and then expose just two function calls: Query the available power states, set the current power state. Point. Or have a function call which sets the power envelope the card is not allowed to exceed at the moment. I will never understand why they leave all the power management to the driver, in the end there are just three choices: "Powersave", "Performance" and "Do whatever you want". And the card itself can handle the "Do whatever you want" case just as well as the driver, if not better.

      Comment


      • #18
        Since I'm probably going to skip the Southern Islands ASIC generation entirely (I have a HD5970), and since I couldn't give two shits about video acceleration or OpenCL, my three priorities would be: 3D performance, 3D stability, and more 3D API support. Glad we're on the same page, AMD.

        HDMI Audio, I might have a use for, though, so at least ONE thing mentioned on the list might slightly help me if successful.

        Comment


        • #19
          Originally posted by allquixotic View Post
          Since I'm probably going to skip the Southern Islands ASIC generation entirely (I have a HD5970), and since I couldn't give two shits about video acceleration or OpenCL, my three priorities would be: 3D performance, 3D stability, and more 3D API support. Glad we're on the same page, AMD.

          HDMI Audio, I might have a use for, though, so at least ONE thing mentioned on the list might slightly help me if successful.
          be happy openCL means raytracing 3D performance

          Comment


          • #20
            uvd

            Another guy here looking forward to full open source UVD support.

            Comment


            • #21
              Originally posted by wumpyr View Post
              Power consumption is the main driver for me. Will ZCP be in the SI ddx initially?
              Bridgman, can you comment on this? Zero core indeed would be nice.

              Comment


              • #22
                Originally posted by PsynoKhi0 View Post
                +2

                P.S.: I've just read about LG having signed a deal with MS for the "privilege" of using Android, so I'm in a bad mood.

                Just remember that is due to the same reason why AMD can't release information on their UVD hardware interfaces:

                The United States Federal Government.

                If it wasn't for DMCA and deformed IP laws then AMD wouldn't have a serious problem clearing UVD documentation with their legal department and there would be no reason for LG to pay Microsoft for it's bullshit patents.


                ...........


                As far as Linux acceleration for graphics goes the best we can probably expect in the foreseeable future is to utilize shader stuff on the GPU more efficiently.

                Comment


                • #23
                  Originally posted by Soul_keeper View Post
                  Another guy here looking forward to full open source UVD support.
                  FULL? LOL in your DREAMS! they work on Limited smal UVD support ...

                  Comment


                  • #24
                    You should at least build one thing that would make using opensource valueable. Not magnitude of things that all look mediocre.

                    -) 3d speed
                    -) video accel via 3d
                    -) video accel via uvd (evil! evil! evil! as in Ultra eVil Decoder harrr)
                    -) powermanagement
                    -) support for newer GCN
                    -) faster support for newer generations beyond 7970
                    -) legal clearness of opengl3.0 and up; establishing legal department so coders code and not play lawers.

                    Of all seven, I would pick faster support for newer generations and full opengl support instead.

                    Reasoning:
                    -) 3d speed
                    you will not reach it. especially not since most of fast algorithms should be and go opensource. Because amd is not google, it is highly unrealistic they give you 1000 directx engineers to optimize opengl.

                    -) video accel via 3d
                    will work less efficient than via UVD (evil! evil!) and those who need it use nvidia cards already.

                    -) video accel via uvd
                    closed driver already does it for some part and you should not do it. install closed driver or nvidia if you need that, really not a real priority.

                    -) powermanagement
                    people using opensource driver, use 40W cards. Using 40W+ card? Than you probably looking for performance, since otherwise your heatgun will just bake at less temperature, but not much more pro´s. Ie, 40W+ card will make no sense with good powermanagement, if its the only advantage, except you use it to heat your apartment.

                    -) support for newer CGN
                    it is not here, so trying to push for it fast is useless. Linux opensource users did not buy your cards, amd.

                    -) faster support for newer generations beyond 7970
                    best bet

                    -) legal clearness of opengl3.0 and up; establishing legal department so coders code and not play lawers.
                    another best bet, since it will accelerate speed for holes in opengl3< to disappear and rate at which complete opengl4 support comes in

                    and only then, you can prioritize on video decode via opencl; and only after that the 3d speed will come in.

                    But actually my own personal best priority for amd opensource would be only one:
                    Stop introducing features for old cards, so long you are not done with newer generation.
                    Like Intel does it.

                    Or amd opensource will stay special olympics driver.
                    Last edited by crazycheese; 01-13-2012, 11:02 AM.

                    Comment


                    • #25
                      Originally posted by crazycheese View Post
                      -) powermanagement
                      people using opensource driver, use 40W cards. Using 40W+ card? Than you probably looking for performance, since otherwise your heatgun will just bake at less temperature, but not much more pro´s. Ie, 40W+ card will make no sense with good powermanagement, if its the only advantage, except you use it to heat your apartment.
                      You are ignoring mobile devices here, where relatively low savings can make a huge difference in the time your batteries last (see e.g. all the ASPM hubbub).

                      Comment


                      • #26
                        Originally posted by crazycheese View Post
                        -) support for newer CGN
                        it is not here, so trying to push for it fast is useless.

                        -) faster support for newer generations beyond 7970
                        best bet
                        These two are the same in terms of what we actually work on, aren't they ? The primary thing delaying work on the *next* generation is finishing work on the *previous* generations, since each generation builds on the support for the one before. Skipping a generation isn't really practical, although in some cases you can work on two generations in parallel. We are already starting to look at the generation after SI a bit, although we're not writing code for it yet.

                        We have definitely been pushing to shorten the delay between hardware launch and open source graphics driver support, going from "a few years" at the start to "a few months" and hopefully even less for SI. The SI situation is a bit complicated in the sense that we started work on it well before hardware launch but the magnitude of the changes between SI and previous generations means that the earlier start date isn't really visible because the development time is longer as well.

                        Originally posted by crazycheese View Post
                        Linux opensource users did not buy your cards, amd.
                        The first GCN card (HD 7970) has only been in stores for a few days, and it's the high end card which I wouldn't expect to see paired with the current open source drivers anyways. We should revisit this after the rest of the product line comes out.

                        Originally posted by crazycheese View Post
                        But actually my own personal best priority for amd opensource would be only one:
                        Stop introducing features for old cards, so long you are not done with newer generation.
                        Like Intel does it.
                        This one is tough because we are actively selling chips with multiple generations of hardware, eg the APUs have GPUs based on Evergreen. New features like the OpenCL work need to go back to at least Evergreen in order to be really useful. In general, though, we are focusing most of our time on new HW support and the developer community outside AMD is doing relatively more of the work to add features & performance for already supported GPUs.
                        Last edited by bridgman; 01-13-2012, 11:28 AM.

                        Comment


                        • #27


                          bridgman: "It's too hard to type and facepalm at the same time "

                          http://phoronix.com/forums/showthrea...Series-Trinity

                          I'm a funny Oracle!

                          "This means full speed on GCN for [...],OpenCL and Video-acceleration."

                          "however all modern future graphic architectures are ray-tracing based over openCL this means mesa doesn't matter. "

                          "and I'm sure they will increase the dev team to focus on openCL for the Opteron customers. . "


                          "Some whispers to me: AMD will announce in February that they favor the open source driver for the next gen graphic architecture on the Linux market and the android market. "

                          yes the announce in February will be a mobile device with "Wayland-driven" opensource driver...

                          Comment


                          • #28
                            another +1 for power management.
                            profile low is giving me levels that are rather close to fglrx but dynpm is still somewhat problematic (but then it involves memory reclocking and that makes things more complicated). Still, dynpm is what fglrx does and what is most useful normally.

                            This Zero Core or whatever it was called on the new HD 7xxx series is what I am looking for. Sounds awesome and finally coming true what I want for ... 8 or 10 years now?

                            +1 also for UVD. I mean, I can play videos, yeah, but having an ASIC that could do things better and more efficient sitting useless around... hmm. Stupid legal minefield.

                            OpenCL ... oh, well. If it happens I won't protest. I mean, especially if it gives me the opportunity to use the same RAM/or mixed shared RAM (VRAM/system RAM) for CPU and GPU (or APU). And then have Gentoo compiling libreoffice on both computing units. Heh. Ah, weren't there people in the good days of old who were using the floppy controllers of their Amiga boxes as a computing aid for the main CPU?

                            HDMI: Don't have it and the first thing I associate with HDMI is HDCP (even though it is possible to use on other interfaces), and I am allergic to techniques like these. Well, if it helps anybody to get some tones out of his box...

                            Furthermore there are a lot of rendering glitches. (all cards/chips I used til now, but that might be also KDE's fault)

                            Comment


                            • #29
                              @bridgman on HDMI audio, do those patches have multichannel PCM support? If not, any plans for it in the future?

                              Fglrx doesn't have it, but Windows with AMD graphics has it, Nvidia's proprietary linux drivers have it, and it would be excellent if the OSS drivers (or even just fglrx) could get it for the benefit of us HTPC users wanting to pass-through DTS-HD & play multi-channel music.

                              Comment


                              • #30
                                I wish they put the driver into the firmware and have a minimal opensource driver for the OS wich interacts with the driver firmware... Or at least the power management.

                                Comment

                                Working...
                                X