All right, again, this is John. He's going to be talking about the bare metal perspective
on AMD GPU A6. And I think, oh, maybe, oh, no, I thought we were going. They're going to
the laser. You got to connect. You got to say yes. Oh, really?
Quick. If we can't have it, it's okay.
Okay.
Yes.
Hey, wax.
All right, John, you ready? Yeah, I might turn.
Is this on?
Hello.
All right, take away John.
Okay, awesome.
There you go. There's an echo from back of room, which is incredibly off-pacing.
But nevertheless, I want to talk about programming AMD GPU.
It is very late on the Sunday. You are looking tired.
We're going to go with very simple.
Okay.
Look, one over there, I want to get across. I'm going to hit it very hard.
This stays for play.
We are programming GPUs. We use GP programming languages.
I am very lucky, but my previous speaker demonstrated beautifully for
joys of OpenCL and Vulcan.
It cannot have us for better introduction.
And we're very happy with this.
We, I love OpenMP.
Other people love other languages.
They are all uniformly very complicated.
They offer convenience.
And what they take from you is time.
But they also generate huge amounts of revenue for some companies, which successfully
defend this world.
There's a small glitch in this as an axiom, which is the GPUs not actually special.
It was GPU thing.
Very much the same thing as a CPU.
That is the idea I'm trying to get across.
I like a brief show of hands.
Stick hand up in the air if you think I'm wrong.
One person.
Okay.
We need to wake up a little bit.
Okay.
This is not meant to be like reasonable statements.
Those are companies made GPUs.
The charge money for GPUs will make you program the down things in OpenCL.
We don't do this just for a laugh.
We do it because they are supposed to look different.
That particular one.
I'd particularly like because it's one block in memory.
We've load of X86 interpreters on.
And a load of GCN interpreters on.
It's about when it's particularly easy to forget which language you're working with.
What you're programming with, thank you.
But for the sake of the one person who doesn't agree with us.
If this firm holds, if CPUs and GPUs are the same thing, then it follows.
But the GPU languages for programming the special thing don't have to exist.
Right?
If GPUs are special, you need special languages to work with them.
If GPUs and CPUs are the same thing, this didn't have to happen.
You are a tough crowd.
Come on. Give me something here.
We're just great. Good. One person disagrees.
So I think what we are actually working with here is not a protective mode,
which means your wonderful software stacks.
Carefully built on industry standard reliable proprietary software.
It's not a feature. This is something you've done wrong.
Because there's a thing called vendor lock-in.
Which we've forced them crowd should have heard of.
Right?
This lovely castle with its wonderful features comes with things like support contracts.
When your kid stops working, the expensive box full of fans.
You can't do anything with until the end gets back to you.
We never as a solution to that.
And it goes something like open source.
Right?
I am standing here in AMD branding.
I am aware of the open source perception of AMD's computer stack.
Outside of a HPC world who loves us, everyone else is not quite as convinced.
Which is, I suspect, part of why we go to the safety of industry standard software.
But what AMD does come with is you've got our driver on your laptop now.
It's in the Linux kernel.
In entire user space, it's on Rockham.
It's on GitHub.
It's on GitHub slash Rockham.
So when you do not like how our software works, changes.
That's exciting.
I know I haven't these slides.
Do we know what to do about that?
There.
The laptop has gone on standby.
It doesn't matter much.
I guess so.
So what I'm going with this is.
People believe very firmly that CPUs and GPUs are different things.
Even though the underlying silicon looks really the same.
And the reason people think they're different is that the experience of using them is very different.
You grab random 886 machine.
It beats.
You write code.
You have a debugger.
It's easy.
You grab random GPE.
You try to make it do stuff.
And it fights you.
It's a bad experience.
And this leads to fear and sorrow.
And the belief that the GPU-specific languages are important.
So help you keep things working.
But it's not anything to do with the hardware.
This was one of them.
The horrible, narrowly embedded programming is done by the Linux kernel people.
And who present you this friendly world that you build upon.
And the other world, you're actually doing embedded programming.
Which is hard.
That's not a GPU CPU thing.
You program x86 directly.
You have a bad time too.
And this, this picture, which I really thought we'd get laughs.
You guys are fighting me here.
Have we not seen this picture of software engineering?
Oh.
This is how we build all our code, right?
The GPU-driven picture.
The sound sucks.
Yes.
Let's go be true.
I'm trying to shout at you all.
Ah.
Yes.
We work with what we got.
Where am I going?
All right.
Fine.
This is meant to be funny and weight people up.
But you're not loving the ball of mud metaphor for a kid.
So we will continue.
So I claim that CPUs and GPUs have the same thing.
That's exciting.
That's x86, which works really easily.
It's fighting me a bit.
Another mind.
And I think it is a shame that so much a GPU programming is done in sort of slightly copying
and past follow the API guide fashion.
Because most vendors don't really tell you anything about the hardware.
But this vendor does.
You can get read.ox.
We tell you how the damn thing works all the way down to the isle.
If you don't like our software, not only can you ignore our driver, like at least one very
vocal person has decided to do.
You don't have to ignore the assembler.
And the compiler.
You can ignore all of it.
We've given you enough documentation that you can push raw bits across PCI.
And it will do what you tell it to.
But this will be incomplete without mentioning that there is one difference between
the two architectures.
And it is fundamental.
And it is historical.
And it is important.
But it is also invisible of software layer.
And it goes roughly.
If you've got one process.
And you're only running one thing.
You work really, really hard to make that one thing run very fast.
This is what most of x86 and a x64 spends all of its time doing.
But we don't have one process.
We haven't for 20 years.
40 years.
Quite a long time now.
And if you've got more of one process running anyway.
On memory stall.
Instead of all this careful speculative work.
You can just run the other process.
And that is what a GPU gives you.
Provided you're willing to start curfing up with at a least a few hundred separate things to run.
Like every server any of you are using is already into the thousands.
It's just going to run something else on memory stall.
That is so much simpler.
The experience of programming a GPU is very complicated.
It takes a lot of work.
The skill of can underneath is doing something much more straightforward.
And that is the core of the efficiency gain.
It's why your compete per what can be so high.
How long do you have?
Do you know?
Anyone know how?
Ten minutes.
Ooh.
Like as my options.
Um.
How are the steps of you guys to questions?
So we got two good paths to take care.
We can try to do questions or I can run to you about CUDA.
CUDA.
Awesome.
We're doing that.
So I've been waiting for an opportunity.
And you guys have basically not echoed me with anything.
So I still have time left.
Okay.
So this thing.
This thing down here.
Single instruction, multiple thread.
This is a hack.
This is a really clever hack for quite a long time ago.
And it says essentially what has filled the mode around Nvidia's castle with tar.
This is what they have done wrong.
How is that still not contentious?
Do you guys not like CUDA?
No one loves pixel shaders.
All right.
So in the olden days, a GPU had a vector unit.
And memory operations.
That was it.
So if you want to do control flow, you had to do masking that vector unit.
And if you have to write that by hand, you get very sad, very quickly, and very confused.
So what you can do instead, I've just worked out for Microsoft positional.
And what you can do instead of masking the thing by hand is invented programming model,
which hides up from you.
And that makes everyone very happy.
The problem is, 20 years later, you've had the great idea of having an entity unit.
But you don't just have a vector unit anymore.
You can now do scalar instrument, you can use it for branches.
And what the same team gives you is a programming model, note that you do.
Where when you talk about int or float, you are implicitly talking about a vector of 32 int or flex.
So when you want to talk about single int, you don't really have a language to do it.
There's a clever piece of work from Intel, where you understand stuff of uniform,
and try to make sense of the semantic supporters.
But for the majority of it, SIM team means writing easy, single elements of a lane as time code, because very well.
And writing complicated stuff is very badly.
And that doesn't shame, because it means you are prone to using GPs for writing things like glass.
And we should be using GPs, things like running the processes of a arbitrary server.
Because it's a general purpose computer.
And sadly, SIM team is really deeply ingrained.
If you pick up LLVM and you feed some C into it, because you want to run some C on a GPU, you are stuck with a SIM team model.
And I would personally very much like to burn us out.
But I am having trouble winning widespread support for changing the model of GPU programming,
which looks like writing a Vx code.
Which confused me a bit, because people don't mind a Vx code that much, and they don't like SIM team that much.
So it should be possible to persuade people to do the simpler thing,
which lets you tell the hardware what you want to do, instead of telling the compiler roughly what you would like to happen,
and then being cross when the code comes out, isn't what you had in mind when you turn your code into a scalar representation.
In particular, a whole load of bug reports about how the quality of code emitted by LLVM is unacceptable,
would disappear if people would talk to the damping in terms of vectors, instead of in terms of scalars.
No, no, no, no.
Well, we have five, five.
Okay, cool.
So, this is actually the last slide.
I am so dependent on you guys talking to me.
You're just not doing it, and it's messed up all my time.
So instead of OpenCL, or Vulkan, or OpenMP, or that was shown up in the name, or HIP.
I think we should program the GPU, the same way we program the CPU.
We really should.
At the least, start using C++ instead of, I don't care.
Then you've still got the same horrible semantics you used to, but you get all the happy feelings from a C++ ecosystem,
instead of working for translated documentation.
But if you would like to program the thing efficiently and effectively,
just write the damn thing in a assembly, but you should be doing an X86.
Seriously.
Okay.
Show a hands-peeply, like-racing assembly.
All right.
Four of you.
You should all like-racing assembly.
Racing assembly is much more fun than all any of these other things.
One guy shaking head.
Oh, cool.
All right.
So, let's close in thoughts.
It's worth noting that instead of the various languages, which are being marked as a good idea,
if you are building on LLVM, you can use anything which limits IR, like typing into your editor, or C, or Rust,
or whatever you see fit.
Anything which will special, daily structured IR, can be fed to your GPU.
And if you want to go down the whole, like, PyTorch TensorFlow fashion, also fine.
I personally like people to stop running this through LLVM, because it drives you through the SIMT model.
I think you should, instead, map from the tensors in your machine language representation,
directly to the vectors of your machine.
Instead of going through this weird scalar imaginary world,
and that would yield much faster code, and much faster compilation, and much happier users.
But if you don't fancy that, you can't still do the scalar thing.
And I might be out of slice.
Oh, yes, there's a disclaimer.
So, my employer is very nice.
This set of ideas does not correlate very well with our general marketing approach to GPUs.
In particular, all of the, this, this back here, this, our GPU specific languages.
We really like them, and we put a lot of effort into implementing them.
I like, we read your bug reports, we do.
Sometimes we even add some of them.
So, my employer would very much like you to continue programming things like you currently do.
But if you would, instead, like huge amounts of your life back,
and you fancy bypassing a whole load of compute stack, the favour of doing the SIMT model thing,
I want you to know that you can, and it's okay, it will still work.
Okay, I'm going to give up at that point, but thank you all.
I'm grateful for your time.
Thank you. Thank you very much.
Thank you.
Great presentation.
I love writing.
Excellent.
Very good.
Yes, it brings me much joy.