Announcement

Collapse
No announcement yet.

Open-Source ATI R600/700 3D Driver Almost Working

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

  • #91
    Well, then I guess we all learned something

    Seriously, AFAIK the change you made was disabling the PCIE lane change always, while the fix Alex pushed only did it for specific X2 cards (ie the pushed fix shouldn't affect your system since you don't have an X2).

    If disabling PCIE lanes makes a difference on your system that means there must be some suspend/resume code mucking with PCIE lanes that we don't know about, and that perhaps having a more general way to disable PCIE lane constriction might be useful.
    Last edited by bridgman; 07-09-2009, 12:05 PM.

    Comment


    • #92
      Originally posted by bridgman View Post
      Well, then I guess we all learned something

      Seriously, AFAIK the change you made was disabling the PCIE lane change always, while the fix Alex pushed only did it for specific X2 cards (ie the pushed fix shouldn't affect your system since you don't have an X2).

      If disabling PCIE lanes makes a difference on your system that means there must be some suspend/resume code mucking with PCIE lanes that we don't know about, and that perhaps having a more general way to disable PCIE lane constriction might be useful.
      Just to be clear :-) I didn't try Alex's code, because I saw the code wouldn't affect my card. But disabling the pcie lane change completely, seemed to fix my problem. So I guess, as you say, there is something general which has to be fixed with the pcie lane function call, if we talk suspend, shutdown etc.

      Comment


      • #93
        Newest r6xx-rewrite seems to have funky behaviour with redbook hello (RV670, 2.6.28). :3
        Originally:
        http://koti.kapsi.fi/nanonyme/public/grey.png
        If I increase window size:
        http://koti.kapsi.fi/nanonyme/public/blue.png
        If I decrease window size:
        http://koti.kapsi.fi/nanonyme/public/black.png
        In case it isn't obvious to everyone, that last picture is what the demo is supposed to look like.
        (at least it no longer locks up when changing window size...)

        Comment


        • #94
          For what it's worth, that's roughly what I see with my rv620. When I put in an rv770 things seem to look correct. We're running slightly newer code than you (ie todays changes) but we should be able to sync up again tomorrow.

          Comment


          • #95
            I know that full PowerPlay-style power management won't be here for a while, but any chance of simple fan adjustments and temperature readings, so I could manually control it? I don't stress my card much in Linux and I'm thinking it could handle a lower speed pretty safely, but obviously I'd like to watch temps also.

            Comment


            • #96
              If you're talking about documentation required for a developer to write the code, I think it's available now (between info we have released and datasheets from the fan/temp chip vendors). If you're talking about someone actually *writing* the code, that'll probably take longer but as the developers say "patches welcome".

              The main reason devs haven't touched this yet is that the code should really go in the kernel so it's on the list of "things to be done right after kernel modesetting and all the associated bits stabilize".
              Last edited by bridgman; 07-09-2009, 10:48 PM.

              Comment


              • #97
                Originally posted by bridgman View Post
                For what it's worth, that's roughly what I see with my rv620. When I put in an rv770 things seem to look correct.
                Sounds about right then. I recently diverted from Fedora 11 enough to install a stock X server, libdrm from git master with --enable-experimental-radeon-api and xf86-video-ati from git master so test results should be pretty much coherent now. And that rv770 thing; yeah, I guess everyone's expecting it to work at least as well if not better with rv7xx than rv6xx... I was mostly being thrilled that the lockups left, I suspect it had to do with that CS dump disabling commit but unsure. (while it would make sense, kinda, should test - then again, who does regression testing to find out where a but got fixed?)

                Comment


                • #98
                  Yeah, it was the CS dump. Figures that the biggest problem we had was in the debugging code ;(

                  In terms of 6xx vs 7xx, it's really a matter of "what the devs have in their machine right now is probably the only thing that works", and that is usually either an rv770 or an rv730. We're just starting to swap out cards and test it on other GPUs now - I'm checking on a couple of 6xx parts and Alex is checking on RS780.
                  Last edited by bridgman; 07-10-2009, 07:55 AM.

                  Comment


                  • #99
                    Originally posted by bridgman View Post
                    Yeah, it was the CS dump. Figures that the biggest problem we had was in the debugging code ;(
                    Yea that mesa commit fixed my lockup, and let xterm/dmesg display the error - which is fixed by the latest commit to agd5f drm.

                    So I now have an almost working hello - I can resize OK, but did get grey once when maximising the window.

                    I have found a reliable way to crash it (hello is unresponsive, using 100% CPU and display distorted) - just move it around while part of it is off screen. I can pkill it OK.

                    Comment


                    • Temp solution.......

                      Originally posted by d2kx View Post
                      Why is fglrx no option for you? If it's because it's closed source, then why do you want to buy a high-end card that couldn't be properly accelerated by the opensource driver anyway?
                      I use ATI 3850 with openSUSE 11.1 with GNOME 2.26, KDE 4.24, Compiz/Fusion 8.2 and everything works stable. Really have had no problems. And I just installed a AMD 955 Black AM3, DDR3 1333Mhz with a ATI 4890 and it works great!!

                      I run a lot of 3D Linux games and 2D games...they work great...

                      I use VirtualBox 3.02 for specific Windows programs I may need...I even play some awesome games in Wine/PlayOnLinux, Windows Games running beautifully in Linux without Windows. Even in a separate session...if they die it returns to Linux first session without issues.

                      So you may want to think about the distro your using...the Opensource driver may not be ready yet...but ATI has gone a long way in helping Linux get some of the bling it deserves even if using their non-Opensource Driver, instead of Windows only.

                      But keep up the good work on the testing of the opensource driver....I also have been testing the Opensource driver....mainly it is the speed that there is a problem with...everything works...but extremely slow in 3D compared to AMD's driver, at least under openSUSE 11.1. I have even setup SUSE Enterprise Desktop 11, adding the openSUSE 11.1 Compiz XGL repo for Compiz 7.8 latest and the Wine repo and the packman repo and the openSUSE 11.1 oss/non-oss/update repos just for specific updates and then disable them keeping as much of the SLED 11 base as possible and got all Video acceleration to work and all compiz functions with the AMD's Driver 9.6 on ATI 3200 Embedded motherboards...so I am very happy at the moment....totally stable and everything runs clean. Using the opensource driver everything runs fast and clean, but no compiz, or accelerated video or 3D, so I use the 9.6 ATI driver with specific updates and everything works.

                      Hope that helps.
                      Last edited by fr2000; 07-15-2009, 05:21 AM.

                      Comment


                      • Update - using current Mesa and agd5f drm modules on 2.6.28.8 on rv670 AGP card.

                        Hello is better - it doesn't crash anymore when part off screen and resizing on screen is OK.

                        Top and left clipping still gives distorted image, which gets redrawn correctly when returning on screen. Sometimes the return to screen results in black becoming grey or rarely whole window in white. In both cases forcing a redraw by resizing fixes the output.

                        Edit: I also notice that it will draw over the top of and not clean up an xterm if obscured by it.

                        glxgears runs @ 10fps, but does not draw anything.

                        Edit: I see on http://jbridgman.livejournal.com/ that r6xx colour problems are known, so I guess I get black - it's the same on the "working on r7xx" redbook progs listed there that use colour.
                        Last edited by legume; 07-15-2009, 10:40 AM.

                        Comment

                        Working...
                        X