When crypto prices crash AMD will start caring about the people that held in there keeping them afloat when every one else moved to NVidia and Intel. But then they will claim to be to poor to fix any thing.
Announcement
Collapse
No announcement yet.
Radeon ROCm Updates Documentation Reinforcing Focus On Headless, Non-GUI Workloads
Collapse
X
-
Originally posted by Qaridarium View Post
why not put a RDNA and a CDNA chip on consumer graphic card?
this way people can use graphics and compute at the same time.
to do a chiplet design for RDNA is very hard but if you do hybrid RDNA+CDNA the chiplet design would be very easy.
many people here would not have these problems with using compute and graphics at the same time with a card like this.
so they can use MESA on RDNA and ROCm on the CDNA part.
Comment
-
Originally posted by bridgman View Post
It's the other way round - it means that the ROCm components shipped with AMDGPU-PRO are part of a solution that does officially support both OpenCL and GUI apps.
The messaging about not supporting GUI apps only applies to the ROCm *stack* (see previous post for more specifics), not the individual ROCm *components*.
Comment
-
There was a reddit thread too, in the end they said they are reverting the commit and it was "internal misunderstanding".
- Likes 1
Comment
-
Originally posted by bridgman View Post
In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work,
Comment
-
I am a bit confused with this news. In a recent article here it was mentioned that RDNA2 cards have support for Rocm 4.0 with the included linux driver:
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
I have an old Radeon RX570 polaris and it was as simple as installing the rocm-dev package (on Ubuntu 20.04) to start developing Julia language on GPU applications with Rocm and the AMDGPU.jl Julia package that is the equivalent to CUDA.jl on Julia.
I was pleasantly surprised to find that ROCArrays work great and have almost identical functionality with the CUDA CUArrays on Julia and I was planning to buy a RDNA2 6800 card to do more testing on Julia GPU enabled applications.
But now I am confused, is the Rocm supported on RDNA2 cards or not??
On the official Rocm website says:
"You can install ROCm user-level software without installing AMD’s custom ROCk kernel driver" simply by: "sudo apt install rocm-dev" which is what I did and it worked on my RX570 card. I know these packages are available on a selected number of distributions (Ubuntu LTS, CentOS, SLES etc) but I am not into distro hoping and that is fine with me.
Comment
-
Originally posted by bridgman View Post
There are two parallel activities going on:
#1 - as you might have seen with the inclusion of ROCR-based OpenCL in the 20.45 AMDGPU-PRO packaged drivers, we are working on unifying the stacks so that users do not have to pick and choose between stacks depending on the work they want to do.
The ROCm stack was developed independently at first so we could move more quickly but we are reaching the point where having multiple stacks is no longer a necessity. There is still quite a bit of work to do in order to get everything unified, however.
#2 - in the short term we are trying to beef up the messaging to avoid confusion - the ROCm stack does not include all of the required graphics userspace components at the moment (eg Mesa) and does not go through graphics testing so we want to make that more clear.
The one thing that the messaging does not make clear is that the limitations are mostly related to (a) kernel driver testing and (b) absence of userspace graphics components. In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work, and we want to ramp up testing and documentation in that area over time. We already organize the ROCm packages so that you can install userspace compute components separately from the kernel driver.
The people at BlackMagic, Blender, all the video editor people, all the machine learning lib guys, the GPU-accelerated visualization people (open source and other), they're going to see this and say "ah screw that. AMD doesn't care so there'll be no market. We don't need to spend the dough to support AMD". I'd argue that even some people at Apple will be looking at this and raising an eyebrow, even if they have their own compute stack (which, ironically, is the best way to get compute out of an AMD chip outside of a data centre).
That's the real problem. The messaging is catastrophic. It's almost insane to put this up "currently" wording notwithstanding. The messaging should be "AMD is committed to compute across all market segments", (even if consumer compute is not a priority for now), at least this might keep some devs on board.
Last edited by vegabook; 02 March 2021, 08:18 AM.
- Likes 3
Comment
-
If the ROCr driver included in amdgpu-pro package is released under an open-source license, AMD should really make it as clear and as easy as possible for package maintainers of distributions to ship it as a regular package. Arch even ships Nvidia's blob kernel driver + their closed OpenCL driver, and of course also Intel's open NEO driver. Just AMD is not included (as Clover is not that usable yet and doesn't work at with Navi+ at all so far).
Comment
-
I think they made their messaging perfectly clear. It was clearly an intentional step and pivot. All they will do now is change the verbiage to try to gaslight us but I'm dead sure that internally nothing will change and there'll be business as usual. Meaning ignoring issues, bug reports, responding to people with prepared one line responses etc, more false promises.
It's time to cut our losses and jump ship before it sinks and takes us with it. I'm selling my hw.
I wonder if we all didn't put so much faith in AMD if we could have lobbied Nvidia to release an open source driver by now.
Instead we've put all our eggs in one basket. The basket fell and we ended up with all our eggs broken.
- Likes 2
Comment
-
Originally posted by AresMinos View PostI think they made their messaging perfectly clear. It was clearly an intentional step and pivot. All they will do now is change the verbiage to try to gaslight us but I'm dead sure that internally nothing will change and there'll be business as usual. Meaning ignoring issues, bug reports, responding to people with prepared one line responses etc, more false promises.
It's time to cut our losses and jump ship before it sinks and takes us with it. I'm selling my hw.
I wonder if we all didn't put so much faith in AMD if we could have lobbied Nvidia to release an open source driver by now.
Instead we've put all our eggs in one basket. The basket fell and we ended up with all our eggs broken.
I'm very disappointed and my long, long support of AMD has taken a very serious beating.
- Likes 1
Comment
Comment