OpenBSD Journal

Call for Testers: radeondrm(4) updates

Contributed by tbert on from the not-that-DRM dept.

Jonathan Gray (jsg@) posted a call for testers for radeondrm(4) updates:

I'm looking for a few people to test some additional radeondrm fixes from the recently released Linux 3.8.13.27: https://lkml.org/lkml/2014/7/25/621

In particular on newer asics with displayport/eDP as I can only test on r100/lvds at the moment.

(Comments are closed)


Comments
  1. By luko (85.159.104.244) lukves@centrum.sk on

    my small wish, and question will be in the short future supported low powered 25W AMD Athlon 5350 with Radeon 8400 ?

    Comments
    1. By Jonathan Gray (210.15.216.215) on

      > my small wish, and question will be in the short future supported low powered 25W AMD Athlon 5350 with Radeon 8400 ?

      From what I can made out that is a kabini based part. While we have some support in the kernel for some of the initial radeonsi devices that doesn't include kabini currently.

      The way the code that AMD has released works makes it quite hard to support any of the radeonsi devices. There is no normal X acceleration support for these parts only OpenGL/OpenGLES based 'Glamor' acceleration which in turn seems to require an EGL with the drm/gbm backend instead of the usual GLX backend. Glamor was a seperate project but seems to have recently been heavily modified and integrated as part of the recently released X.org 1.16 server release.

      In order to use OpenGL (ie Mesa), on these devices the radeon target in LLVM is a hard requirement. LLVM is not currently part of src or xenocara, only ports.

      So the list to have basic 2D acceleration is something like
      - update kernel radeon drm code to support kabini
      - support for drm/gbm backend in EGL
      - glamor-egl in xenocara or more likely x.org server 1.16
      - possible mesa update (should be fine?)
      - possible xf86-video-ati update (should be fine?)
      - rebuild xf86-video-ati with glamor enabled
      - llvm to be integrated into src (or rebuild xenocara with XENOCARA_BUILD_GALLIUM=llvm)
      - newer versions of llvm no longer work with our libstdc++ so hope that you don't need those changes

      With the radeonsi devices the kernel supports it should be possible to use the modesetting driver with shadowfb at least. With kabini you'll have to use vesa.

      These things are unlikely to all happen in the short term.

      Comments
      1. By Anonymous Coward (85.159.104.244) on

        lot of thanks for your quick answer, i think will be better buy cheap old radeon :D

      2. By Brad (brad) on

        > - newer versions of llvm no longer work with our libstdc++ so hope that you don't need those changes

        libstdc++ isn't the issue. It can't even be compiled. We have to work with what we have now and that is the only option.

        Comments
        1. By Jonathan Gray (210.15.216.215) on

          > > - newer versions of llvm no longer work with our libstdc++ so hope that you don't need those changes
          >
          > libstdc++ isn't the issue. It can't even be compiled. We have to work with what we have now and that is the only option.

          llvm svn now requires c++11 and libc++ or libstdc++ >= 4.7 to build.
          When using clang from ports to compile clang svn it won't build due to parts of std:: missing in the gcc 4.2.1 libstdc++ from base.

          Base g++ can't be used due to c++11.

          Building with ports g++ 4.8.3 works though:
          clang -v
          clang version 3.6.0 (trunk 214622) (llvm/trunk 214620)
          Target: x86_64-unknown-openbsd5.6
          Thread model: posix
          Perhaps this would require some driver tweaks to point to libestdc++ again to work properly for clang++.

          I guess you meant building with gcc4 from base?
          The llvm port used to depend on the gcc4 port before gcc4 was imported into base. From a ports perspective I don't see why that couldn't happen again? Wanting to avoid bootstrap problems? Trying to focus on a particular version for if/when it migrates out of ports?

          Comments
          1. By Anonymous Coward (2001:470:b01e:3:214:51ff:fe67:4efb) on

            > I guess you meant building with gcc4 from base?

            Correct. We need a newer compiler in base and it has to be something that can be built with gcc4.2... unless of course the project would be willing to accept a relatively crazy bootstrap process. I don't think that is likely.

            > The llvm port used to depend on the gcc4 port before gcc4 was imported into base. From a ports perspective I don't see why that couldn't happen again? Wanting to avoid bootstrap problems? Trying to focus on a particular version for if/when it migrates out of ports?

            I have mentioned the issue with base libstdc++ vs a libstdc++ from newer GCC for the purpose of having C++11 support but nothing has been done about it so far. Part of it is not wanting to essentially depend on ports GCC for the relevant sub-package. The remaining issue(s) with libc++ need to be worked out.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]