An AMD GCN Assembler For Linux That Supports The Open & Closed Drivers

[phoronix]

Phoronix: An AMD GCN Assembler For Linux That Supports The Open & Closed Drivers

A Phoronix reader pointed out that a developer has released an assembler for AMD GCN GPUs that supports both the open and closed-source Catalyst drivers on Linux...

http://www.phoronix.com/scan.php?pag...-GCN-Assembler

[NerdTaco]

I think the community deserves a lot of credit for picking up where AMD is currently failing at providing at the moment (nobody knows whats coming down the pipe in terms of actual upstream driver changes, so we can only wait on that). We got some really awesome people working on changes for AMD chips, and as much as id love to see upstream AMD start to pick themselves up off the ground, people are still going out and making the linux world awesome. The community really deserves a lot more credit than they get

[Azpegath]

I don't get it, what do you use it for?

[elldekaa]

I'm interested if anyone can give some details about the interest of this ? Directly writing assembly code for the GPU ? If yes, there is people that need it ?

[Calinou]

I think the community deserves a lot of credit for picking up where AMD is currently failing at providing at the moment (nobody knows whats coming down the pipe in terms of actual upstream driver changes, so we can only wait on that). We got some really awesome people working on changes for AMD chips, and as much as id love to see upstream AMD start to pick themselves up off the ground, people are still going out and making the linux world awesome. The community really deserves a lot more credit than they get

I would like to see reverse engineered firmware, so that you can finally use AMD cards in freedom, without having to wait for them to update it to fix bugs.

[duby229]

I would like to see reverse engineered firmware, so that you can finally use AMD cards in freedom, without having to wait for them to update it to fix bugs.

I think time has proven that AMD is the driver of AMD's open source development. So I think regardless we'll still be waiting on them. If you look at it in terms of scales of dimension (I guess fractal is the right word), I'm pretty sure it would be likely that AMD themselves would be the ones developing and maintaining such a thing. I would love to see that happen. Maybe someday they will get there. I encourage it to happen.

[blubbaer]

I don't get it, what do you use it for?

After a quick look, I can tell you that you can write compute kernels with it. Not in a higher-level language like C but in assembly. Writing compute kernels (maybe shaders too) in assembly can give you better performance than a compiler could achieve. Back in the early days, just before OpenGL 2.0 came out, shaders were written in assembly.

This could give graphics developers the opportunity to tweak their shaders to get some FPS more. Sadly Catalyst and Gallium don't have the same ABI so it isn't very portable.

[SystemCrasher]

I would like to see reverse engineered firmware, so that you can finally use AMD cards in freedom, without having to wait for them to update it to fix bugs.

Good wish, but IMO it is more important to get rid of blobware in places like storage devices, because firmware can make a lot of harm there. At the end of day, if GPU would dare to misbehave, in modern system IOMMU would kick in and stop wrong memory accesses same way usual MMU stops incorrect memory accesses on CPU side. But when it comes to storage... there are no real constraints. You throw command down to interface, internal firmware takes control in device's CPU and then you can only hope for the best. But you never know what this firmware up to. Ever heard of Equation group, who have developed bootkits involving HDD firmware patching? You can erase your drive, reformat it to the hell... but firmware would eventually return patched sectors anyway, potentially handing control over system to "right" code, which could patch some parts of system, taking some parts of botkiit "out of nowhere" and without any actions from software on CPU side.

Modern computer could have like a dozen of various small helper coprocessors, and it is not like if it is mandatory to do a direct attack. These helper processors are usually situated in rather convenient positions and can do all sorts of nasty crap in really unobvious ways. Intel ME serves as perfect example of tivoized backdoor, and each and every x86 PC from Intel since 2010 has got it. TA-DA.

There is very little point to get rid of GPU firmware, if your x86 system boots like this: on powerup, small helper CPU starts. It can provide remote management and early system startup. This is not a x86 CPU. Early CPUs were ARC, later are something else. It have signed firmware and you can't even just delete offending firmware since this little bastard would just power down whole system in 30 minutes if you haven't put firmware to system ROM, making computer unusable without signed "management" backdoor code from Intel. Then this small CPU brings up rest of system, primary CPU starts and x86 code executes. It worth of nothing it is blob-free since ME CPU runs side by side, can access built-in network card in chip set, can pwn everything via DMA writes, and so on. And so, if one is serious about freedom, getting rid of x86 and Intel's ME backdoor crap is very first thing to do. In terms of ability to pwn system and terms of tivoized blob crap in boot sequence of main system parts.

[SystemCrasher]

I don't get it, what do you use it for?

High performance computing, obviously. BOINC is a distributed grid platform. I guess they assemble carefully optimized, hand-crafted code into GPU commands which GCN GPU could actually execute. GPUs are not like CPUs and so GPUs can be much faster on some kinds of computations, as long as one can write down their algo to be massively parallel.

Just to give you idea: my GPU beats my fairly powerful 8-core CPU by something like 50x on massively parallel computational tasks, on poorly optimized opensource MESA's opencl. Then it got GDDR5 RAM which is several times faster than main system DDR3 RAM (theoretically it could be like 8x difference or so). Of course there is catch: it takes very special ways of crafting algos to actually get something similar to these numbers, and not each and every algo could be coded in massively parallel, GPU-friendly way. That's why GPUs are limited to "accelerators" role. They can't run, say, OS processes 50x faster. But they can crunch numbers 50x faster, etc. Basically, GPU can do an impressive amount of SIMD-like operations at once. Graphic processing is most obvious thing where it works great. Then, some crypto and scientific computations could be like this as well. Probably there're quite many things which can be accelerated.

[bridgman]

I would like to see reverse engineered firmware, so that you can finally use AMD cards in freedom, without having to wait for them to update it to fix bugs.

IIRC we have only had to update microcode twice - once to safely enable open-source video acceleration on chips which were not designed to support it, and once when we accidentally pushed an older version of microcode with the initial driver code and had to replace it with a newer one (where both versions existed before HW launched).

What microcode bugs are you waiting for us to fix ?

And the usual question, what makes built-in (and hence unfixable) microcode any more attractive to you ?

Or are you talking about VBIOS, which already has open source header files for the data tables, an open source interpreter for the command tables, and an open source disassembler for the command tables as well. Other than some X86 wrappers to support the standard int10 interface everything else is AtomBIOS command and data tables.