> -----Original Message----- > From: Luke A. Guest [mailto:laguest@xxxxxxxxxxx] > Sent: Monday, December 12, 2016 11:17 AM > To: Deucher, Alexander; 'Daniel Vetter'; Bridgman, John > Cc: Grodzovsky, Andrey; Cheng, Tony; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; dri- > devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU > > On 12/12/16 15:28, Deucher, Alexander wrote: > >> -----Original Message----- > >> From: amd-gfx [mailto:amd-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On > Behalf > >> Of Daniel Vetter > >> Sent: Monday, December 12, 2016 4:27 AM > >> To: Bridgman, John > >> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-devel@xxxxxxxxxxxxxxxxxxxxx; > amd- > >> gfx@xxxxxxxxxxxxxxxxxxxxx; 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. > > > > > Apologies for spamming, but I didn't send this to all. > > 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. The kernel side is public. The dkms packages have the full source tree. As I said before, we plan to make this all public, but just haven't had the time (as this thread shows, we've got a lot of other higher priority things on our plate). Even when we do, it doesn’t change the fact that the patches can't go upstream at the moment so it doesn't fix the situation Daniel was talking about anyway. Distro's generally don't take code that is not upstream yet. While we only validate the dkms packages on the enterprise distros, they should be adaptable to other kernels. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
