R9 380 is one of the VI parts which is already enabled by default in upstream amdgpu.
Not sure where the idea about community porting GCN 1.1 came from, that code has been upstream for months. The only question is GCN 1.0 since we haven't finalized whether to support that with amdgpu or radeon, so in the meantime people are writing "OMG what if they never support it ?" stories to get traffic.
The only issue under discussion is that we are in the middle of a Linux kernel driver transition (moving from the closed-source Vulkan driver and open source radeon driver to a new amdgpu kernel driver) and the question we haven't answered yet (very few announcements are happening until the Vulkan embargo NDA lifts) is which kernel driver the Vulkan driver will use on early GCN hardware.
Let's try that again without the copy/paste typos:
Um... what exactly pisses you off ? We will be supporting Vulkan on your hardware, and amdgpu support for GCN 1.1 is already upstream.
GCN 1.1 support in amdgpu is disabled by default at the moment because that hardware is already supported by radeon and changing the default right now will break user systems. We need to wait until userspace code with the ability to work over either driver makes its way out to most of the user systems (which means going through at least a round of consumer distro release cycles), so that picking up a kernel with amdgpu enabled for pre-VI doesn't make your system stop working.
Catalyst-style deployment where userspace and kernel driver come as a set are not affected by upstream defaults and don't have to wait.
Um... what exactly pisses you off ? We're going to be supporting Vulkan on your hardware, and amdgpu support for your hardware is already upstream in amdgpu.
Support for GCN 1.1 in amdgpu is already upstream and has been for a while; it's just disabled by default because that hardware is already supported by radeon and we don't have the option to change that default until suitable userspace code (eg Mesa) has made its way out to most user systems so that existing systems don't break.
Missed a bit - the reason VI is the first family enabled by default in amdgpu is that we already had upstream support for SI and CI in the radeon kernel driver, and Linux kernel rules are really strict about not breaking userspace by removing or disabling user/kernel interfaces after they have gone upstream... so we can't just disable the radeon code as soon as we have amdgpu code upstream.
GCN 1.1 is missing nothing, so tell your Kaveri to be happy.
We already have upstream support for KV and the other GCN 1.1 parts in amdgpu, it's just not enabled by default yet, and can't be until the userspace has been available long enough to make sure we can cut over without new kernel builds breaking existing systems:
The only question that's not fully settled is what we do for SI - extend the libdrm-amdgpu userspace library to use radeon kernel driver IOCTLs, or port the SI code from the radeon kernel driver to the amdgpu kernel driver. We have been looking at both options in parallel with developing the Vulkan userspace.
AFAIK the microcode images can be downloaded directly from Alex's radeon_ucode folder on freedesktop.org (folder above is for 285/380/380X), but once folks come back from vacations I'll ask about packages that can take care of the install details.
The only "quick solution" I can think of would be if AMD hosted your own repository that one could add to the sources. It would still be non-free but one would not have to add the whole non-free repo from the distro, and still know the blobs are from AMD.
That's an interesting idea, will look into it. Thanks !
I would perhaps consider the border of when its OK and not OK to be if you can change the code or not. That is also the reason Im not sure about the VBIOS part.
I don't want you to the get wrong picture. Its great that the microcode can get updated. But its more of an ethical question.
Yep, the ability to update the microcode is often used as a criteria for whether something is "software" or not, but following that line of thought quickly leads to what I think everyone agrees are counter-productive conclusions. For example:
1. Burning microcode into the chip is OK, and we promote use of those chips when accompanied with free drivers even if the microcode is not free
2. Making the microcode upgradable (which helps us) is even better, but we explicitly prohibit use of those chips unless the microcode is also free, even if the drivers are completely free except for loading the microcode
3. Even though microcode changes are normally made only during pre-launch development or in order to SUPPORT the development of free drivers we penalize users of that hardware because the microcode COULD be changed
4. Even if we put controls in the driver code to prevent changes to the microcode (eg validating a hash) so that the microcode can never change we still penalize users of that hardware, even though we think changeable microcode is otherwise better
5. If the microcode were distributed in the VBIOS ROM the libre OS builds would allow full, accelerated use of that hardware because the drivers could then be considered totally free, despite the microcode still being changeable and the drivers being otherwise identical, but we don't want to make exceptions for that exact same microcode/driver combination in the distros themselves
(in fairness the decision to lump all microcode and firmware into a single repo was made upstream in Debian not downstream in the libre OSes)
(removing quote for clarity) Nope, I understand completely and you said it very well (better than I was doing). The problem is arguably as simple as "guilt by association"... ie in order to let the drivers load microcode that is distributed in hardware or flash on competing products you need to use an OS mechanism which also allows the use of other, obviously more problematic "firmware" blobs which clearly do perform functions that would otherwise be implemented in the driver. I don't know if there is a solution in there but if nothing else it might help to explain to board vendors why people care about not having to ship the microcode images as part of the "software". Thanks.
>>Hope you understand what Im trying to say. Im sure I sound like a negative and pessimistic jerk but Im really not.
Nope, I understand completely and you said it very well (better than I was doing). The problem is arguably as simple as "guilt by association"... ie in order to let the drivers load microcode that is distributed in hardware or flash on competing products you need to use an OS mechanism which also allows the use of other, obviously more problematic "firmware" blobs which clearly do perform functions that would otherwise be implemented in the driver.
I don't know if there is a solution in there but if nothing else it might help to explain to board vendors why people care about not having to ship the microcode images as part of the "software". Thanks.
Sorry, realized I hadn't been logging in or identifying myself as an AMD-er. So now I have an account.
It's funny, for such a technical site the account setup questions list a lot of management positions but nothing for the technical side. AFAIK most tech companies these days have parallel management and technical tracks, don't they ?
Slashdot Mirror
Vulkan is being released first as closed source then open source, but open source should support at least the same hardware as the closed source did.
R9 380 is one of the VI parts which is already enabled by default in upstream amdgpu.
Not sure where the idea about community porting GCN 1.1 came from, that code has been upstream for months. The only question is GCN 1.0 since we haven't finalized whether to support that with amdgpu or radeon, so in the meantime people are writing "OMG what if they never support it ?" stories to get traffic.
Why the sad face ? Vulkan will run on both.
R9 390 and R9 290 are both based on Hawaii, while R9 380 and R9 285 are both based on Tonga.
R9 380 is Tonga (what we call GCN 3 and the media calls GCN 1.2). R9 290 is Hawaii, which is GCN2.
What fragmentation are you talking about ? The Vulkan driver will be exactly the same on all of our hardware.
https://twitter.com/grahamsellers/status/688126936648790016
The only issue under discussion is that we are in the middle of a Linux kernel driver transition (moving from the closed-source Vulkan driver and open source radeon driver to a new amdgpu kernel driver) and the question we haven't answered yet (very few announcements are happening until the Vulkan embargo NDA lifts) is which kernel driver the Vulkan driver will use on early GCN hardware.
Let's try that again without the copy/paste typos: Um... what exactly pisses you off ? We will be supporting Vulkan on your hardware, and amdgpu support for GCN 1.1 is already upstream.
GCN 1.1 support in amdgpu is disabled by default at the moment because that hardware is already supported by radeon and changing the default right now will break user systems. We need to wait until userspace code with the ability to work over either driver makes its way out to most of the user systems (which means going through at least a round of consumer distro release cycles), so that picking up a kernel with amdgpu enabled for pre-VI doesn't make your system stop working.
Catalyst-style deployment where userspace and kernel driver come as a set are not affected by upstream defaults and don't have to wait.
Um... what exactly pisses you off ? We're going to be supporting Vulkan on your hardware, and amdgpu support for your hardware is already upstream in amdgpu.
Support for GCN 1.1 in amdgpu is already upstream and has been for a while; it's just disabled by default because that hardware is already supported by radeon and we don't have the option to change that default until suitable userspace code (eg Mesa) has made its way out to most user systems so that existing systems don't break.
It is actually Vulkan with a 'k' in this case:
https://www.khronos.org/vulkan
Missed a bit - the reason VI is the first family enabled by default in amdgpu is that we already had upstream support for SI and CI in the radeon kernel driver, and Linux kernel rules are really strict about not breaking userspace by removing or disabling user/kernel interfaces after they have gone upstream... so we can't just disable the radeon code as soon as we have amdgpu code upstream.
GCN 1.1 is missing nothing, so tell your Kaveri to be happy.
We already have upstream support for KV and the other GCN 1.1 parts in amdgpu, it's just not enabled by default yet, and can't be until the userspace has been available long enough to make sure we can cut over without new kernel builds breaking existing systems:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/Kconfig
The only question that's not fully settled is what we do for SI - extend the libdrm-amdgpu userspace library to use radeon kernel driver IOCTLs, or port the SI code from the radeon kernel driver to the amdgpu kernel driver. We have been looking at both options in parallel with developing the Vulkan userspace.
http://people.freedesktop.org/~agd5f/radeon_ucode/tonga/
AFAIK the microcode images can be downloaded directly from Alex's radeon_ucode folder on freedesktop.org (folder above is for 285/380/380X), but once folks come back from vacations I'll ask about packages that can take care of the install details.
The only "quick solution" I can think of would be if AMD hosted your own repository that one could add to the sources. It would still be non-free but one would not have to add the whole non-free repo from the distro, and still know the blobs are from AMD.
That's an interesting idea, will look into it. Thanks !
I would perhaps consider the border of when its OK and not OK to be if you can change the code or not. That is also the reason Im not sure about the VBIOS part.
I don't want you to the get wrong picture. Its great that the microcode can get updated. But its more of an ethical question.
Yep, the ability to update the microcode is often used as a criteria for whether something is "software" or not, but following that line of thought quickly leads to what I think everyone agrees are counter-productive conclusions. For example:
1. Burning microcode into the chip is OK, and we promote use of those chips when accompanied with free drivers even if the microcode is not free
2. Making the microcode upgradable (which helps us) is even better, but we explicitly prohibit use of those chips unless the microcode is also free, even if the drivers are completely free except for loading the microcode
3. Even though microcode changes are normally made only during pre-launch development or in order to SUPPORT the development of free drivers we penalize users of that hardware because the microcode COULD be changed
4. Even if we put controls in the driver code to prevent changes to the microcode (eg validating a hash) so that the microcode can never change we still penalize users of that hardware, even though we think changeable microcode is otherwise better
5. If the microcode were distributed in the VBIOS ROM the libre OS builds would allow full, accelerated use of that hardware because the drivers could then be considered totally free, despite the microcode still being changeable and the drivers being otherwise identical, but we don't want to make exceptions for that exact same microcode/driver combination in the distros themselves
(in fairness the decision to lump all microcode and firmware into a single repo was made upstream in Debian not downstream in the libre OSes)
(removing quote for clarity) Nope, I understand completely and you said it very well (better than I was doing). The problem is arguably as simple as "guilt by association"... ie in order to let the drivers load microcode that is distributed in hardware or flash on competing products you need to use an OS mechanism which also allows the use of other, obviously more problematic "firmware" blobs which clearly do perform functions that would otherwise be implemented in the driver. I don't know if there is a solution in there but if nothing else it might help to explain to board vendors why people care about not having to ship the microcode images as part of the "software". Thanks.
>>Hope you understand what Im trying to say. Im sure I sound like a negative and pessimistic jerk but Im really not. Nope, I understand completely and you said it very well (better than I was doing). The problem is arguably as simple as "guilt by association"... ie in order to let the drivers load microcode that is distributed in hardware or flash on competing products you need to use an OS mechanism which also allows the use of other, obviously more problematic "firmware" blobs which clearly do perform functions that would otherwise be implemented in the driver. I don't know if there is a solution in there but if nothing else it might help to explain to board vendors why people care about not having to ship the microcode images as part of the "software". Thanks.
Sorry, realized I hadn't been logging in or identifying myself as an AMD-er. So now I have an account. It's funny, for such a technical site the account setup questions list a lot of management positions but nothing for the technical side. AFAIK most tech companies these days have parallel management and technical tracks, don't they ?