Page 11 of 41 FirstFirst ... 91011121321 ... LastLast
Results 101 to 110 of 406

Thread: ATI R600/700 OSS 3D Driver Reaches Gears Milestone

  1. #101
    Join Date
    May 2008
    Posts
    98

    Default

    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?

  2. #102
    Join Date
    Aug 2007
    Posts
    437

    Default

    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!

  3. #103
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    182

    Default RV620 regression

    When previously I tested r6xx-rewrite:
    Code:
    commit 10b3e64bcada2e68144cc6ed40f7d760aff873e2
    Author: Alex Deucher <alexdeucher@gmail.com>
    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 <airlied@redhat.com>
    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.

  4. #104
    Join Date
    Jul 2008
    Posts
    208

    Default

    Quote 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; 07-18-2009 at 08:23 AM.

  5. #105
    Join Date
    Aug 2008
    Posts
    116

    Default

    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:

  6. #106
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    658

    Default

    Quote 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

  7. #107
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,438

    Default

    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.

  8. #108
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,438

    Default

    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; 07-18-2009 at 02:29 PM.

  9. #109
    Join Date
    Jul 2008
    Posts
    208

    Default

    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.

  10. #110
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,438

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •