NOTE: All enabling patches were committed to HEAD as of r235859 and to RELENG_9 as of r236969.

What is this ? The required kernel-mode support to run the recent usermode ddx and mesa drivers for Intel GPUs. Initial goal is to have gen4-gen6 (and gen7 AKA IvyBridge, when available) hardware support. Gen2 and gen3 will be best efforts. See http://en.wikipedia.org/wiki/Intel_GMA for the useful table with the information about the hardware, generations and marketing nicks. The driver can be somewhat frivolously separated into the execution and memory manager (GEM) and modesetting (KMS) parts. Due to quite intimate relations of GEM with the VM subsystem, some updates to our VM are needed, which are included in the patch.

Large parts of the code were taken from the Intel GPU driver in the Linux kernel, which is licensed under the BSD-like Intel opensource license. The i2c bus access code is converted to our iic(4) framework, which need an eye from newbus and iic gurus. agp_i810(4) has been reworked to add required generic support for the Intel GTT.

Required usermode components are available in the ports tree, you need to add WITH_NEW_XORG=true and WITH_KMS=true to /etc/make.conf.

Or, for the latest development versions of the usermode stack, get

  1. dri2proto from git head, git://anongit.freedesktop.org/xorg/proto/dri2proto
  2. glproto from git head, git://anongit.freedesktop.org/xorg/proto/glproto
  3. libdrm from git head, git://anongit.freedesktop.org/mesa/drm. You need to apply the patch http://people.freebsd.org/~kib/drm/libdrm.2.patch to get KMS.
  4. intel ddx driver from git head, git://anongit.freedesktop.org/xorg/driver/xf86-video-intel
  5. Mesa from git head, git://anongit.freedesktop.org/mesa/mesa. I configured the library as
CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib FLEX=/usr/local/bin/flex BISON=/usr/local/bin/bison ./configure --enable-dri --disable-xlib-glx --with-dri-drivers=i915,i965,swrast --disable-gallium-llvm --disable-gallium-egl --with-gallium-drivers="" --enable-texture-float

Obviously, you need to have textproc/flex and devel/bison installed, flex from the base would not work.

Since the syscons is not integrated with KMS, screen goes blank after i915kms is loaded. Use startx to let ddx driver load the right kernel module. Set sysctl hw.dri.debug=0 to reduce verbosity of the driver at runtime.

You must have the serial console to catch debugging output and panics. GEM does useful tracing during the operation that is required to analyze the actions causing the problems. See ktr(4), GEM uses KTR_DEV event mask. Enable witness.

The current state of the driver is reported by sysctl tree at hw.dri.0.info. In the case of GPU hang or error, the GPU dump is available at hw.dri.0.info.i915_error_state.

hw.dri.debug sysctl, also available as dri.debug tunable, controls the driver verbosity:

  1. bit 0 when set, enables the drm debugging output (very verbose)
  2. bit 1 when set, enables the KMS debugging messages
  3. bit 2 when set, reports any ioctl that failed

Any bug report, to be useful, should include:

  1. pciconf -lvb output
  2. kernel messages, for modesetting problems, include the kernel messages with hw.dri.debug bit 1 set.
  3. full panic message and ddb backtrace, if any
  4. Ktr trace from the execution with KTR_DEV enabled. See ktr(4) on how to obtain it from core dump or live system.
  5. in the case of GPU hang, the content of i915_error_state sysctl.

FAQ (yes, I already tired of some questions)

  1. Do you plan to port TTM ?

Not in the scope of this project, but see AMD_GPU

  1. Does KMS work will ease the future porting of the KMS code for non-Intel drivers ?

Some parts of the updated DRM infrastructure was ported during the course of porting Intel driver. In particular, the precise vblank timestamp handling, EDID parsing, generic crt handling code, and updated DRM block memory allocator. Also, the working locking model was developed for the i915, that can be reused by other drivers.

Multi-master code was not ported, I spent a week on it and abandoned the efforts due to a lot more time required, putting the final date of the project on risk. The Intel driver was instead adopted to our drm.

That said, the KMS itself is very card specific and the core of efforts for each driver is driver-specific.

  1. How Linux changes are handled ?

I manually review the Linux commit log for drm and apply the applicable changes. No, this cannot be automated. See above notes about VM integration, iic framework, different version of drm core. Jeff Roberson' Linux compatibility layer was useful for initial evaluation of the driver, but I decided against using it, since most troubles were expected in interfaces that are not easily wrapped. Some additional infrastructure code, like delayed taskqueues, was developed for FreeBSD instead.

  1. I cannot switch back to the text console. Or, immediately after loading the driver, the console went black.

The VT switching code is not implemented (yet). In fact, the real cause is that driver turns on modesetting right after the load. This way, it is easier for me to test the driver. Eventually, this will be changed.

  1. The system panics upon “kldunload i915kms”

At present the module cannot be unloaded. See http://lists.freebsd.org/pipermail/freebsd-current/2012-June/034563.html for details.