Re: drm-next update and longer term plans

On Fri., 2 Dec. 2016 at 6:25 am, 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
>
> _______________________________________________
> freebsd-x11_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe_at_freebsd.org"
>

Hi Matthew / others,

Thanks for your work - I sincerely appreciate every minute of your personal
time spent on this.

What are your thoughts on whether this is ready for committing to
12-current, with plenty of time for polishing before it makes it into a
release?

Regards,
Ben