Thanks to all your feedback. Well, it seems achievable. I may ask some questions here and there, but I think I'll give it a try.
Alexandre Demers On 2016-01-19 07:58, Christian König wrote: >> I think Graham summed it up pretty well :) > Indeed, but there is a detail missing. The main problem for moving SI > and CIK support from radeon to amdgpu is that we can't break existing > userspace. > > Fortunately amdgpu wasn't designed from scratch, instead it's rather a > evaluational successor of radeon. Because of that a lot of the > internal interfaces are still the same. > > Additional to that I made the IOCTL numbers from Radeon and Amdgpu > intentional disjoint. Amdgpu is using 0x00-0x12 and KMS on Radeon is > using 0x1c-0x2d (we never supported UMS for SI/CIK). > > So in theory it would be possible that somebody implements a > compatibility mode which provides the old Radeon IOCTLs for SI and CIK > hardware generation in Amdgpu. > > This way we could support SI on Amdgpu as well and remove the support > for SI and CIK from Radeon. > > The biggest differences are indeed in the multimedia area, e.g. UVD > and VCE. But it's still mostly copying the Radeon code to Amdgpu (if > somebody cares we could even move that into an independent module > shared by both). > > Regards, > Christian. > > Am 18.01.2016 um 23:19 schrieb Deucher, Alexander: >>> -----Original Message----- >>> From: Sellers, Graham >>> Sent: Monday, January 18, 2016 10:38 AM >>> To: alexandre.f.demers at gmail.com; Deucher, Alexander >>> Cc: dri-devel >>> Subject: RE: Porting GCN pre-1.2 parts from radeon to amdgpu kernel >>> driver >>> >>> Hi Alexandre, >>> >>> Yes, your understanding is correct. >>> >>> Frankly, Alex or one of the other guys on the open source team would be >>> best positioned to answer your questions as to what would >>> specifically need >>> to be done. However, yes, the gap we have here is in the amdgpu kernel >>> driver. I pretty much only work on the user-mode side of things. Think >>> "libVulkan.so" or "vulkan.dll" - the bit that applications link to. >>> We talk to our >>> kernel drivers through standard interfaces. It's the kernel driver >>> that deals >>> with a lot of the differences between different parts of hardware. >>> amdgpu is >>> a ground-up redesign of our kernel solution for Linux. The >>> closed-source >>> kernel driver that we were using in our Catalyst packages has been >>> put out to >>> pasture. For the amdgpu project, given the number of engineers we have, >>> we have to make a tough decision between supporting interesting new >>> features of new GPUs, or sticking with pretty basic support but >>> backporting >>> to older GPUs. >>> >>> The differences in the graphics core itself between SI, CI and VI >>> are actually >>> pretty minimal (as far as the kernel driver is concerned, anyway). >>> Where >>> there are bigger differences are in things like the multimedia >>> (video) engines, >>> display controller, power management and so on. The radeon KMD has full >>> support for all SI and CI (and earlier) "un-core" parts of the GPU. >>> amdgpu has >>> VI product support and some minimal (albeit disabled) support for >>> CI, and >>> basically nothing from SI. >>> >>> Our user-mode Vulkan driver (and closed source OpenGL driver, for that >>> matter) can talk to the amdgpu kernel driver, but not to the radeon >>> kernel >>> driver. The interfaces are quite different, and honestly, the radeon >>> kernel >>> interface isn't a great fit for Vulkan. We had considered trying to >>> support >>> radeon KMD in our Vulkan driver, but it doesn't seem practical. So, >>> it seems >>> that the options would be really to port the non-core support from >>> radeon >>> KMD into amdgpu, or somehow port the new KMD interfaces to radeon >>> KMD, which would allow our Vulkan drivers to run on it, but seems >>> like a bit >>> of a backwards step. >>> >>> There are other complications - such as it being frowned upon to >>> have two >>> kernel drivers for the same piece of hardware, so you'd need to port >>> SI and >>> CI stuff from radeon to amdgpu, and then somehow disable (or remove >>> it) in >>> the radeon KMD such that there was still only one driver for the >>> GPU. It's >>> non-trivial, but not insurmountable. Also, even though the code is >>> there and >>> working in radeon KMD, there are enough differences in the >>> infrastructure >>> that the ported support would need to be re-validated and all that >>> stuff. >>> >>> If you think you're up for the challenge, we'd be appreciative of >>> the input. >>> One of the major reasons to open our code and support open source is to >>> encourage involvement and contributions from the community. That's why >>> we're doing the GPUOpen initiative and we will be opening a lot more >>> of our >>> software in the future. Many of the guys on our open source team >>> initially >>> got involved by contributing to the project before we hired them. >>> That kind >>> of thing looks really good on a resume. :) >> I think Graham summed it up pretty well :) >> >> Alex >> >> >>> Graham >>> >>> -----Original Message----- >>> From: Alexandre Demers [mailto:alexandre.f.demers at gmail.com] >>> Sent: Saturday, January 16, 2016 2:45 PM >>> To: Deucher, Alexander; Sellers, Graham >>> Cc: dri-devel >>> Subject: Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver >>> >>> Hello to both of you, >>> >>> I've been following the development mostly of the radeon driver for >>> some >>> time (with some small commits here and there as you may know). I was >>> waiting to hear some news about the coming support of Vulkan API. And I >>> have been wondering for sometime now if it would be a good think to >>> have >>> all GCN parts moved from the radeon driver to the amdgpu kernel >>> driver (I >>> had figured out it would be possible, but would it be of any use was >>> still >>> unanswered). I was also curious to know if the new Crimson software >>> would >>> support the radeon driver at some point. >>> >>> Now, I may have had a clear answer: I just read from Phoronix' editor >>> Michael Larabel >>> (http://www.phoronix.com/scan.php?page=news_item&px=Help-Bring- >>> Older-GCN-To-AMDGPU) >>> that Vulkan would come to the amdgpu driver only, that the blob (which >>> should eventually be opened) would support all GCN parts and that >>> the only >>> missing part to support GCN pre-1.2 parts with both Vulkan and Crimson >>> would be to have them ported from the radeon driver to the amdgpu >>> driver. >>> Am I understanding correctly? >>> >>> I'd be interested to know a bit more about the task and I may try to >>> start the >>> work or join someone who would already be interested in doing so. >>> >>> Any comments on the matter? Any missunderstood thing? >>> >>> Cheers! >>> >>> -- >>> Alexandre Demers >> _______________________________________________ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >
