4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported
mmacy at nextbsd.org
Sun May 22 07:20:39 UTC 2016
I'm happy to announce a call for testers for the 4.6 update of drm and
i915. The driver has been successfully tested on IvyBridge, Haswell,
Broadwell and Skylake. At least basic HW 3D acceleration should work,
VGA and DP out are known to work. Video decode has only been tried
once and that did not work.
At this point I'm most interested in taking an inventory of what is
broken where. My priorities are common sense:
b) fixing 2D artifacts
c) fixing 3D problems
d) video decode
d) output support
e) other features
At this time "prime" (needed for switching between GPUs, compute
APIs, and DRI3) is not yet supported. All the pieces are in place but
support existing functionality is a higher priority. Userptr (mapping
user memory in to the driver) requires VM changes. Support is
planned, but likely post-11.
A few caveats are in order:
- The only reported test on Sandy Bridge indicated severe artifacts.
- Arrandale (pre-Sandy Bridge) and earlier are not yet supported by
this update. The intel_i810 code has been heavily localized for
FreeBSD making it more difficult to integrate. Thus there are
holes in the gmch support.
- This update is 64-bit only. There is no good reason to be running
in 32-bit mode on any of the hardware supported by this driver.
- Although it works fine for me on my Skylake the one other tester
I have reports from indicates that the driver isn't actually
attaching and creating aliases for the drm device nodes.
Please send issue/success reports to the freebsd-x11 mailing list.
I may be preoccupied with work matters for periods of time. Sending
it to the list makes sure that the messages don't get lost.
If you encounter problems with startx, please try loading the i915
kmod in isolation and make sure that it switches correctly to vt_fb.
If you're not running efifb you'll notice a change in resolution.
If it works but is slow or has artifacts you may try switching to
UXA by removing /etc/X11/xorg.conf.d/20-intel.conf (if you're using
the USB image). If you've built from source, try configuring SNA
instead. SNA is much better behaved for me.
The usual rules apply for kernel debugging. There should be copious
information on that in the handbook and elsewhere. If that proves
to be problematic for people I will send out a follow up mail.
A couple observations:
- The FreeBSD PTB insist that a debugger be in tree but that it
pre-date GPL2, consequently kernels are, by default compiled with
DWARF2 which is very poor at retain debug information in the
presence of any optimization. If this is a problem, either
recompile everything with -O0 (add CFLAGS += -O0 in drm2 and
i915kms Makefiles, and pass COPTFLAGS=-O0 to buildkernel) or
install a newer kgdb from ports.
- The purpose of encrypted swap is that the data on disk be
unrecoverable. This is somewhat at cross purposes with savecore.
So don't do that.
Now that this is out I will be switching gears to bringing up amdgpu
and radeon support. I have no hardware that uses the radeon driver
so I will have to rely on Jean for testing and support there.
Those of you wishing to try your hand at testing from source can
fetch our repo from github at:
Make sure to check out the drm-next-4.6 branch.
If you'd rather just try it on a usb pen driver you can also
obtain a prebuilt memstick image with this branch installed
along with xorg and some commonly used ports at:
There is no root password and the user/pw is joeuser/joeuser.
If you're curious about what's on it, the script used to
create the image is here:
If you'd like to help out with collecting data on what
laptops are supported please run Warren Block's
It's also installed under /usr/local/bin on the image.
If I've missed anything please let me know and I will follow up.
More information about the freebsd-x11