1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

radeonhd DRM/DRI with HD4850

Discussion in 'X.Org' started by Defre, Dec 5, 2009.

  1. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    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 :)
     
  2. adamk

    adamk New Member

    Messages:
    1,624
    Likes Received:
    0
    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
     
  3. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    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. :)
     
  4. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    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 :).
     
  5. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    Update your portstree, radeonhd 1.3.0 is ready.
     
  6. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    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
    
     
  7. adamk

    adamk New Member

    Messages:
    1,624
    Likes Received:
    0
    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
     
  8. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    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.
     
  9. adamk

    adamk New Member

    Messages:
    1,624
    Likes Received:
    0
    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.
     
  10. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    We will certainly see many more problems in the future while porting software, especially drivers, with Linux centric development.
     
  11. Beastie

    Beastie Member

    Messages:
    1,916
    Likes Received:
    1
    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.
     
  12. aragon

    aragon New Member

    Messages:
    2,031
    Likes Received:
    0
    To the OP, this is x11-drivers/xf86-video-ati

    Just to affirm what you said, I'm on 8.0-STABLE and have DRM 1.31.0 here.
     
  13. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    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!!
     
  14. adamk

    adamk New Member

    Messages:
    1,624
    Likes Received:
    0
    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
     
  15. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    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. :)
     
  16. thuglife

    thuglife New Member

    Messages:
    160
    Likes Received:
    0
  17. adamk

    adamk New Member

    Messages:
    1,624
    Likes Received:
    0
    But is it using direct rendering? I keep getting an undefined symbol in r600_dri.so "sl_pp_context_create".

    Adam
     
  18. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    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 :).
     
  19. adamk

    adamk New Member

    Messages:
    1,624
    Likes Received:
    0
    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
     
  20. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    @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 :)
     
  21. Defre

    Defre New Member

    Messages:
    19
    Likes Received:
    0
    @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.
     
  22. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    @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.
     
  23. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    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.
     
  24. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
  25. kolbycrouch

    kolbycrouch New Member

    Messages:
    34
    Likes Received:
    0
    @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.