@ekaitz_zarraga Maybe more specifically: gpuopen.com/rdna2-isa-availabl

That first website seems to be mostly for AMD CPUs, not GPUs

@ekaitz_zarraga
If you want to understand the architecture of a GPU, how they operate and execute work and all that, the AMD manuals are _incredibly_ detailed. Highly recommended if you want to go down that rabbit hole... but be warned that it's a _deeeeep_ rabbit hole

@ekaitz_zarraga
If you want to go down into low-level communication with the GPU, you'll have to look at GPU driver implementations, like the Nouveau driver

@ekaitz_zarraga
And between companies, the only thing they _need_ to do is implement the DX/Vulkan/OpenGL specs. How exactly they do that is up to them, and the details vary wildly

@ekaitz_zarraga
Individual companies tend to reuse a lot of stuff from older generations of cards, and within the same generation you can generally count on things being pretty similar... but there's no guarantee that, say, Navi GPUs will share anything in common with Navi2 GPUs in terms of how they communicate with their driver. In fact, that's on purpose, so that the GPU vendors have more freedom to modify and improve things under the hood

@ekaitz_zarraga
The lowest-level you can go is by using Vulkan, which is the "no hand-holding" API. You'll have to do a loooot of stuff manually (like allocating memory on the GPU, for example), but that's all still standardized by the Vulkan spec. You can switch your GPU from AMD to nVidia or Intel, and everything should still work (at least in theory...)

@ekaitz_zarraga
Basically, really low-level communication with the GPU is not something we ever do. We use the APIs provided by the GPU driver. In general, because GPUs all have different architectures, ISAs, etc, you can't count on being able to communicate with one without a driver that's specific to that GPU

@ekaitz_zarraga
In general, the driver will expose standard APIs for you to communicate with the GPU. In Linux, the driver will give you a Vulkan and an OpenGL implementation you can use. In Windows, you'll have DirectX, Vulkan and OpenGL. If you want to go lower-level than that (and basically communicate via IRQs and memory locations with the GPU) you'll need to write your own GPU driver

@ekaitz_zarraga
And I think that's about it. Let me know if you want to know more :)

@ekaitz_zarraga
You can kinda solve this by switching to SPIR-V, a precompiled shader binary format. SPIR-V is the standard in Vulkan, and I believe there's some support in OpenGL nowadays too (not sure about this). With SPIR-V, you compile your source to this binary representation, and then the driver just needs to do the final translation to GPU machine code, which is a lot simpler and straightforward. That way compiled SPIR-V programs are GPU and driver-independent and you can share them around freely

@ekaitz_zarraga

Regarding the compilation step, you can get back the compiled bit stream out of the driver, but it's unfortunately driver-dependent and GPU dependent, so it's only useful to cache it so you don't need to recompile it on later runs. If you wanted to ship something with precompiled shaders in OpenGL, you'd have to precompile your shaders for every possible combination of GPU and driver, and keep it updated forever. Pretty ridiculous task, unfortunately.

@ekaitz_zarraga

You can either do these things manually (each OS has a different API for this), or you can use a library that abstracts all this and gives you a cross-platform implementation of window handling and blitting (the "copy texture to screen" part). Examples of libraries like this are: SDL, SFML, GLFW and a bunch of others.

@ekaitz_zarraga

Everything that I've said so far is platform-independent. OpenGL defines all these things as a standard. Sadly, there's some things they didn't dare to standarize, because OSs are too different from each other. This shows up in everything related to window handling. As long as you don't need the data to be displayed on screen, you can do everything cross-platform. But once you do, window creation is a platform-dependent thing, and outputting the result of your shaders to a window is too.

@ekaitz_zarraga

Unlike other similar APIs (DX12, Metal, Vulkan...), OpenGL doesn't consume a pre-compiled version of your shaders. In OpenGL, you give the driver the source code for your shader, the driver compiles it and gives you a handle you can use to refer to the compiled shader. Then, you can send data to the GPU, and essentially tell OpenGL "grab this shader, and set these 3 textures as input, and this buffer as output. Then execute".

@ekaitz_zarraga
Ok, this will be a long one.

1/x

OpenGL is a standard API designed to allow you to send data between your GPU and CPU, and to execute programs on the GPU (we call these programs "shaders").

The data you send can either be textures (a collection of pixels), buffers (arbitrarily typed data), or the code for the shaders to execute.

A couple months ago I mentioned I was giving a presentation about what I've been up to at work. Well, the video has been published, finally! So here it is 🙂
youtu.be/ool2E8SQPGU

@matthewseiji
This is hitting too close for comfort...
They even have "therapists" that I'm pretty sure will be reading a script...

@Doomed_Daniel
No idea! And I didn't even know that about github pages, so...

Show older
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!