diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml b/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml index 3ebcc1db65..6b19fa555d 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml @@ -1099,4 +1099,73 @@ The &os; Foundation + + + The Graphics Stack on &os; + + + + &os; Graphics Team + FreeBSD-x11@FreeBSD.org + + + + + Matthew + Macy + + mmacy@nextbsd.org + + + + + Graphics Stack Roadmap and Supported Hardware Matrix + GitHub Repository + Ports Development Repository + Fork of libudevd-devd Shim + Graphics Team Blog + + + +

Good progress on graphics support was made during the weeks + around Christmas and the new year with the import of Linux's 4.9 + DRM for i915 and amdgpu into the drm-next + branch of the github repository. The amdgpu KMS + driver is already somewhat usable, with a few major known issues + remaining. It now supports GPUs as far back as Southern Islands + and up to Polaris. The 4.9 update also appears to have fixed a + regression in i915 that was introduced by the 4.8 merge + late this past summer. The drm-next branch now supports the + Intel integrated graphics unit up to Kaby Lake CPUs. To + facilitate out-of-the-box support on CURRENT, most of the + branch-local VM changes were reverted and the graphics fault + routines converted to use pg_populate. This new interface is the + source of a couple of regressions causing panics on i915 and + severe artifacts with amdgpu on integrated GPUs. Mark Johnston + (markj@) has volunteered to analyze these issues. Please show + your support and encouragement to Mark for helping to move this + project towards the finish line.

+ +

The xserver-mesa-next-udev branch was created for the ports + development repository, and holds Mesa 13.0 and fixes for + newer AMD GPUs. It uses a fork of the libudev-devd shim, also + bringing Mesa closer to Linux upstream. I plan to keep + updating drm and amdgpu (for use on my + desktop and potentially longer term for GPGPU computations) as + well as work with Mark to address the existing bugs in + i915 (assuming that two new porters are approved). + However, the Linux i915 developers seems to + aggressively explore the space of possible implementations and + use of Linux internal APIs, making it prohibitively time + consuming to track upstream. I am helping someone to learn the + ropes of how to replay a subset of changes from a Linux + release into &os; in the hope that he will take over the + mantle of drm-next i915 maintainer. Assuming the + issues listed above are addressed, a port of the linuxkpi, + DRM, and KMS drivers for use on standard amd64 CURRENT + installations is planned. Together with upgrades to the + relevant graphics ports, this will provide experimental + support for new AMD and Intel GPUs.

+ +