Announcement

Collapse
No announcement yet.

Where The Open-Source AMD Driver Is At For Modern GPUs

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

  • #16
    Originally posted by Jimbo View Post
    it seems some type of "architectural" problem.
    Yes it is. As Jérôme Glisse said, there is several points :
    - the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
    - there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
    - r600g have a design that is not the best to do what it do.

    To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.

    Comment


    • #17
      Originally posted by pingufunkybeat View Post
      Well, if the performance difference is 20% (if there is one at all), like is the case with r300g, then it is indeed a good comparison.
      Only if the binary that is produced is time critical. Let's face it an end user is rarely going to care if it takes 54 seconds to encode a mp3 vs 60 seconds and the output would be the same but when you are dealing with real time input / output that is an entirely different matter.

      Comment


      • #18
        If 20% more performance costs $10, then it is as good as unimportant. Especially when dealing with 10-year-old games, which run faster than the refresh rate anyway, which is essentially the Linux situation.

        Comment


        • #19
          Originally posted by whitecat View Post
          Yes it is. As Jérôme Glisse said, there is several points :
          - the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
          - there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
          - r600g have a design that is not the best to do what it do.

          To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.
          Kernel side is one part of the issue if you want to compete with catalyst. Right now the biggest issue is in r600g itself. Thought given the number of r600g needs i fear that kernel side might also impact it a little bit more than r300g.

          Comment


          • #20
            mmmm Michael maybe is cuz my card is a 4850 but nexuiz in the most extreme preset is always around 50 fps at 1440x900 using mesa-git, natty, drm git, ddx git, 2.6.38 drm next (2.6.39 broke btrfs so i can't boot it), color tiling, swapwait off, st3c support, etc.

            well im using custom cflags but still those results are creepy slow, maybe pts is missing something?

            i know you do out of the box benchs but it won't hurt to create some sort of tweaked profile wich is more likely to be closer to the real state of the driver, remember r600 is under heavy development

            Comment


            • #21
              Originally posted by pingufunkybeat View Post
              If 20% more performance costs $10, then it is as good as unimportant.
              That is only if you do not have a card in the first place, so replacing a card carries considerably higher price.

              Comment


              • #22
                Originally posted by glisse View Post
                Kernel side is one part of the issue if you want to compete with catalyst. Right now the biggest issue is in r600g itself. Thought given the number of r600g needs i fear that kernel side might also impact it a little bit more than r300g.
                ... number of regs r600g needs ...

                Comment


                • #23
                  damn edit time

                  btw i discovered that K/ubuntu normally set the cpu scheduling to conservative and actually unless you have a laptop or a good acpi implementation in the bios(i assume that it exists somewhere) the cpu is always set to the lower frequency available and it never goes up (same with ppa ubuntu kernels).

                  the point been that i discovered that when i set my phenom II X4 955 to preformance scheduler my fps jump very hard aka nexuiz default 20ish fps -- performance cpu/ mid gpu 40 ish

                  Comment


                  • #24
                    Originally posted by glisse View Post
                    Kernel side is one part of the issue if you want to compete with catalyst. Right now the biggest issue is in r600g itself. Thought given the number of r600g needs i fear that kernel side might also impact it a little bit more than r300g.
                    ok, thank you for correcting me.

                    Comment


                    • #25
                      Originally posted by glisse View Post
                      Kernel side is one part of the issue if you want to compete with catalyst. Right now the biggest issue is in r600g itself. Thought given the number of r600g needs i fear that kernel side might also impact it a little bit more than r300g.
                      I am very curious on this:

                      - What are the r600g needs (on performance side)?
                      - Are they being implemented?
                      - They will solve the performance problems r600g has?

                      Comment


                      • #26
                        The main reason r300 is closer to catalyst is that more people have been working on it longer compared to r600.

                        Some of the things r300 has that haven't been implemented yet on r600:
                        - texture tiling
                        - flushing only when necessary
                        - limited threading
                        - hyper Z
                        - fast clears
                        - lots of vertex upload optimizations
                        - more optimized shader compiler

                        Comment


                        • #27
                          Developers have been hacking on r3xx-r5xx 3D hardware for ~8 years compared to ~2 years for r6xx+. That makes a big difference.

                          Comment


                          • #28
                            Originally posted by pingufunkybeat View Post
                            ...free software itself is THE killer argument.
                            Tell that to millions of happy Windows and MacOS users.

                            Free software is not even an argument, it's a boon. First, the software has to work, that's the killer argument.

                            Comment


                            • #29
                              @agd5f

                              Thx for that info, I hope that all of those features could get implemented into r600g , and we could see better performance numbers someday. Anyway , good job, your work with open source graphics drivers is appreciated.

                              Comment


                              • #30
                                Originally posted by bug77 View Post
                                Tell that to millions of happy Windows and MacOS users.

                                Free software is not even an argument, it's a boon. First, the software has to work, that's the killer argument.
                                Absolutely developing for end users wants is always going to payoff in bigger marketshare. The vast majority don't care how it is done, just that it can do it.

                                Comment

                                Working...
                                X