Announcement

Collapse
No announcement yet.

ATI R600/700 OSS 3D Driver Reaches Gears Milestone

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

  • Any estimate on when we can expect the necessary DRM to be merged into the kernel? 2.6.31-rc4? Or is that being too hopeful?

    Comment


    • Because of the good progress here, I'm selling my GTX260+ and keep using my 2900XT for a while. When the next gen 'Evergreen' comes up and OSS drivers plays good with it (even only 2D + XV) I am going to buy a high end model of it --- voting with my cash!

      Comment


      • RV620 regression

        When previously I tested r6xx-rewrite:
        Code:
        commit 10b3e64bcada2e68144cc6ed40f7d760aff873e2
        Author: Alex Deucher <[email protected]>
        Date:   Tue Jul 14 21:19:32 2009 -0400
        
            R6xx/r7xx: implement memcpy buffer swaps
        I got nice glxgears *window* with broken colors. No problems with blackscreen.


        Now I retested this with master:
        Code:
        commit a8921d0b52f04bbd62c66278e7421e6b99bfd7c3
        Author: Dave Airlie <[email protected]>
        Date:   Sat Jul 18 17:44:44 2009 +1000
        
            gallium: make g3dvl build again
        I get full black screen when starting glxgears (only mouse cursor is visible). When I press ALT+TAB (glxgears window looses focus) it's OK. Gears are being rendered and colors are OK. When I give glxgears focus again, black screen shows again.

        Comment


        • Originally posted by forum1793 View Post
          Lock-up occurs with radeonhd also. [edit] with accelMethod EXA and DRI on.

          So far I think every lock-up occurs after opening window in X, such as Konsole terminal or firefox, and trying to drag window. When I click in body of terminal and type, it does not lock up. Only when clicking on top bar of window and dragging.

          Not sure if anyone recognizes this behavior in relation to the changed packages I posted earlier.

          Is anyone else using xorg-server 1.6.2 with an hd3200 or similar and getting these lockups?
          Someone posted on linuxquestions.org that the [my] problem was due to upgrading pixman. I have built and installed pixman-0.15.10 and the lock-ups no longer occur.

          Whether it was pixman alone or that associated with xorg-server upgrade in conjunction with dri, I don't know. Seems to be working OK now.

          Edit: I confirmed the same change resolves the issue with the 64 bit version (slackware64-current).
          Last edited by forum1793; 18 July 2009, 08:23 AM.

          Comment


          • Like I promised, I started to compile the experimental branch. However, I ran into a snag: the configure file of the Mesa branch doesn't like relative paths. Any quick-fixes for that?

            Code:
            j@Brutus:~/git_clones/mesa$ ./autogen.sh --with-dri-drivers=swrast,r600 --libdir=$(pkg-config --variable=libdir dri) --includedir=$(pkg-config --variable=includedir dri) --disable-gallium --enable-debug
            autoreconf: Entering directory `.'
            autoreconf: configure.ac: not using Gettext
            autoreconf: running: aclocal
            autoreconf: configure.ac: tracing
            autoreconf: configure.ac: not using Libtool
            autoreconf: running: /usr/bin/autoconf
            autoreconf: configure.ac: not using Autoheader
            autoreconf: configure.ac: not using Automake
            autoreconf: Leaving directory `.'
            configure: error: expected an absolute directory name for --includedir:

            Comment


            • Originally posted by JeanPaul145 View Post
              Like I promised, I started to compile the experimental branch. However, I ran into a snag: the configure file of the Mesa branch doesn't like relative paths. Any quick-fixes for that?

              Code:
              j@Brutus:~/git_clones/mesa$ ./autogen.sh --with-dri-drivers=swrast,r600 --libdir=$(pkg-config --variable=libdir dri) --includedir=$(pkg-config --variable=includedir dri) --disable-gallium --enable-debug
              autoreconf: Entering directory `.'
              autoreconf: configure.ac: not using Gettext
              autoreconf: running: aclocal
              autoreconf: configure.ac: tracing
              autoreconf: configure.ac: not using Libtool
              autoreconf: running: /usr/bin/autoconf
              autoreconf: configure.ac: not using Autoheader
              autoreconf: configure.ac: not using Automake
              autoreconf: Leaving directory `.'
              configure: error: expected an absolute directory name for --includedir:
              dont copy & past commands without the knowlege about it

              you system has not an package dri so he cant get an path with pkg-config --variable=XXX dri

              Comment


              • Also note that 6xx/7xx mesa support has been merged to mesa master, so you don't want to be building from the branch any more.

                The drm still needs to come from the r6xx-r7xx-3d branch of ~agd5f/drm, however.
                Test signature

                Comment


                • re: the black screen problem, it's starting to appear that the issue is actually not 6xx/7xx-specific at all, since people are starting to see it on earlier GPUs as well.

                  Current thinking is that the following commit is the issue : http://cgit.freedesktop.org/mesa/mes...45d50a53c090ce

                  The change is in GLX, which explains how glxgears could have the problem but not gears. Thanks to MrCooper and rnoland for figuring this out.

                  I'm not sure exactly how this causes the problem yet, but the general idea is that the change marks certain visuals (frame buffer / depth buffer formats) as non-conformant so the application uses a different visual which is what results in the different behaviour. There's still a bit of head-scratching going on re: the details, I think...

                  BTW there is a good chance that the glx change is just triggering an existing problem somewhere in the driver stack, so reverting the above commit may be a workaround rather than a fix.

                  EDIT; also, there seems to be some tie-in to the window manager. This might explain why Richard and Cooper (who just ran startx from the command line) weren't seeing the black screen problem. Not sure yet.
                  Last edited by bridgman; 18 July 2009, 02:29 PM.
                  Test signature

                  Comment


                  • I run startx from command line and get the black screen. I'm using kde so maybe the kde window manager plays a role.

                    Also, thinking the pixman problem might be due to headers used in compiling, I recompiled 0.15.16 after installing the drm/mesa...

                    Same lock up problem. As soon as you click the mouse on a window top bar, the mouse icon turns to the four arrows (one in each direction). You drag the window and it locks up. The problem is repeatable. Went back to pixman-0.15.10 and no lockups.

                    As the other distributions adopt the newer xorg-server files this problem will become more of an issue.

                    Comment


                    • The messages I saw indicated that the user had to kill off his window manager to get rid of the black screen.

                      11:21 #radeon: < boghog> seems weird to me though that killing my window manager also makes it go away
                      11:21 #radeon: < bridgman> boghog, did you try running something like glxgears after killing the wm ?
                      11:22 #radeon: < bridgman> and still have no black screen ?
                      11:22 #radeon: < boghog> yeah
                      11:22 #radeon: < boghog> without a wm there's no problems at all
                      Test signature

                      Comment

                      Working...
                      X