[RFC] Using DC in amdgpu for upcoming GPU

[Luke A. Guest]

On 12/12/16 15:28, Deucher, Alexander wrote:
>> -----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.
>

What Daniel said is something I've said to you before, especially
regarding libdrm. You keep mentioning these patches you need, but tbh,
there's no reason why these patches cannot be in patchwork so people can
use them. I've asked for this for months and the response was,
"shouldn't be a problem, but I won't get to it this week," months later,
still not there.

Please just get your stuff public so the people who aren't on enterprise
and ancient OSes can upgrade their systems. This would enable me to test
amdgpu-pro and latest Mesa/LLVM alongside each other for Gentoo without
having to replace a source built libdrm with your ancient one.

Luke.