XDC 2015 and EuroBSDcon 2015

This year, I attended two conferences: the XDC (X.Org Developers Conference) and EuroBSDcon.

XDC 2015

The XDC was from the 16th to the 18th of September, in Toronto, Canada. Last year, I did a talk giving the status of the graphics stack on FreeBSD, but not this year. I felt we did not make enough progress. Nevertheless, the conference was very interesting and we had fruitful discussions. Ed Maste from the FreeBSD Project and the FreeBSD Foundation was there too, along with Johannes Dieterich, a contributor who did an excellent job helping Koop Mast with the new OpenCL ports: we were three to represent FreeBSD!

Here is a list of the most important topics to the FreeBSD community:

  • Peter Hutterer from Red Hat gave talk about libinput, following the 1.0 release in last August. As a reminder, libinput is a new library for handling input devices. It is used by Wayland compositors and eventually will replace all the xf86-input-* DDX in the X.Org server.
  • Randy Fishel from Solaris presented their work on porting the kernel video drivers. He talked to us about sharing their implementation of a Linux shim. He is pretty happy with this layer. We need to come back to Alan Coopersmith and him about this.
  • Keith Packard discussed the next two releases of the X.Org server. xserver 1.18 should happen later this month. I took this occasion to test RC 1 on FreeBSD and there was no problem (on a Radeon-based laptop). xserver 1.19 is scheduled for March 2016. Then, he talked about a long-time issue with select() in xserver he would like to fix with the support for SIGIO in epoll() on Linux. He kindly asked other OSes developers, including us, if a similar feature existed. This is something I still need to check before I get back to Keith.

You can find slides and videos from the talks on the XDC wiki. There were many interesting presentations beyond what I summed up here.

During breaks, we also spent some time with Johannes to debug the new i915 kernel driver. He was very helpful and I could make a lot of progresses.

We also discussed with Ed about the long term issues with the graphics stack on FreeBSD. It was really important and meant a lot to me to meet him at this non-FreeBSD conference. But let’s talk about EuroBSDcon first.

EuroBSDcon 2015

EuroBSDcon was held between the 1st and the 4th of October 2015 in Stockholm, Sweden: two days of FreeBSD devsummit followed by two days for the conference itself.

The FreeBSD devsummit is comprised of several working groups and presentation. I hosted a session on the graphics stack. The goals were to get attention from all FreeBSD developers to problems we encounter and to the importance of having a working stable graphical environment. I feel it was a success! You will find the details in the wiki article linked above.

What came out of these two conferences?

Again, we had a wonderful welcome at the XDC. People even asked why we could not make it to the FOSDEM in last February. So meeting the graphics stack community really makes a difference and we will definitely attend next FOSDEM! Likewise, I met many FreeBSD developers and users for the first time during EuroBSDcon and it was about time!

I’m confident the FreeBSD Project is now well aware that the graphics stack is critical to its success: if there is one reason to remember, it is mandatory to attract and keep new users.

On the technical side of things, we focused on:

  • The Linux shim. Our current code in OFED is partly covered by the GPL license. See the devsummit wiki for the conclusion of this discussion. But we forgot about the shim from Solaris and it is worth a look. So we still have work to do but progress was made.
  • The input stack. To move forward, Jakub accepted to put his evdev branch in Phabricator as soon as possible, even commit it maybe. Then, we all agreed on a udev wrapper above libdevq. We still need to put some thoughts in the libdevq design before this can be achieved.

Of course, many people asked about the status of the new i915 driver and especially Haswell and Broadwell support. The new driver is more and more stable. It will include Haswell support, but not Broadwell.

As you understand, I had a wonderful time at these two conferences. I’m looking forward the next one: FOSDEM 2016! And it is a great opportunity as both the FreeBSD and the graphics stack communities go there.

ICC profiles and “startx” on FreeBSD

Beyond photography, I find that a calibrated screen is more comfortable to use, especially if you have two or more monitors with uneven panels and colors rendering.

You can buy a professional colorimeter for a not-so-small amount of money, but fortunately, there’s an open-source alternative. Richard Hughes developed ColorHug, a free open-source colorimeter that you can build yourself or order from him. I bought one myself shortly after it was released. It gives very good results, comparable to professional devices.

