Re: drm-next update and longer term plans

On Thu, Dec 1, 2016 at 2:25 PM, Matthew Macy <mmacy_at_nextbsd.org> wrote:

> I imagine that for most users the state of graphics support for
> post-Haswell hardware is a bit of a black box so I'm sending out this note
> to let users know what they can and cannot expect.
>
> Wayland has actually become a reality for some. Talk to Johannes Lundberg
> if you're interested in tracking that.
>
> The i915 (Intel integrated GPUs) driver is currently best supported by the
> drm-next-4.7 branch. Broadwell and Skylake support is complete and some
> support came in late in the cycle for Kaby Lake. I can still consistently
> lock up the kernel in the later stages of the piglit test suite, there is
> no backlight support, and suspend/resume do not work on Skylake. The
> drm-next branch is integrated with upstream up through Linux 4.8-rc5 and
> thus has complete support for Kaby Lake, but there is a lockup in i915 that
> occurs some time within an hour of startx. This takes too long for it to
> have shown up in my limited integration smoke testing.
>
> The amdgpu driver is, in terms of KPI dependencies - as far as I can tell
> - a strict superset of the radeon driver. For example, when I tested my one
> older card that uses the radeon driver it manifested the same ttm bugs as
> amdgpu did at that time. Thus, when amdgpu reaches a complete working state
> I expect radeon to largely "just" work. As of this past Sunday amdgpu with
> the amdgpu DDX works with 2D, supports external monitors - selecting the
> appropriate resolution on a per display basis, and backlight works. It will
> also typically panic in ttm within ~90 minutes of startx. Although this is
> huge progress over panicking within 30s of startx (which was the case as of
> Saturday) or not starting at all due to bugs in the libdrm port a few weeks
> prior, it's obviously not something I encourage anyone to use.
>
> My primary motivation for starting with the work is being able to to train
> DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc
> GPU accelerated whilst still running FreeBSD. The Radeon Open Compute stack
> holds out the promise of doing that without using the closed source CUDA
> stack on top of the Linux ABI emulation - which would inevitably be opaque
> and fragile. My plan is to keep on fixing bugs and tracking upstream until
> the first long term branch after ROC support has been integrated in to
> Linux mainline. I have no exact knowledge of when exactly that will be (AMD
> doesn't have sufficient developer resources to make any concrete
> guarantees) but think it should happen by the summer of 2017. I would like
> to think that by that time the i915, amdgpu, and radeon will be feature
> complete and at least as stable as the drm2 support currently in tree.
>
> I need to weigh my soft commitment to make long-term DRM support happen
> with paid work and other activities which are much more important to me
> long term. Thus I've currently committed to spending every Sunday fixing
> bugs in the drm-next branches. Amdgpu is both more important to me and has
> gotten much less attention than i915. Thus I will be devoting my efforts to
> it in the near term. I'd very much welcome efforts by others to triage the
> issues in i915.
>
> Many people ask when drm-next will be available on 11. I am not a
> committer and thus have no direct say in that. However, if you are a
> motivated individual with kernel knowledge you should contact Adrian Chadd.
> There are a few places where I was not able to provide proper linuxkpi
> semantics without making (mostly quite modest) changes to sys/kern. There
> is a general reluctance by some core developers to make changes to
> accommodate Linux. It is possible that, with additional effort, the
> linuxkpi can both be complete enough to avoid needing to port the graphics
> drivers to FreeBSD (something clearly shown by past efforts to be
> unsustainable) and not need to make any kernel changes. If you would like
> to help with that, let Adrian know. In the meantime, TrueOS will continue
> to use my development branches for the benefit of users with newer hardware.
>
> -M
>

Matt,

Thanks for your and your teams work on this. While I am still running on
Sandy Bridge hardware, I am hoping that my next system will be able to run
real X or Wayland without being stuck with VESA formonths, as I was when my
Sandy Bridge system was new. While I understand that this is really a
by-product of you goal, thanks for it.

I really hope that Core understands that unless FreeBSD can run drivers
developed for Linux or required only trivial patches, FreeBSD will always
lag at least months and probably years behind for both graphics and GPU
compute. While Linux does compete with FreeBSD, it is not an enemy. It is
fellow traveler and, when there is no legal reason that Linux code support
can't be accommodated, it should not be dismissed.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman_at_gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683