Initial R6xx/R7xx 3D Driver

[nanonyme]

Anyone gotten the respective radeon module to load on kernel 2.6.29?

[Pitabred]

The r600 string appears in the radeon_drv.so file; about the glxinfo output, I can't provide it immediately because I'm working remotely and I'm unable to get a proper display offering the same capabilities it would locally. I will update as soon as I can.

Just FYI... when you're working remotely, you can just "export DISPLAY=:0" and then run glxinfo, glxgears, any of that as long as you have your X server running on the remote machine (and it's server 0) you'll just set those programs to use the remote machine's local display. You won't get anything but the console output from where you are, but that's generally all that you need.

[legume]

Anyone gotten the respective radeon module to load on kernel 2.6.29?

Just tried vanilla 2.6.29.2 and it works OK.

I've found that on a linux from scratch system I have to explicitly specify where my kernel is like -

make LINUXDIR=/home/andy/Src/Kernels/linux-2.6.29.2 DRM_MODULES="radeon"

[Nille]

Little helper script with dkms support:

http://kanotix.com/files/fix/dkms/dr...7xx-3d-dkms.sh

Kano you are the best. Thank you very much.

[xenon]

Just FYI... when you're working remotely, you can just "export DISPLAY=:0" and then run glxinfo, glxgears, any of that as long as you have your X server running on the remote machine (and it's server 0) you'll just set those programs to use the remote machine's local display. You won't get anything but the console output from where you are, but that's generally all that you need.

Thanks, but I had tried that and a few other things without success. There's probably a solution, but hopefully I won't need to do much remote X debugging in the future.

[nanonyme]

Just tried vanilla 2.6.29.2 and it works OK.

I've found that on a linux from scratch system I have to explicitly specify where my kernel is like -

make LINUXDIR=/home/andy/Src/Kernels/linux-2.6.29.2 DRM_MODULES="radeon"

Yeah, compiling went fine. It's just that (on a F11 kernel which is based on 2.6.29) I got this when trying to load radeon.ko http://nanonyme.kapsi.fi/logs/1.txt
So I was wondering if someone could vouch for it working with stock 2.6.29.

[PuckPoltergeist]

Hm, glxgears won't work here. Perhaps again AGP related?

The output:

puck@datengrab ~ $ glxgears
[r600]  Mappings:
        Registers                         cpu 0x7f13d09a6000   size 0x00010000   handle 0xff3f0000
        Status                            cpu 0x7f13d09a5000   size 0x00001000   handle 0xf0101000
        GART           gpu 0x00f0000000
        DRM buffers    gpu 0x00f0102000   cpu 0x7f13bbc7a000   size 0x00200000
        GART Textures  gpu 0x00f0302000   cpu 0x7f13bbe7a000   size 0x01c80000   handle 0xf0302000
        Framebuffer    gpu 0x00d0000000   cpu 0x7f13bdafa000   size 0x10000000
        Front Target   gpu 0x00d0000000   cpu 0x7f13bdafa000   size 0x00b7c000   pitch 0x0700
        Back  Target   gpu 0x00d0b84000   cpu 0x7f13be67e000   size 0x00b7c000   pitch 0x0700
        Depth Target   gpu 0x00d1700000   cpu 0x7f13bf1fa000   size 0x00b7c000   pitch 0x0700

[r600] r600MakeCurrent   (r600_context.c:413)
[r600]    Context 0x123a230 Draw 0x1239510 Read 0x1239510
[r600] r600MemAlloc   (r600_mem.c:289)   allocated 1 at age 0
[r600] r600MemFree   (r600_mem.c:328)   freed 1 at age 0
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600CopyBuffer   (r600_screen.c:479)
[r600]    ClipRect 5:25-305:325
[r600] r600MemAlloc   (r600_mem.c:289)   allocated 1 at age 0
[r600] r600MemFree   (r600_mem.c:328)   freed 1 at age 0
glxgears: r600_mem.c:297: r600MemFree: Assertion `id <= context->memManager->u_last' failed.
Abgebrochen

dmesg:

agpgart-amd64 0000:00:00.0: AGP 3.0 bridge
agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
radeon 0000:01:00.0: putting AGP V3 device into 8x mode
[drm] Setting GART location based on new memory map
[drm] Loading RV635 CP Microcode
[drm] Loading RV635 PFP Microcode
[drm] Resetting GPU
[drm] writeback test succeeded in 2 usecs
[drm:r600_cs_packet3] *ERROR* bad tex base 0x0000000000000000
[drm:r600_cs_packet3] *ERROR* fb 0x20000000, 0xd0000000 - 0xefffffff
[drm:r600_cs_packet3] *ERROR* gart 0x02000000, 0xf0000000 - 0xf1ffffff
[drm:r600_cs_packet3] *ERROR* bad SET_RESOURCE
[drm:r600_cs_packet3] *ERROR* bad tex base 0x0000000000000000
[drm:r600_cs_packet3] *ERROR* fb 0x20000000, 0xd0000000 - 0xefffffff
[drm:r600_cs_packet3] *ERROR* gart 0x02000000, 0xf0000000 - 0xf1ffffff
[drm:r600_cs_packet3] *ERROR* bad SET_RESOURCE
[drm:r600_cs_packet3] *ERROR* bad tex base 0x0000000000000000
[drm:r600_cs_packet3] *ERROR* fb 0x20000000, 0xd0000000 - 0xefffffff
[drm:r600_cs_packet3] *ERROR* gart 0x02000000, 0xf0000000 - 0xf1ffffff
[drm:r600_cs_packet3] *ERROR* bad SET_RESOURCE
[drm:r600_cs_packet3] *ERROR* bad tex base 0x0000000000000000
[drm:r600_cs_packet3] *ERROR* fb 0x20000000, 0xd0000000 - 0xefffffff
[drm:r600_cs_packet3] *ERROR* gart 0x02000000, 0xf0000000 - 0xf1ffffff
[drm:r600_cs_packet3] *ERROR* bad SET_RESOURCE

/var/log/Xorg.0.log doesn't show something related to this failure

[bridgman]

It's probably going to be a week or so before the devs get back to troubleshooting bugs. Right now the priority is getting the new 3D code running on the radeon-rewrite base, which involves different paths for the bottom part of the 3D driver and different paths in the DRM IIRC.

The code where the problems are likely to be is the code that's going to be replaced in a week

[PuckPoltergeist]

It's probably going to be a week or so before the devs get back to troubleshooting bugs. Right now the priority is getting the new 3D code running on the radeon-rewrite base, which involves different paths for the bottom part of the 3D driver and different paths in the DRM IIRC.

The code where the problems are likely to be is the code that's going to be replaced in a week

Ah ok, good to know. I will try it again then.

[nanonyme]

It's probably going to be a week or so before the devs get back to troubleshooting bugs. Right now the priority is getting the new 3D code running on the radeon-rewrite base, which involves different paths for the bottom part of the 3D driver and different paths in the DRM IIRC.

The code where the problems are likely to be is the code that's going to be replaced in a week

Maybe, maybe not. I'm having my problems solely with the DRM code. (I'm confident agd5f and folks will check compatibility issues soon. I was mostly trying to find out if my problems were due to Fedora modifications to the kernel or if 2.6.29 is simply too Different (tm))
Edit: Oh, you meant the DRM part might get rewritten too?