To calibrate the screen, FreeBSD lacks the appropriate applications in the Ports tree. As pointed out by Koop Mast, we have Argyll CMS (graphics/argyllcms) in the Ports tree, an application which can drive colorimeters. However, I didn’t test it because it wasn’t available at the time I got mine. The ColorHug is provided with a modified Fedora live CD with all the required programs installed and configured. Just boot your computer using this CD, plug the device and the wizard starts automatically, offerring you to calibrate all connected monitors. The process is quite straightforward and takes from a few minutes to 20-25 minutes, depending on the accuracy you want. When it’s finished, you have your shiny new profile(s) in ~/.local/share/icc. Profiles are named after monitor’s name and the date of the calibration. You need to copy those files to the same location on your FreeBSD desktop.

Now, you need to configure your computer to use the generated profile(s). GNOME, KDE and any other modern desktop environment come with display configuration tools which are easy to use. For those preferring a more lightweight environment and startx, things are a bit more complicated. Here is what I had to do.

Continue reading ICC profiles and “startx” on FreeBSD

Mesa 10.x and i915 on FreeBSD 9.x

Currently, the i915 driver on FreeBSD 9.3 has no support for hardware context. This means we are stuck with Mesa 9.1 and xserver 1.14.

To solve this, the plan is to provide the i915 kernel driver as a port. xf86-video-intel is modified to automatically load this driver, instead of the i915kms.ko module shipped with FreeBSD 9.3-RELEASE.

A patch is available: we would like users running FreeBSD 9.3 on an i915-based desktop to test it with their daily workload.

To test it, you need to:

  1. apply the patch:
    cd /usr/ports
    patch -p1 < /path/to/drm-kmod.a.patch
  2. build and install x11-drivers/drm-kmod;
  3. build and install x11-drivers/xf86-video-ati or x11-drivers/xf86-video-intel too: they are patched to load the *_port.ko kernel driver;
  4. If you already have *kms.ko loaded, reboot.

Then try your usual workload, movies, games, suspend/resume, etc. and tell us how it goes!

When this works, we can get rid of Mesa 9.1 and move forward with Mesa 10.x and xserver 1.17+.

Unifying Mesa ports’ configure

To minimize the time to build each Mesa port and limit the dependencies, we always configured Mesa with different flags, depending on the port being compiled. For instance, graphics/libEGL was built without Gallium, so it didn’t pull LLVM.

We discovered this strategy produces a non-working Mesa:

  • libEGL is built without the “drm” platform because it is enabled only if Gallium drivers are enabled too. This prevented us from activating glamor support in the X.Org server. We thought it was something too Linux-centric and it made the server crash on FreeBSD but we were wrong: once libEGL is built with the same flags as graphics/dri, everything works out-of-the-box.
  • Likewise with Clover, the OpenCL implementation. Without Gallium drivers, pipeloader modules are not compiled. Therefore, libOpenCL.so is installed but it is non-functional.

Therefore, we are unifying all Mesa ports so they all use the same configure flags and dependencies. This means:

  • The GALLIUM option will be removed and the support for Gallium will turned on for everybody. We do this because building half of Mesa with Gallium and not the other half leads to hard to debug situations.
  • All Mesa ports will depend on LLVM, at least on x86. Fortunately graphics/dri already depends on it with default options and Mesa is useless without it.

This greatly simplifies Mesa ports. Furthermore, as said above, this will allow us to enable glamor in the X.Org server. Glamor is the only 2D acceleration API supported by recent Radeon cards where EXA is not implemented. This feature is included in xserver 1.16+.

Testing the DRM update

The DRM update patch is now ready for review and testing.

Update: the patch was committed to FreeBSD 11-CURRENT as of r280183.

As you can see, the patch is huge and I don’t expect a deep review of it. When I started to work on this, I tried to import some bits here and there. But I ended up porting every DRM files from Linux 3.8 from scratch. Many symbols were renamed (structure names, members, variables, etc.), functions were reordered or moved between files, new helpers and macros were added. The end-result is that the diff with Linux is greatly reduced.

Changes are mostly under-the-hood; the most important ones are described below. Beside a couple Radeon PCI IDs, drivers are largely untouched. Don’t expect Haswell support or Radeon power management in this patch for instance.

Continue reading Testing the DRM update

On the OpenCL front

Koop Mast, Johannes Dieterich and Oliver Hartmann made a lot of progress on OpenCL lately!

A new “opencl” branch was created on GitHub, with several new ports:

  • lang/ocl-icd is an OpenCL ICD loader implementation. It is a libOpenCL.so wrapper who can manage several vendor-specific OpenCL implementations.
  • Four OpenCL implementations are being worked on:
    • Beignet (lang/beignet) is for Intel GPUs.
    • Clover (lang/clover) is for Radeon GPUs; it is part of Mesa.
    • Freeocl (devel/freeocl) and POCL rely on the CPU.
  • lang/clinfo is a simple tool (like glxinfo) who prints information about the OpenCL platform and device.

This is still experimental and can be considered of “alpha” quality. OpenCL headers are provided by several implementations, we need to handle this. Port categories are not even decided yet. But it is promising nonetheless! You can find a more detailed status on the wiki.

Status of the DRM update

The i915 kernel video driver refresh, committed two weeks ago, was enough to finally make Intel GPUs to start working with the update to the DRM device-independent code being prepared.

More than its age, the problem of our DRM kernel subsystem is its inconsistency:

  • The i915 driver matches Linux 3.5.
  • The Radeon driver comes from Linux 3.8.
  • The device-independent code is a mix of the legacy FreeBSD DRM code (sys/dev/drm) and some bits taken from an unknown version of Linux.

This makes updates very difficult to do because none of the drivers are on the same page.

The goal of this project is to bring the DRM device-independent code to Linux 3.8, the same version than the Radeon driver. It’s working well for more than a year, but couldn’t be committed because the i915 driver wouldn’t work with a newer DRM.

Thanks to the i915 update, it is working now, even if the driver only matches Linux 3.5. However, there are still some issues to review and fix:

  • In Linux, there’s a global DRM lock, mostly used during device attach/detach. In FreeBSD, the device lock was used instead. This caused many functions to be changed to avoid recursive locking (because they used the device lock). With the DRM update, I’m restoring the global DRM lock but there are still places where the locking is wrong: I need to review all of them.
  • Another problem is returned error codes. In Linux, they use negative integers. In FreeBSD, functions were modified to use positive integers. To reduce the diff, I’m restoring the negative integers inside the DRM subsystem. I just convert them to positive ones at the last moment, when the DRM subsystem interacts with other FreeBSD components. Again, this needs a thorough review.

This work is happenning in my “kms-drm-update-38” branch on GitHub (branched from 11-CURRENT, frequently updated). Only the kernel is relevant, no need to rebuild world. Please test it as much as you can and report back to the freebsd-x11@ mailing-list!

Update to the i915 kernel driver

On Wednesday January 21st, Konstantin Belousov committed a first batch of updates to the i915 kernel video driver. Several fixes followed the initial commit.

His work brings the driver more closer to Linux 3.5 and thus includes several bug fixes and improvements to the support of generations up through Ivy Bridge. However, Haswell and later generations are not supported yet: this will come at a later time.

Among the bugs fixed, the most annoying for users were:

  • Broken OpenGL applications (crashes, garbaged display) after one or more suspend/resume cycles. This regression appeared after the addition of hardware contexts support.
  • Backlight support which was non-functional for some people. The feedback seems positive now.

Furthermore, this driver refresh allows Jean-Sébastien Pédron to move forward with the DRM update work-in-progress. Another article will be posted on that topic.

AGP support is back

Since the introduction of the Radeon kernel driver, only PCI and PCIe discrete cards were supported. AGP cards owners were out of luck, because I didn’t have neither the time, the knowledge nor the hardware to work on it.

Thanks to the work of Tijl Coosemans (tijl@), both FreeBSD 11-CURRENT and 10-STABLE (ie. what will become 10.2-RELEASE, next year) now support Radeon AGP cards!

He had to add missing APIs to our agp(4) driver. Those functions are required by the TTM memory manager which Tijl modified as well. Like GEM, TTM is a DRM component responsible for:

  • managing system and video memory;
  • moving data between these two memories;
  • mapping and paging data;
  • swapping pages.

Here is what Tijl says:

The Accelerated Graphics Port was the motherboard connector used for graphics cards before PCI Express became popular. Support for Radeon AGP cards in the radeonkms driver has now been ported to FreeBSD and is available in stable/10 and head.

The performance of the agp(4) driver has been improved as well. It regularly flushed all CPU caches to main memory which was a very costly operation.