Date: Thu, 01 Dec 2016 23:37:46 +0000 From: Ben Woods <woodsb02@gmail.com> To: Matthew Macy <mmacy@nextbsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org> Subject: Re: drm-next update and longer term plans Message-ID: <CAOc73CC2yoyq3xDQNZgHkQq=ijuX5KmuyHAT38kx8z69b8b44w@mail.gmail.com> In-Reply-To: <158bc7db990.e5ab7400189889.2067341649206744373@nextbsd.org> References: <158bc7db990.e5ab7400189889.2067341649206744373@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri., 2 Dec. 2016 at 6:25 am, Matthew Macy <mmacy@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOc73CC2yoyq3xDQNZgHkQq=ijuX5KmuyHAT38kx8z69b8b44w>