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?
Announcement
Collapse
No announcement yet.
ATI R600/700 OSS 3D Driver Reaches Gears Milestone
Collapse
X
-
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
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
Comment
-
Originally posted by forum1793 View PostLock-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?
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 PostLike 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:
you system has not an package dri so he cant get an path with pkg-config --variable=XXX dri
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 allTest signature
Comment
Comment