AMD Navi "Blockchain" Card Support Being Added To Linux 5.10

[phoronix]

Phoronix: AMD Navi "Blockchain" Card Support Being Added To Linux 5.10

Last week we were first to report on a PCI ID being added for a Navi 1 "Blockchain" graphics card without display outputs and seemingly focused on cryptocurrency mining. This card wasn't talked about at yesterday's Radeon RX 6000 series launch but that support is now on the way to the Linux 5.10 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Blockchain-ID-For-Linux-510

[karolherbst]

As I anticipate a lot of comments, let's make it quick: No, blockchain doesn't solve your problems and yes everybody telling you otherwise wants to scam you.

Below this comment will only contain garbage and you can just skip it and do more rewarding things instead of reading here.

[tildearrow]

I don't even understand how can people get "free money" this way.

Here in our country it is sad to see that cryptocurrencies such as Bitcoin are being used for criminal activities...
...which only makes me (and other people) trust the system less...

[ThoreauHD]

All currency is used for criminal activities. It's just that one currency currently owns your media, and the others don't- yet.

[Jumbotron]

Ok...let the ignorant flamers gear up. AMD is NOT making a "cryptocurrency" card. They are making a compute card that is tuned for blockchain. AMD couldn't give two shits about cryptocurrency miners which fall into two groups.

1: Criminals/Criminal Governments
2: Naive Ultra Libertarian/Anarchic Utopians

What AMD IS DOING along with their purchase of Xilinx arguably the best run and deepest IP FPGA company on the planet, is to begin to produce an infrastructure for blockchain.

Blockchain by default needs lots of compute horsepower...like...what doesn't nowadays? It also needs a metric shit ton of IO. Guess what? AMD has CPUs with metric shit tons of compute. AMD has GPUs with metric shit tons of compute. AND NOW they have FPGAs with metric shit tons of IO capability.

Guess what folks. AMD is now capable of building a data center in a box. Or in the case of this story a blockchain center in a box. And every component tied together with a cache coherent topography called Infinity Architecture along with the upcoming Gen-Z protocol and architecture to tie together racks of 4U AMD/Xilinx Data Center/Block Chain Centers in a Box.

All you Blockchain deniers/bad mouthers... piss off. Cryptocurrency kiddies...yeah you can REALLY piss off. Blockchain is here now and here to stay. Crypto...LOL. Children and thugs scratching in the digital dirt hunting for digital gold nuggets.

But Blockchain IS ALREADY here. It is ALREADY in the global distribution infrastructure. Every SINGLE Central Bank on the planet is going flaming ball's out to produce their own version of Blockchain based Central Bank Currency, first for internal settlement then to roll out to their respective Citizens. By 2030 at least 4 major countries <Sweden, China> and a couple of minor ones <Viet Nam> will have already rolled out their own digital currencies based on Blockchain.

AMD wants a BIG SLICE of that multi-billion...soon...trillion dollar business.

Not to mention fat government/defense contracts where Blockchain is increasingly the order of the day

THAT'S why there is an AMD Blockchain card.

[Ipkh]

I wish AMD would focus more on their OpenCL drivers and release these as compute cards. For things like Folding@Home, GPUgrid and the like. Maybe use that to improve their open source drivers and make linux hardware acceleration more accessible. Actual help the community instead if hindering it with multiple software stacks.

[Jumbotron]

Trust me AMD doesn't care about GPUGrid and [email protected] least not as a corporate policy.

But I agree with you about the
state of their OpenCL efforts. I say this as an admitted AMD fan bois from 1989 until now....AMD'S OpenCL efforts are a bag of cats who are also on fire and pissing on each other to put the fire out.

Look at how the feckless, clueless Intel who STILL AFTER 7 FUCKING YEARS can't do 10nm. They are ALREADY full supporting OpenCL 3 and have oneAPI.

Nvidia...CUDA...'nuff said.

AMD has ALL the pieces now hardware wise. CPUs, GPU's, FPGAs, and ARM DSP's. They have arguably the best interconnect technology in Infinity Archtecture to tie everything together all on cache coherence outside of Cray Shasta / SGI Ultra Violet interconnects.

But AMD SUCKKKKKKKKKKSSSSSS at software and APIs. ROCm is STILL....STILL a hot steaming pile. It's been 10 years...10 FREAKING YEARS.

If AMD can get their shit together in time they can REALLY seal their place as a legitimate competitor in HPC vs Nvidia and Intel as opposed to just being the "cheaper option"

But if they don't the HPC market only has room for 2 APIs and frameworks...that being Intel's oneAPI and Nvidia's CUDA.

[bridgman]

Rock is STILL....STILL a hot steaming pile. It's been 10 years...10 FREAKING YEARS.

In fairness, most of that 10 years was overtime. We started the ROCm initiative about 4 years ago.

[Jumbotron]

In fairness, most of that 10 years was overtime. We started the ROCm initiative about 4 years ago.

Of course you are correct but i was rolling in AMD's work on the lead up to ROCm which includes the Fusion/HSA work. And sorry for the misspelling of ROCm with ROCK...smart (not so smart) phone.

Look...I know you guys....the engineers...are working your asses off. And now with Lisa Su you actually have a for real, got her hands dirty at IBM type engineer as CEO. She is kicking all kinds of ass and has made it possible (along with the rest of you guys) to get AMD to the point where you all are once again contenders in HPC and of course just recently in financial shape to buy Xilinx which I have been wanting you guys to do since Intel bought Altera.

Don't take my words as anything but brutally honest fan bois perspective but backed up with all kinds of love and hope for AMD's future. And I know you are a huge part of that as well, which deserves ALL of our respect. Cheers.

[bridgman]

I'm not sure how much sense it makes to include the previous Fusion/HSA work. That was pretty Windows-centric and designed around completely different hardware - APUs with 48-bit addressing (same as the CPU) and using IOMMUv2 for transparent GPU access to unpinned CPU memory via recoverable page faults.

The dGPUs of the time were much more limited - 40 bit addressing, GPUVM and only able to access pinned memory that had been explicitly mapped to GPU by the driver. Discrete GPUs (ours and our competitors) are only now catching up with the APU capabilities we had in 2014.

We were able to re-use some of the earlier code - compiler front end, runtime and kernel driver skeleton mostly - but most of what we consider the ROCm stack today was written from scratch including compiler back end, memory management and of course all the libraries.