All right, thank you. So welcome everybody. Good morning. I hope everybody had enough sleep,
and potentially enough coffee so far. My name is JP Lair. I work at AMD. You can see that
there, they're here and on my t-shirt as well. So in case you missed it, you have plenty of
opportunities to see it. So I'm going to talk about rocking on the rocks. Now what is that? And I
learned from a colleague after I put the slides together that they say on the rocks to something
when it's in a bad shape. So I was like, hmm, that's not the message I want to convey. So for me
on the rocks, it's just the preferable way to serve a drink that I don't particularly like, okay?
So, but it's rock them on the rocks. So that's first look at rock them a bit. So rock them as our
software stack plenty of people probably know. There's a bunch of things in here that's a picture
and newer picture that I'd taken from a blog post that we did for a very nice version rock
in 7.9 tech preview. In case you didn't know that we had, you know, 7172 and 799 anyway.
So we have a bunch of operating systems supported at the bottom. We have then, of course,
the infrastructure stuff, including the GPU driver and Kubernetes support and whatever.
And then we have the software on top of it, which is the rock and core SDK. That is the one thing
that I'm talking about mostly today, which has the compilers, the run times and whatever.
And then we have vertical SDKs, which are more domain specific packages with, you know,
extensions to the core SDK, tile it for example for data science, right? So we ship more stuff there.
And then we have more operating system support monitoring support. And then, of course,
right on top, there's the whole AI ecosystem that, you know, it's very, very, very prominent right now.
So talking about the expansion SDKs, there's one for HPC. There's a couple of things where it adds
value for Fortran. So if you actually want to call into some of the hip libraries that we ship,
so hip FFTW would have hip FFT or something. The rock and HPC expansion SDK comes with hip
fort, which generates all the bindings that you can use from your Fortran application to call
into those hip libraries. And then there's the rock and data science expansion SDK that gives you
GPU accelerated data processing. I am not an expert, so I asked some colleagues and it apparently
includes the hip DF, which is hip data frame. So the data frames processing and hip graph
and hip mm and it's out of preview. So it should work, right? So you can go check it out and see
what actually does work. And then we also have the rock and click live science expansion SDK that
gives you GPU accelerated IO in some some medical image processing. That is as much as I know,
still in early access state. So you may see a couple of bumps there, but both of them are also
compatible with a rapid ecosystem. So I think that's one of the most important things here.
So then looking at the Core SDK again, this is what most people think of or at least what I think
of as kind of the rock and thing, right? We have the compiler. We have the math libraries. We have
the communication libraries and whatnot. And this is actually what the rock builds or what the rock
is for and then the rock. What is the rock, right? So the rock is basically our path forward to build
tests and distribute rockham, right? It also comes with a couple of changes in how we organize our
software in terms of the repository structure. And one of the goals is probably one of the main
goals is to make it not only easier to to build and ship it, but also faster, right? Previously,
we had a multi week, multi weeks in between rock and releases. With the rock, we build and
nightly so that you can get, you know, the most coolest features every night. So coming to why,
again, faster shipping. But also, I mean, building rockham was just put it politely, not obvious,
right? Anybody here try to build rockham? Yes, who agrees that building rockham was an obvious?
Yes, okay, see. So with the rock, it's getting better, certainly. So I think one of the cool things here
is that actually making your software build a build is embracing the open source ecosystem,
right? Because I mean, if we open source to stuff, that's great, but if you cannot build it, that's
worth us, right? So that's, I think that's great. So speaking of the rock, the rock is now kind of the
single source of truth, right? And as part of that, the components or the libraries and
the system level stuff, those have been integrated into what is called super repositories. So instead of
having like, I don't know, 56 different repositories, there is no only four or five, maybe, right?
And I think that's a big step forward, because it's now a little more obvious,
what you actually need in order to build rockham in the first place. And so inside the rock,
you will have references to those other repositories that bring in the components.
You will have the build recipes, and you will have the containers that we use as the
build environment to actually build rockham. In addition, test recipes and packaging recipes,
although I think the test recipes are in there yet, and the packaging recipes are also still a little
bit on the development. So the repo consolidation, what does it actually mean?
There now is a single rockham libraries super repo that has all the, let's say, AMD SMI
and other system level components that have been previously in living in their own repository.
So they are now consolidated here in rockham libraries. Then there is the rockham systems,
sorry, the rockham libraries, of course, is the libraries I was confused here a bit.
The rockham libraries has all the math lips and those sorts of things. The rockham systems
has AMD SMI, so the systems level stuff apologies for the confusion here.
And then we also have rock GDP as one of the other high-level components.
And then we also have the compiler. So those are kind of like your four high-level
components that you actually need in order to build the rockham core SDK. And I'm a compiler person,
so I really enjoy this one. And also we will see later that the compiler and rock GDP are a little
different when it comes to contributing to these things. So if you find a bug,
how you would actually help us fixing it is different here. But again, I'm a compiler person,
so to me to compile it special. Okay, not only for contributing reasons, but in general.
So how does the rock keep track of the components? So those four arrows should refer to the
different super repository that we have, which is the compiler, the libraries, the system, and the
debugger. And basically inside the rock you will have sub module pointers that keep track of a certain
state of that repository. So that this is a combination or a configuration of the rock, right?
So this is a particular version that you can build with the rock.
And let's see. And then what happens is for the libraries and the systems super repo.
These sub module pointers are basically updated every day to track the most recent advancements
in those super repositories if and only if the integration pipeline is green, right? So if you
find a test error while you're advancing these sub module pointers, you are not going to
to maintain that you're going to roll back. So that the rock is kind of always green. That's the
idea and that's what we want to achieve moving forward. Okay, so building rock.
That has been a pain in the past. So I'm very happy that with the rock, I show you commands now,
okay, and that actually worked on my machine TM, right? So this. So all you do is you do a CMake,
I use Ninja for building, I set the source to the rock source, I put in the build directory,
and I want to build for the AMD GPU families, GFX1030. GFX1030, by the way, is a consumer grade GPU,
right? It's not not the data sender GPU. So we have much more support now also for the data sent
for the consumer grade GPUs, which I think is great. It's amazing because you don't need to spend
thousands of dollars for a data sender GPU to try stuff out, right? Okay, but so this, you know,
this will build all of it, and that's maybe not what you want because you don't want to wait
hours and hours for your, you know, your command to come back. So maybe you want to use this
configuration. So I just added the rock enable all equals off, right, because we don't want to build
all, we just want to build the compiler. I just want to build the compiler again because the compiler
special to me, right? Okay, so we build flang now. So I tested this on a 16 core 32 threads machine
with 128 gigs of RAM, and you want to add that flag, because otherwise you will tell the out of,
out of memory manager like, oh, yeah, please take a job, right? Because flang consumes six to
seven gigabytes per process while compiling. So you can easily smash your system if you do not limit
the parallelism when you're compiling flying. The other thing is that the rock uses something that
is called like a job pool or something in CMake. So it will typically spawn more threads or
processes, then you specifically tell it something to do, right? And so there is a CMake flag that
you can basically set the rock background jobs to just one. So it will just respect however many
processes you specify when you tell it to build something so you don't overload your system. But again,
flang parallel compiling jobs, that's important. And then maybe you also want to, you know, enable
the hip run time because you want to actually produce something that's useful for you. So you know,
you can do that and you can then with the components that got built here, you can run compile
and run your hip applications. Which I think is neat because that's way easier than what you
used to do. Then of course, if you run into problems, you know, contributions.com.
All of this is open source also for the reason that if you if you some look or something
that doesn't work, open an issue in the rock or in like one of the specific repositories,
you know, create a fork, branch, a contribute, whatever. But for rock GDP, it's a little different.
And so the contributions for rock GDP kind of need to be upstreamable at some point. And
for upstreaming into GDP, there's specific process that people need to follow. And I think
they have to sign some sort of agreement. That's what you told me.
Okay. So whatever you contribute to rock GDP needs to be upstreamable and for that and to make
that happen, you have to hand over the copyright to the FSF, so that, you know, that's in a
well shape. But so if you have questions about that particular, lands a lot here here so you can
you can talk to him. And so now let's look at the compiler. When we look at this picture,
I told you that the repositories move forward every night, right, these sub module pointers.
For the compiler, they don't. For various reasons, one of them is we merge upstream LVM into
our downstream compiler about four to six times a day. And there's a lot of churn and there's a lot
of breakage coming in. And so we want to give the developers that actually use the rock for developing
a more stable compiler for a certain amount of time. And so we aim for moving the compiler forward
every two to four weeks. So that's why, you know, the errors a little bit higher here.
Now looking again, if you want to contribute and looking at the compiler in that regard,
the preferred way of contributing to the rock and compiler is to actually go to LVM upstream
because that makes it, you know, much nicer, much easier to have for all the other projects that
also want to run on AMD GPU for example, but that will lie on the LVM project to do so.
So Triton is an example here, right? They track LVM upstream. And so if you want to fix a bug in the
AMD GPU back and for example, you want to do that in LVM upstream so that also Triton can pick it up.
And then those changes get merged into the AMD LVM fork. That's the one that is tracked down stream.
And then we have some downstream special sauce that, you know, we contribute only there.
And then the rock will actually track that branch, that fork in its sub module pointer.
So let's say you build all of this with the first line here, right? You run CMake build,
probably want to add another dash dash parallel here actually. And then you can actually just
do see test in the build directory and it will run some initial tests to see if the build worked
and if that actually makes sense what what you produced. It does not yet do component level testing
if you run it that way. I think that will be there at some point, but it's not there yet at least not
with this like super easy command. Now just again looking at this timeframe what I mentioned
in the legacy rock conversion basically. So this is time I'm going from left to right.
We would merge from our development compiler into the released into the release branches. Let's say here
and there, right? So if we would fix a bug in the compiler here, you would need to wait until the next
merge to actually get that. And that's kind of bad if you have like a fast paste ecosystem.
And so with the rock, we will have much more updates into the compiler so that you know,
everybody can benefit from the advancements and from the fixes that we do.
And so to sum it up, I think rock among the rocks is kind of great because it gives you a
really open source way of doing things because it's in the public and also like AMD engineers
are encouraged to open up the issues on GitHub not internally or not only internally so that you know,
people can track out progress, people can see what we do and I think it's a great.
There's also more and more a community around this. So there's an AMD developer community on
Discord. If you look at the rock, read me, there's a link to it so you can join that.
There's AI folks in there. There's HPC folks in there. There's people from the rock. So if you have a
question about how to build it or why doesn't that work, that's a great place to be and ask questions.
And then for again, for the more fast paste ecosystem, which is not necessarily HPC, I
know, but for the more fast paste ecosystem, the faster delivery that the rock gives us, I think it's
great, great thing. So then I put all the references here that I used so you can actually
read them, look at them and links to the repositories. Then I have this slide that I'm typically
need to show you so I could be wrong here, right? And with that, I thank you very much and I'm
hoping to have questions.
Okay. So the question is whether the rock has a version and all the other
components also have a version and then there's a rock
version, how that does all come together.
The answer is I don't know.
I got confused with the all versioning stuff,
but so I don't know what's the current status
there is.
Can you go back to slide 13?
Slide 13. I was asked to go back to slide 13.
Which one is that?
What's up with all the branches?
The contributing model for AMD engineers is not that we do forks
and then do poor request.
But that everybody opens up branches in those repositories.
That's why there are so many branches.
Everybody writes to the repository
is supposed to be stating branches essentially
Yes, everybody.
Yes, so people who have push rights work in those repositories
and then again, so for example, the rock and libraries repository
has like I don't know how many different sub-projects
because all the libraries are in there.
So if you're just considering maybe there's
30 libraries in there.
So in so many engineers, that's why you see like up to a thousand branches.
There is a naming scheme, yes.
Yes, it makes sense.
Okay, more questions here.
Do you show the thing it's supposed to be?
So the question was that we need to specify the GPU family
and whether I'm getting confused with the preview here.
Whether it's possible to have generic builds.
The answer is yes.
It's possible and actually so the rock.
There's a distinction between targets and families.
So this would be technically a target.
The families can be even more abstract,
but I don't recall them because I only think in targets.
So it would be like GFX 11 something.
And that will give you support for all the GFX 11 based systems
that are currently supported.
So you can build for multiple architectures at the same time.
And I think you could also specify the actual generic target
to build those as well.
So the question is what's the size difference between a generic build
and just a strict sailor build?
And the answer is I don't know.
So what was the size difference?
Yeah.
So from the system administrators hat,
the question was how is the supposed work with the packaging?
And the answer is I'm not quite sure.
There's other people looking at that.
But my understanding is that so right now,
this will produce basically charge easy artifacts
that are currently also just pushed into some
history storage so you can download those.
And they're also producing Python wheels from it right now.
And moving forward,
there will be packages for the different distros.
And I would hope that there will be some more,
let's say, not distros specific means of grabbing the tar gz
and putting stuff somewhere.
Right?
Does that answer your question?
Okay, maybe we can take this off line.
Okay, cool.
So the question was whether we do binary compatibility
between releases or between certain releases.
So is that ABI compatibility or?
Okay, so my answer that is I'm not quite sure actually.
That might be a question for somebody from the rock team.
I don't know if Mario's is here.
No, he isn't okay.
But that would be another.
So that would be something you can easily ask
on this developer community thing.
They may have an answer for you there.
Okay.
Is there a for open source developers to get access to some resources,
like the SSAH and this GPU there,
or the way we're connecting?
So the question is, is there a way for open source developers
to get access to hardware, especially like GPUs?
So they used to be the AMD developer,
the AMD developer cloud, I think it was called.
One time I checked, you had to have like an AMD content person.
I think that has been relaxed a little bit.
And there's also now there's another program
that I forgot the name of, where it's mostly geared towards AI use cases,
I think.
But it is in general to bring up the ecosystem around AMD GPUs more.
So that might be a vehicle.
But yeah, for specifics, I'm not quite sure.
I would also need to check the website where you know,
ask people.
Okay.
More questions.
Yes?
So the question is, how close do the versions from user land and kernel land need to be?
Right?
When you have, let's say, a PyTorch container,
and you have the KFD and your host system.
How close do they?
At least in the past, we guarantee two versions up and down what's compatibility
from everything.
My experience is that it's much more than that.
But also, it has been some restructuring going on,
so that we're actually more isolating things a little bit
because of specifically these AI container world.
So I don't think it has to be super tightly put together
from a version point of view.
But again, the details, I'm not entirely sure.
So yeah.
And times up.
Thank you.