The Experimental GCN 1.0 GPU Support Might Be Dropped From AMDGPU Linux Driver

[ermo]

As has been stated every time UVD and VCE on SI parts gets brought up, you can use the same firmware from radeon with amdgpu. The only difference is you need to rearrange to the internal address space so that vram is put at 0 in the internal address space the same way radeon does it. The only downside to that is that SI would be an outlier because we use the same memory config on all the other asics. The only reason we brought up new firmware at the time was because it would have been nice to use the same memory layout for all asics supported by amdgpu. It's not a hard requirement. There's no secret information required; there is already working support available in radeon that can be used as a guide. It's just a matter of porting the code. The driver is open source. Patches are welcome. If some one wanted to port the UVD support from radeon to amdgpu, we'd certainly help review the patches. radeon is a fully featured driver that the supports all the functionality of the asic. Someone could also add support for radeon to vulkan rather than porting the remaining features from radeon to amdgpu.

I'm not a graphics/kernel developer and currently do not see myself devoting the resources to become one. However, I would be fine with funding a competent developer to do the work on my -- and other GCN1.0 users' -- behalf.

Bearing that in mind, if I were to ask you for your thoughts on what would make the most sense from a design and maintenance perspective, what would you suggest? Which would be the cleaner, more manageable solution going forward?

(a) Port code from the radeon kernel module to the amdgpu module to support UVD and VCE on SI parts,

OR

(b) Add support for Vulkan on top of the radeon kernel module in RADV

[agd5f]

My understanding is something like in order to get vulkan working on radeon, then amdgpu's winsys needs to be ported to radeon and that seems way too difficult. If it's so simple to get UVD working by rearranging address spaces for GCN1 on amdgpu, that's obviously the simpler option than porting amdgpu's winsys to radeon.

I would disagree with your assessment. I think it will be harder to get the kernel side ported and stable in general than to add support for radeon to vulkan.

[chithanh]

As someone who cannot use amdgpu on HAWAII (GCN2) due to incompatibility with AMD SME (something which AMD has so far not indicated it plans to address), I would welcome if the radeon driver and Vulkan started working together.

Also that might pave the way for Vulkan on VLIW4 hardware, I think airlied made a comment some time back that this would be possible in principle.

radeon is a fully featured driver that the supports all the functionality of the asic.

Is that so? Why is it possible to use amdkfd with amdgpu but not with radeon then?

[agd5f]

Why is it possible to use amdkfd with amdgpu but not with radeon then?

amdkfd has never supported SI parts. SI lacks the necessary hardware (user mode queues) to support KFD/ROCm.

[ermo]

I would disagree with your assessment. I think it will be harder to get the kernel side ported and stable in general than to add support for radeon to vulkan.

I guess that answers my question, thanks.

[chithanh]

amdkfd has never supported SI parts. SI lacks the necessary hardware (user mode queues) to support KFD/ROCm.

But amdgpu+amdkfd works on CI parts, while radeon+amdkfd doesn't. Or was that comment about radeon being fully featured specific to SI?

[agd5f]

But amdgpu+amdkfd works on CI parts, while radeon+amdkfd doesn't. Or was that comment about radeon being fully featured specific to SI?

Specific to SI.

[agd5f]

I guess that answers my question, thanks.

Yes. The kernel driver handles the majority of the interactions with the hardware (interrupts, displays, power management, engine init, etc.). Getting all of that ported over and stable and tested on a wide variety of hardware is a huge amount of work. In the case of mesa, the user mode driver is building state packets which will be the same regardless of the underlying kernel driver (e.g., radeonsi does this already). The winsys is just a wrapper around the ioctl interfaces provided by each driver. The ioctls are pretty similar since amdgpu evolved from radeon. That's not to say it's trivial. amdgpu has a number of changes to the ioctl interface that make it easier to implement vulkan support. That said, in my opinion, tweaking some things around the edged to make the ioctls work for vulkan is a much smaller lift than porting the entire driver init sequence over to amdgpu and then making it stable (e.g., clocking, suspend/resume, etc.) on a wide variety of hardware.

[ermo]

Yes.
(...)
in my opinion, tweaking some things around the edged to make the ioctls work for vulkan is a much smaller lift than porting the entire driver init sequence over to amdgpu and then making it stable (e.g., clocking, suspend/resume, etc.) on a wide variety of hardware.

If you were me, who would you approach about such a "lift"?

I'd be willing to attempt to do some of the monkey work if I had access to a (set of) mesa/RADV developer(s) who would be willing to guide and mentor me. The goal would only be to make it more interesting/worthwhile for proper mesa devs to finish off the tricky/fun bits.

I'd also caution that I'd be asking a lot of stupid questions since I'm basically woefully underqualified for this kind of work; but giving it an honest try is at least better than the status quo.

And if anyone else is following along: I'm just some random guy on the internet wondering how to approach this and get the ball rolling.

[agd5f]

If you were me, who would you approach about such a "lift"?

I'd be willing to attempt to do some of the monkey work if I had access to a (set of) mesa/RADV developer(s) who would be willing to guide and mentor me. The goal would only be to make it more interesting/worthwhile for proper mesa devs to finish off the tricky/fun bits.

I'd also caution that I'd be asking a lot of stupid questions since I'm basically woefully underqualified for this kind of work; but giving it an honest try is at least better than the status quo.

And if anyone else is following along: I'm just some random guy on the internet wondering how to approach this and get the ball rolling.

Developers are regularly on #radeon and #dri-devel on freenode IRC. Start with radeonsi and take a look at the radeon and amdgpu winsys backends and get familiar with them. Use them as a reference to implement the relevant support in radv.