Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

  • Originally posted by glisse View Post
    read well above 100k$
    It means 1000 peoples willing to donate 100$. I'm pretty sure it's a reasonable target _IF_ some org opens a dedicated donation fund.
    Anyway, even if we reach the 100k$/year target, it means no more than 10 developers. It's a big difference, but I don't think it will be enough to close the gap with the catalyst.

    In a perfect world Amd will drop catalyst to concentrate on the open drivers, but thanks to patents it will remain a dream
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • It's not 100 full-time people working on the LINUX part of Catalyst, it's 100 (or more) full-time people working on Catalyst in general, most of which is shared between Windows, Linux, BSD and OSX.

      The Linux support for Catalyst drivers is obviously not the main focus of the AMD driver developers, the vast majority goes into improving Windows performance, and Linux gets these improvements for free.

      It's not very likely that AMD would give up WINDOWS drivers (Catalyst) just so they can put all the people to work on Linux drivers. It's not going to happen.

      Comment


      • Originally posted by glisse View Post
        If we can gather several millions of dollars i proposing myself as CEO ;-)

        the only thing we can gather now is cheezburgers and internets

        Comment


        • Originally posted by bridgman View Post
          For several millions of dollars I'm sure glisse would finish the driver stack himself
          the time part is missing... glisse will finish the driver instandly.

          money makes the world go around.

          http://www.dailymotion.com/video/x1y...go-round_music

          Comment


          • Originally posted by pingufunkybeat View Post
            It's not 100 full-time people working on the LINUX part of Catalyst, it's 100 (or more) full-time people working on Catalyst in general, most of which is shared between Windows, Linux, BSD and OSX.

            The Linux support for Catalyst drivers is obviously not the main focus of the AMD driver developers, the vast majority goes into improving Windows performance, and Linux gets these improvements for free.

            It's not very likely that AMD would give up WINDOWS drivers (Catalyst) just so they can put all the people to work on Linux drivers. It's not going to happen.
            How many of these 100 drones are working on the Linux part? If just 5 of them are doing so and these drones were moved into free driver development then that would obviously help the free drivers somewhat.

            I would prefer this since I don't use the non-free Catalyst, but I do see why the AMD shareholders could prefer that these drones continiue to work on the evil binary blob driver.

            Comment


            • Well, I'd prefer that too, but AMD is after the professional workstation market, and as long as Mesa, drm, Gallium, and the related infrastructure can't provide OpenGL4 and similar stuff, I don't expect AMD to drop Catalyst for Linux.

              Comment


              • I know the obvious response at this point will be "but if you moved the Catalyst for Linux developers to the open source driver then you could have GL4 etc...", but that's not how it works. We develop the Catalyst driver code and share it across 100% of the PC market (ie all OSes), but if we moved the devs who make that common code available on Linux to working on the open source driver then they would not be able to leverage the work done for all of the other OSes, ie they would be working on a Linux-specific code base, and the same number of developers would *not* be able to deliver the same level of features and performance.

                Put simply, open source drivers share code across HW vendors (ie the intel, radeon and nouveau driver stacks share a lot of common code, which is why they have similar features) while proprietary drivers share code across OSes.

                Comment


                • As if fglrx delivers the same features as catalyst...


                  Sorry, I am not a troll, but this one was shouting for such a reply.

                  Anyway, I suspect that having good h264 decoding possibilities and an efficient dynpm would significantly reduce the whining and the "what if" comments. Opengl and cl would still remain but we could have a good everyday driver. Are these on your short-term list? Maybe even helping out Christian Konig. Well, one can dream, I guess.

                  Comment


                  • ???

                    In cases where the feature implementation is relatively OS-independent (ie where code *can* be shared across OSes) I believe the Linux and Windows versions of Catalyst *do* have the same features (eg OpenGL, OpenCL).

                    In cases where the implementation is OS-dependent or DRM is a factor (video decode acceleration, Eyefinity on older X version, even suspend/resume), ie where the code has to be pretty much re-implemented from scratch for Linux, the features on Linux can lag. Those features tend not to be a high priority for the workstation market though, so the model works OK.

                    For in-between things (where some of the code has to be re-implemented but not all, eg power management) there has been a lag but not so much these days.

                    Comment


                    • Originally posted by HokTar View Post
                      Anyway, I suspect that having good h264 decoding possibilities and an efficient dynpm would significantly reduce the whining and the "what if" comments. Opengl and cl would still remain but we could have a good everyday driver. Are these on your short-term list? Maybe even helping out Christian Konig. Well, one can dream, I guess.
                      Top priority for the AMD devs is enabling support for new GPU generations (via code and/or docs) and supporting community devs, which are the things that pretty much have to be done in house. When time permits, the devs also work on improving existing support (Alex wrote the initial EXA and Textured Video code, along with initial power management and a bunch of other things, Richard added GLSL and flow control support) but only when time permits.

                      Other than not being enabled by default, are you seeing problems with dynpm ? My recollection was that the "glitching" issue was largely fixed a month or two ago, and the remaining TODO task (splitting the code so that memory and engine clocks are changed in different blanking periods) could be done by anyone.

                      Comment


                      • Originally posted by bridgman View Post
                        Top priority for the AMD devs is enabling support for new GPU generations (via code and/or docs) and supporting community devs, which are the things that pretty much have to be done in house. When time permits, the devs also work on improving existing support (Alex wrote the initial EXA and Textured Video code, along with initial power management and a bunch of other things, Richard added GLSL and flow control support) but only when time permits.

                        Other than not being enabled by default, are you seeing problems with dynpm ? My recollection was that the "glitching" issue was largely fixed a month or two ago, and the remaining TODO task (splitting the code so that memory and engine clocks are changed in different blanking periods) could be done by anyone.
                        Whenever I tried it did not lowered the clock/voltage. Manually setting it to low works fine.

                        I think I have a fairly good understanding of the current methodology, i.e. you enable drivers than the community enhances it. I dared to ask that question because it seems that only the NI chips are left and the desktop APU is still far away. So my thinking was that in the next few months you might have some free time to help out here and there. Maybe I am completely wrong.

                        Comment


                        • Nope, you're right... although if we're going to stay "caught up" there's not going to be a *lot* of free time between generations.

                          Comment


                          • Can you elaborate on this glitching issue, please?

                            Originally posted by bridgman View Post
                            Other than not being enabled by default, are you seeing problems with dynpm ? My recollection was that the "glitching" issue was largely fixed a month or two ago...
                            Can you remember what was done to fix this "glitching" issue, please? E.g. was it in the kernel, the driver, or Mesa? Because I was noticing some glitchy behaviour with the 2.6.36.1 kernel and xorg-drv-ati from git recently (HD4890).

                            Comment


                            • Originally posted by bridgman View Post
                              Nope, you're right... although if we're going to stay "caught up" there's not going to be a *lot* of free time between generations.
                              Sometimes you show your admirable skill in not answering a question. Not to mention that I never said "a lot".

                              Plus I had the wild guess that the desktop apu will be based on evergreen or ni thus enabling it might not take much more than for ontario, i.e. a few hundred lines.
                              If this assumption turns out to be correct then there would be two devs with little to no work for months. So yes, maybe that would be a *lot* of free time.

                              Anyway, if Alex or Richard will have some free time then my question will get answered, I guess.

                              Comment


                              • Originally posted by chrisr View Post
                                Can you remember what was done to fix this "glitching" issue, please? E.g. was it in the kernel, the driver, or Mesa? Because I was noticing some glitchy behaviour with the 2.6.36.1 kernel and xorg-drv-ati from git recently (HD4890).
                                Pretty sure it was in the kernel. My guess is that you would need 2.6.37 to get it.

                                HokTar, not lowering clock/voltage is what the TODO task (splitting clock adjust for engine & memory into different vblank intervals) is intended to address. If there isn't enough time in a single vblank interval to set and stabilize both clocks the current code doesn't change either of them... and you can't lower the voltage unless the clocks have already been lowered and stabilized.

                                Originally posted by HokTar View Post
                                Sometimes you show your admirable skill in not answering a question. Not to mention that I never said "a lot".
                                No, but you implied "a lot" by suggesting that the devs work on things like assisting Christian's video decode work. The remaining work there is not "quick fixes", there's a fairly significant learning curve on the video algorithm side.

                                Originally posted by HokTar View Post
                                Plus I had the wild guess that the desktop apu will be based on evergreen or ni thus enabling it might not take much more than for ontario, i.e. a few hundred lines. If this assumption turns out to be correct then there would be two devs with little to no work for months. So yes, maybe that would be a *lot* of free time
                                A lot of the work Alex did for Ontario should carry across to Llano as well, but that's not where I see the time going. There are some differences between the NI SKUs which will require additional work on top of what has been done already, and we want to try and tie work on the next generation core into the proprietary development effort, which means we need to start *now* rather than a year from now.

                                I think there will be free time but I don't expect it to come quickly. When the free time *does* come the issues you mentioned may not be top-of-mind any more.

                                Doing more on the power management side will be a priority, whether we do it or the community devs do it. Dynpm may not be top priority either, those are the things we are trying to figure out now.

                                Originally posted by HokTar View Post
                                Anyway, if Alex or Richard will have some free time then my question will get answered, I guess.
                                It's a pretty safe bet that they will have some free time, but because it may not happen for a while I just can't give any kind of confident answer that they will be working on the specific things you mentioned.

                                Comment

                                Working...
                                X