4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

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: 

a) stability 
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: 


https://github.com/iotamudelta/freebsd-base-graphics 

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: 

http://www.bsddesktop.com/images/disk_YYMMDDHH.img.xz 

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: 

http://www.bsddesktop.com/images/usbcreate.sh 


If you'd like to help out with collecting data on what 
laptops are supported please run Warren Block's 
notebookstats script: 

http://www.bsddesktop.com/images/notebookstats 

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. 

-M