Category Archives: mesa

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.