[RFC] Using DC in amdgpu for upcoming GPU

[Deucher, Alexander]

> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Monday, December 12, 2016 4:27 AM
> To: Bridgman, John
> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-devel at lists.freedesktop.org; amd-
> gfx at lists.freedesktop.org; Daniel Vetter; Deucher, Alexander; Wentland,
> Harry
> Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
> 
> On Mon, Dec 12, 2016 at 07:54:54AM +0000, Bridgman, John wrote:
> > Yep, good point. We have tended to stay a bit behind bleeding edge
> because our primary tasks so far have been:
> >
> >
> > 1. Support enterprise distros (with old kernels) via the hybrid driver
> > (AMDGPU-PRO), where the closer to upstream we get the more of a gap
> we
> > have to paper over with KCL code
> 
> Hm, I thought resonable enterprise distros roll their drm core forward to
> the very latest upstream fairly often, so it shouldn't be too bad? Fixing
> this completely requires that you upstream your pre-production hw support
> early enough that by the time it ships its the backport is already in a
> realeased enterprise distro upgrade. But then adding bugfixes on top
> should be doable.

The issue is we need DAL/DC for enterprise distros and OEM preloads and, for workstation customers, we need some additional patches that aren't upstream yet because they we don’t have an open source user for them yet.  This gets much easier once we get OCL and VK open sourced.  As for new asic support, unfortunately, they do not often align well with enterprise distros at least for dGPUs (APUs are usually easier since the cycles are longer, dGPUs cycles are very fast).  The other problem with dGPUs is that we often can't release support for new hw or feature too much earlier than launch due to the very competitive dGPU environment in gaming and workstation.

Alex