No announcement yet.

Compiz Running With Mesa On R600/700 GPUs

  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by tball View Post
    How far is this driver from running Heroes of Newerth? Or said in another way, when does this driver support opengl 2.1? Are we gonna wait for galium3d?

    Thx for this great work!
    HoN support is a long ways off; I can't even get it working on my Intel GPU. There is a texture compression problem (for all OSS drivers), which can be worked around by faking st3c OpenGL extension. But I get a mesa crash once I start a game, however it seems to be specific to Intel since it's crashing in i965 header. And Intel currently has much better 3D support than R600 in Mesa.


    • #42
      way to go AMD / ATI

      thanks for your continued efforts put on the drivers (KMS, gallium, energy savings, 3D, etc.)


      • #43
        Originally posted by Zhick View Post
        I think I remember having read that AMD is about to release it's new Notebook-CPUs/Platform. Maybe those'll be better.
        The Tigris platform with Caspian 45nm CPU is supposed to be released next month, but from what I've read availability will be restricted to Asia at first, and may not reach US/Europe/rest of world till much later.

        It's been pretty frustrating to me too - AMD makes the best GPUs but you can't buy a notebook with an AMD CPU, GPU, and top-rank display; they simply don't exist. (Thanks a lot, Intel and your illegal business practices. You suck.) Even with the anti-trust convictions in Asia and Europe, the market hasn't changed.

        I'm still looking for an AMD-powered 15" notebook with WUXGA LED-backlit display. Seems like I'll be looking for a long time still, unless I find a compatible WUXGA screen to swap into my Puma laptop (which is currently WSXGA+).

        But back on topic - nice going guys, this is great progress on the drivers.


        • #44
          Originally posted by rvdboom View Post
          When does the appropriate code will be included in the kernel source? Or is it already?
          I currently cannot compile the agd5f branch, it fails somehow :

          I don't mind compiling mesa, libdrm or xf86-video-ati from git but I usually prefer to stick to standard kernel sources.
          There is a patch:

          You need it for kernel > 2.6.28!


          • #45
            Originally posted by agd5f View Post
            Unfortunately, most battery benchmarks only test the system at idle which generally isn't really a valid usage scenario.
            Well, I think most of the time a CPU is in idle mode. Therefore it is a quite valid benchmark! On Notebooks the performance is not the important part, but battery life is*. If you need performance, you buy a desktop PC (with a lot less problems with cooling, noise aand burned fingers) or do stuff remote on a real numbercruncher.

            But back to topic:
            Congratulations! :-)

            *Especially if people like you and bridgeman and your colleagues taking work away from the CPU with your GPUs (e.g. HD-encoding/decoding)! YOU are killing AMDs CPUs! YOU are killing good arguments for buying a AMD CPU with your uber-graphic-chips that nearly do everything beside cooking coffee and making toast (any chance that this will implemented in R900?)! SHAME ON YOU, you GPU-programmers, builder, architects! I think, this is a hostile takeover from ATi! ;-)


            • #46
              Originally posted by agd5f View Post
              you need to checkout the r6xx-r7xx-3d branch:
              git checkout -b r6xx-r7xx-3d origin/r6xx-r7xx-3d
              Now I got the stats that I was looking for

              ~/drm$ git diff b48bd 59ed4 --stat
               bsd-core/drm_mode.h          |    1 +
               bsd-core/r600_cp.c           |    1 +
               bsd-core/r600_microcode.h    |    1 +
               bsd-core/radeon/Makefile     |    4 +-
               linux-core/Makefile.kernel   |    2 +-
               linux-core/ati_pcigart.c     |    4 +-
               linux-core/drm_agpsupport.c  |    8 +
               linux-core/drm_compat.h      |    9 +-
               linux-core/drm_fops.c        |    2 +-
               linux-core/drm_memory.c      |    5 +
               linux-core/drm_os_linux.h    |    3 +-
               linux-core/drm_sysfs.c       |    6 +-
               linux-core/drm_vm.c          |    9 +
               linux-core/r600_cmdbuf.c     |    1 +
               linux-core/r600_cp.c         |    1 +
               linux-core/r600_microcode.h  |    1 +
               linux-core/radeon_cs.c       |    1 +
               linux-core/radeon_drv.c      |   10 +-
               shared-core/drm_mode.h       |    2 +
               shared-core/drm_pciids.txt   |  123 +
               shared-core/r600_cmdbuf.c    |  685 ++++
               shared-core/r600_cp.c        | 2545 ++++++++++++
               shared-core/r600_microcode.h | 9025 +++++++++++++++++++++++++++++++++++++++++-
               shared-core/radeon_cp.c      |  391 ++-
               shared-core/radeon_cs.c      |  852 ++++
               shared-core/radeon_drm.h     |   29 +-
               shared-core/radeon_drv.h     |  718 ++++-
               shared-core/radeon_irq.c     |   14 +-
               shared-core/radeon_state.c   |   86 +-
               tests/modeprint/app          |  Bin 16233 -> 0 bytes
               30 files changed, 14405 insertions(+), 134 deletions(-)
              Could I have used git to tell me what branches that exist?


              • #47
                Originally posted by agd5f View Post
                Newer chips tend build on older ones. Both r6xx and r7xx have a similar programming model, so from the driver's perspective they can share a lot of code. Kind of like r3xx, r4xx, and r5xx.
                I see... Sort of like K10 and K10.5 if we talked CPU's.


                • #48
                  Originally posted by bridgman View Post
                  I don't think the next generation is soon enough to have any differences in DRM vs graphics coupling - the development pipe is 3-4 years long and the top level design is locked down pretty early in the process. I wouldn't be expecting anything in that regard.
                  That must put a slight pressure on doing the right thing

                  Originally posted by bridgman View Post
                  Reusing code from Catalyst probably isn't an option since the internal designs are so different. We did try at the start of the project, but the changes required were big and it turned out to be a lot more work than writing the drivers from scratch.

                  On the other hand, writing the open source drivers for the next generation GPUs while the Catalyst work is still relatively fresh in everyones mind is bound to help. That was one of the reasons we ended up getting the acceleration code running on 7xx first (remeber the "first triangle" back in August last year) and then working out the 6xx-7xx differences to get the code working on 6xx as well.
                  Impressive that it was possible to make R700 features working without all of the R600, when they are so related.


                  • #49
                    Originally posted by Louise View Post
                    Could I have used git to tell me what branches that exist?
                    to see a list of remote branches:
                    git branch -r


                    • #50
                      Originally posted by agd5f View Post
                      to see a list of remote branches:
                      git branch -r
                      Cool! Thanks.

                      I am learning git right now, as you can tell .

                      I want to use it for my thesis, where I use Matlab.