Compiz Running With Mesa On R600/700 GPUs

[legume]

I can't seem to find why though... Xorg.0.log shows no errors at all, it loads the DRM driver just fine.
I have a 3870 btw...

Did you build new kernel radeon and drm modules? (the ones that come with 2.6.30 won't work for 3D, but will work for exa/xv accel)

Edit: If you didn't look back in this thread for how to get/build.

[mdias]

Did you build new kernel radeon and drm modules? (the ones that come with 2.6.30 won't work for 3D, but will work for exa/xv accel)

Edit: If you didn't look back in this thread for how to get/build.

I've got the same as the user on this post (mesa-git, xf86-video-ati-git, drm-radeon-module-git-r6xx-r7xx-3d and ati-dri-r6xx-r7xx). I've also tried to follow agd5f's instruction on this post but to no avail.

Also, when I tried to run compiz I was brought back to GDM login window. Before I had the driver installed I just got a plain white screen.

Thank you for the help

[legume]

I've got the same as the user on this post (mesa-git, xf86-video-ati-git, drm-radeon-module-git-r6xx-r7xx-3d and ati-dri-r6xx-r7xx).

Hmm looks like the modules are right then (I assume you rebooted after installing).

I notice from you previous post that you get -

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.5
OpenGL shading language version string: 1.20

Which doesn't look like mesa git, eg. if I force software I get -

bash-3.2$ LIBGL_ALWAYS_SOFTWARE=1 glxinfo |grep -i opengl
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.6-devel

I also don't get shader language, but then I build mesa git with gallium disabled.

LIBGL_DEBUG=verbose glxinfo

may give more clues about what is going on.

[Louise]

It is as I thought, I'm using the Software Rasterizer

Do you have SELinux disabled or in case of Suse, AppArmor disabled? They tend to prevent root from installing unsigned libraries for security reasons.

[Perry3D]

Hmm looks like the modules are right then (I assume you rebooted after installing).

I notice from you previous post that you get -

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.5
OpenGL shading language version string: 1.20

Which doesn't look like mesa git, eg. if I force software I get -

bash-3.2$ LIBGL_ALWAYS_SOFTWARE=1 glxinfo |grep -i opengl
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.6-devel

I also don't get shader language, but then I build mesa git with gallium disabled.

LIBGL_DEBUG=verbose glxinfo

may give more clues about what is going on.

I think Arch is splitting the mesa packages in ati-dri (intel-dri), mesa and libgl.
Maybe u have to build a libgl package from git.


/edit: OK, with libgl-git it works.

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV770 9442) 20090101  TCL
OpenGL version string: 1.4 Mesa 7.6-devel
OpenGL extensions:

I will upload it to AUR in a few minutes.

/edit: Oh, already a PKGBUILD in AUR.

[lordmozilla]

/edit: Oh, already a PKGBUILD in AUR.

You got to love arch... Well at least I know by the time i get back to my desktop in october, I can have KDE4.3 running with compositor using the OSS drivers!

[nanonyme]

Do note though that even if the Mesa driver becomes fast soonish, running OpenGL programs under Compiz will still be pain before r6xx/r7xx gets DRI2. Might take its time, depending on how hard the memory manager and command submission stuff is to code... (reading airlied's development blog memory manager sounded pretty much like trying to bungee jump yourself up the tree backwards instead of climbing - can just imagine how many bruises in your head you'll have after that)

[agd5f]

Do note though that even if the Mesa driver becomes fast soonish, running OpenGL programs under Compiz will still be pain before r6xx/r7xx gets DRI2. Might take its time, depending on how hard the memory manager and command submission stuff is to code... (reading airlied's development blog memory manager sounded pretty much like trying to bungee jump yourself up the tree backwards instead of climbing - can just imagine how many bruises in your head you'll have after that)

The command submission stuff should be relatively easy since the current r600 3d driver uses the CS ioctl already. The CS ioctl code in the drm would just need to be ported to work with ttm. This is another reason we switched r600 development over to the radeon-rewrite tree.

[bridgman]

Yep... that's a big part of what the developers have been doing between April and now - switching over to the new CS API which bridges between non-KMS and KMS/GEM/TTM environments, and dealing with the fallout.

[Drago]

Yep... that's a big part of what the developers have been doing between April and now - switching over to the new CS API which bridges between non-KMS and KMS/GEM/TTM environments, and dealing with the fallout.

Hello there, can you tell me how many developers approximately are involved in open source R600-700 development. Thanks.