Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver

[Alexandre Demers]

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
>