radeonhd DRM/DRI with HD4850

D

Defre

Hi,

Never used freebsd as a desktop OS before 8.0.
Xorg runs fine with "radeonhd" as driver. However, I can't get any 3D acceleration (OpenGL runs through software rasterizer).
I tried a few tricks around 3D acceleration (drm.ko and radeon.ko are loaded, and "dri" "dri2" "glx" are specified in "xorg.conf").

However, I'm not a Xorg specialist, and I know quite nothing about freebsd advanced configuration (though I read most common parts of the handbook).

Are there any support for the HD4850 (works now quite well under Linux) ? Maybe I need to get & build unstable modules for DRM/DRI, and maybe also unstable Mesa ?

Well thanks for your support. Beside getting 3D working, learning how to test unstable modules of the freebsd kernel seem really interesting to me.

Thank for your support :)
 
Great timing for your question. This was posted on the freebsd-x11 mailing list today:

http://lists.freebsd.org/pipermail/freebsd-x11/2009-December/009093.html

Thankfully rnoland@ has been continuously working on the DRM, libdrm, and mesa support for FreeBSD for newer AMD cards, keeping it up-to-date (mostly) with the code being written for linux. Aside from KMS specific stuff, the open source driver works as well under FreeBSD as it does under linux.

I suggest reading that entire thread. Robert Does discuss some issues with the updates that nork@ posted, including issues with Mesa 7.6 that are fixed in 7.6.1 and master git.

Adam
 
Wow, what great timing. I was turning very green from seeing the nvidia 64bit driver release the other day, so hopefully I can go back to pink after trying this. :)
 
Thank you, that sounds good.

I tried to apply patch (don't know the right way, I did:
Code: 
$ cd /usr/ports/graphics
$ patch < patch-from-ml
), then I recompiled ports.


Xorg starts, however, glxgears stops immediately and prints:
Code: 
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.

No information relative to command stream in dmesg. However, when Xorg starts, dmesg contains:
Code: 
drm0: <ATI Mobility Radeon HD 4850> on vgapci0
info: [drm] MSI enabled 1 message(s)
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV770/RV790 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
hdac1: timeout in reset

"radeon 1.29.0 20080528" seems out of date to me... But no idea about what to do :).
 
Yep I know. My portstree was synced.
I was using an up-to-date xf86-video-radeonhd-devel, but switched to xf86-video-radeonhd, after seeing your message: problem is exactly the same.

dmesg now displays:
Code: 
info: [drm] Resetting GPU
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV770/RV790 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
hdac1: timeout in reset
 
I would not recommend radeonhd (nor would rnoland@). More testing is done by the 3D developers with the 'radeon' driver.

EDIT: And yes, 1.29.0 is old. DRM 1.31.0 is available. I'm using it in -CURRENT though I believe it's also available in 8_RELENG. Not sure about the 8.0 release.

Adam
 
Radeonhd works fine in 2D, no problems so far (FreeBSD 8 stable). 3D is a different story but it works okay in Fedora 12, even with Quake 3. So if there is any further problem it's a FreeBSD problem.
 
I'm not saying that 3D doesn't work with radeonhd. Simply that the developers who work on the open source 3D driver using the radeon driver instead. If you have problems with 3D + radeonhd, it's often worth testing with radeon.

Having said that, I do believe the problem is more likely to do with the DRM version being at 1.29.0 than with the 2D Xorg driver.
 
We will certainly see many more problems in the future while porting software, especially drivers, with Linux centric development.
 
oliverh said:
Radeonhd works fine in 2D, no problems so far (FreeBSD 8 stable). 3D is a different story but it works okay in Fedora 12, even with Quake 3. So if there is any further problem it's a FreeBSD problem.
Click to expand...
Yes, unfortunately acceleration is quite problematic under FreeBSD for many drivers. The Intel driver for instance locks the machine up every week. When you disable acceleration, it doesn't lock at all anymore.
 
Ok, I upgraded to 8-STABLE. All problems are solved.
"radeon" set-up the screen faster (lot of artifacts for a short-time with "radeonhd"), but seem a bit slower at 3D.

Desktop experience is perfect. I tested nexuiz: too slow to be played, however rendering occurs well.
Open-source drivers are getting really good, that's a great news. Thanks to all of you!!
 
Defre, nexuiz is slow but playable (at least for me) here. Are you sure 3D acceleration is working? What's the output of 'glxinfo'? (It's in graphics/mesa-demos if you need it).

Adam
 
Oh, excuse me. I just insisted on the fact that nexuiz was slower than usual for such cards.
I agree, beside it it is "playable" (although it won't be fun at all to play under such conditions).

Nothing unusual given announced driver status. :)
 
Hi adamk,

On my box, compiz works surprinsingly well (except effects like blur which corrupt pixmaps or display RGB gradient) . However, Nexuiz still has some problem. All this with direct rendering.
Configuration: FreeBSD 8.0-STABLE AMD64, GENERIC KERNEL on ATI HD4850.

All information to make it run can be found on freebsd-x11 ml: a great source of news and information.
8.0-RELEASE has an old drm, it won't work. Make sure to have at least STABLE.
Then, update Mesa. Ports in this post for Mesa 7.6.1-rc2 work well:
http://lists.freebsd.org/pipermail/freebsd-x11/2009-December/009083.html
You could also try the Mesa from freedesktop's git, hints from Robert Noland in the same thread also works.

Symbol problem should be solved:
Code: 
nm r600_dri.so  | grep sl_pp_context_create
                 U sl_pp_context_create
However, make sure r600_dri.so get recompiled, I got some problem with mixed Mesa 7.4 / 7.6.1 files... got to clean :).
 
Yes, I'm well aware of the freebsd-x11 mailing list and the r6xx/r7xx discussions that went on there. I'm probably one of the first to test the r600 driver on FreeBSD. While I'm sure that slightly older versions of Mesa work fine, my question stems from the fact that the glsl-pp-rework-2 branch just got merged to master a few days ago. At the present moment, Mesa from git will not give direct rendering with the r6xx driver on FreeBSD (-CURRENT amd64 and i386 were tested here), as far as I can tell.

I've already alerted rnoland to the breakage.

Adam
 
@defre did some tests too and it works like a charm :-)

Hardware: ATI Mobility Radeon HD 3430

Tests:

-tuxracer
-prboom in gl mode
-darkplaces (Quake1 opengl)

The latter (Quake1) is playable but stutters sometimes.

Compared to Fedora 12 it's rather slow on the same hardware. On Fedora 12 it's possible to play Quake 3 with radeonhd & dri. But it's nice to see this work on FreeBSD :-)
 
@adamk Oops, I just wanted to be helpful and I didn't even realize that you were the first to post an answer in the thread... Sorry, I will remember the next time ;).
Concerning Mesa, I was indeed using the git version, but not this branch.

@oliverh Nice to see how it works for you! Conclusion are the same on my computer, improvements in the open-source graphic stack are quite impressive.
 
@defre well, I have to revert may saying above. Quake3 (ioquake3-devel) runs indeed very smooth (800x600, high texture quality, trilinear filtering). I just removed hz=100 in /boot/loader.conf, it confuses snd_hda and lots of the graphics.
 
Being a lazy bum I changed bsd.mesalib.mk in graphics/libGL from rc2 to rc4 and recompiled dri, libGL, libGLU, libGLw, libglut and mesa-demos with make NO_CHECKSUM=yes. The result is great: glxgears shows 1214.658 FPS instead of 375 with rc2 and all above mentioned games run very smooth now.
 
@oliverh, would i happen to need 8-STABLE to compile mesa?
I got past those intel dri compile errors only to get intel_drm errors, figured it had something to do with me running -RELEASE.
 
You must log in or register to reply here.
Back
Top