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

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

[Alexandre Demers]

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sellers, Graham]

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. :)

Graham

-----Original Message-----
From: Alexandre Demers [mailto:alexandre.f.demers@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Deucher, Alexander]

> -----Original Message-----
> From: Sellers, Graham
> Sent: Monday, January 18, 2016 10:38 AM
> To: alexandre.f.demers@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@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Christian König]

> 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@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@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@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@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@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Alexandre Demers]

As a follow up, I've been away for quite some time now (long overdue 
vacations), but I'm back home now. This will be my main project, so we 
may get something working if I'm lucky. I'll soon be posting a link to 
my repository where things will be worked on.

Cheers.

Alexandre Demers

On 2016-01-20 20:21, Alexandre Demers wrote:
> 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@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@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@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel