Category Archives: mesa

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.

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, 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 was not implemented.

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 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.

Mesa 10.3.0 committed!

Today, Koop Mast committed an update to the Mesa ports to have both 9.1.7 and 10.3.0 available.

What’s new?

Mesa 10.3 brings major improvements in stability and performance, especially for Radeon owners, compared to Mesa 9.1. For instance, it fixes many of the GPU lockups you may see.

With Mesa 10.3.0 comes a new port as well: graphics/gbm. This buffer management library is used by other components inside and outside Mesa, such as:

  • GLAMOR, the 2D acceleration API based on OpenGL, used by at least newer Radeon cards;
  • Weston, the reference compositor from the Wayland project;
  • Clover, the OpenCL library in Mesa.

Beside those components, the X.Org server 1.15 requires Mesa 9.2+ too.

Only for FreeBSD 10.1+

We still need Mesa 9.1.7 because our Intel i915 driver in FreeBSD 9.x and FreeBSD 10.0 lacks a feature called “HW context“. This feature allows the switch between multiple OpenGL contexts without having to resend them to the card after each switch. Mesa 9.2 and later versions require this. That’s why Mesa 10.3.0 can’t be used on FreeBSD 9.x or 10.0.

However, FreeBSD 10.1 and 11-CURRENT have this feature. In this case, Mesa 10.3.0 will be picked automatically.

[CFT] Xorg Upgrade 7.5.2

The Xorg Team is pleased to announce the next round of Xorg updates. First of all, note that this is experimental, so you really have to know what you’re
doing read careful and follow exactly our documentation. We are specifically looking for feedback from Intel, ATI and NVIDIA users, we like to know if we break here
anything. The WITHOUT_NOUVEAU switch is gone along with xf86-video-nouveau, we suggest to switch to the nvidia blob.

KMS Support [1]:
Unfortunately, the intel KMS driver will only work for the latest FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is named all.13.1.patch.
The higher the version the newer the patch is. Other needed patches are already available in the Xorg update.

HEAD Users:
Get the latest patchset from Kib here:

9-STABLE Users:
Meowthink maintanice currently the backport to 9 STABLE, make sure you have the latest FreeBSD 9-STABLE src check out. Get the patch from here:

Rebuild your Kernel and reboot.

Know issuse:
There will be a patch reject in the sys/dev/drm/i915_suspend.c file. The solution is to manually undo the expansion of the $FreeBSD: ….$ tag, so it only
says $FreeBSD$.

Checkout Xorg Development Repo:
You will need to install devel/subversion in order to checkout the xorg repo. Next, you will need to add WITH_NEW_XORG=yes in your /etc/make.conf if you want to try out the
new Xorg and mesa. Note that if you are not qualified for the KMS patch, you shouldn’t use WITH_NEW_XORG=yes because the old intel driver doesn’t build with the new X
server. If you are qualified, you should also set WITH_KMS=yes in /etc/make.conf.

svn co

A small merge script to merge the svn checkout into the real portstree can
be found here:

The script is a modified version of the old kdemerge script. Please set the KDEDIR variable to the path of your ports.

After merging, run one of the following command, depending on which tool you use to manage your installed packages.

portupgrade -af \*
portmaster -a

After installing these, you will have to rebuild all xf86-* ports. We will bump all releated ports during the commit to the portstree.

Our current plan is to let the CFT running until the last weekend of February. We hope to get a lot feedback to solve as many problems as possible.
So please help us to get the best xorg update ever in!

Links: [1]

Happy updating :)

– Miwi

Working on Xorg Stuff!


Well I know I haven’t been writing for a long time but there are always reasons behind it :). Lately I have been busy with my job and personal life, but anyway I’m still alive and I have started working on FreeBSD since a while.

As stated in the subject, why I’m writing today is to talk about FreeBSD Xorg stuff. Personally I have stopped working on it for a long time. The main reason was that we are still stuck on some problems like missing KMS/GEM support, though since a while there is some progress that can be seen. Also kwm@ and eadler@ jumped into the Xorg team and did a lot of good work in the last few months.

As a result, Xorg gets 2 layers of framework. What this means, users with newer GFX hardware will get the chance to use newer Xorg server and drivers. The team has decided to create a new flag called WITH_NEW_XORG that users have to include in /etc/make.conf. This was mainly done for the intel KMS work being done. It should probably work for other chips. Unfortunately, the intel KMS driver will only work on FreeBSD 9-stable or 10-CURRENT users. Older version of FreeBSD will not be supported. Intel users will need to patch their src manually with Kib’s KMS kernel patch to get the newer chips to work. We have libGL and Mesa patches in our xorg-dev repo ready.

Here are some facts on what you will get with WITH_NEW_XORG:

libdrm 2.4.30 (including KMS support)
mesa 7.11.2
xorg-server 1.10.4
a lot of new Graphic Drivers.

After this is done and committed we going to work on Mesa 8.0 and X server 1.12. The reason we haven’t done this yet is because they are in RC stage and x server 1.11 and above break the nvidia driver. We will call for a testing soon with the full instruction on what you will have to do. So keep your eyes open..

So long…

PS: follow me on Twitter here.