I just watched jonathon blow's recent monologue about the awful state of the graphics industry: https://youtu.be/rXvDYrSJJfU?si=uNT99Jr4dHU_FDKg

In it he talks about how the complexity of the underlying hardware has progressed so much and so far, that no human being could reasonably hope to understand it well enough to implement a custom graphics library or language. We've gone too far and let Nvidia/Amd/Intel have too much control over the languages we use to interact with this hardware. It's caused stagnation in the game industry from all the overhead and complexity.

Jonathan proposes a sort of "open source gpu" as a potential solution to this problem, but he dismisses it fairly quickly as not possible. Well... why isnt it possible? Sure, the first version wouldn't compare to any modern day gpus in terms of performance... but eventually, after many iterations and many years, we might manage to achieve something that both rivals existing tech in performance, while being significantly easier to write custom software for.

So... let's start from first principles, and try to imagine what such a GPU might look like, or do.

What purpose does a GPU serve?

It used to be highly specialized hardware designed for efficient graphics processing. But nowadays, GPUs are used in a much larger variety of ways. We use them to transcode video, to train and run neural networks, to perform complex simulations, and more.

From a modern standpoint, GPUs are much more than simple graphics processors. In reality, they're heavily parallelized data processing units, capable of running homogenous or near homogenous instruction sets on massive quantities of data simultaneously; in other words, it's just like SIMD on a greater scale.

That is the core usage of GPUs.

So... let's design a piece of hardware that's capable of exactly that, from the ground up.

It needs:

• Onboard memory to store the data

• Many processing cores, to perform manipulations on the data

• A way of moving the data to and from it's own memory

That's really it.

The core abstraction of how you ought to use it should be as simple as this:

• move data into gpu

• perform action on data

• move data off gpu

The most basic library should offer only those basic operations. We can create a generalized abstraction to allow any program to interact with the gpu.

Help me out here; how would you continue the design?

I don't know about most of you, but from my experiences of self-studying GP so far, it's been a hellish landscape of -

having to read (technically) outdated codebases and finding modern-practice equivalents (ComPtr for Dx11/12, for example)

Searching for hours on end on a topic that somehow has very little public resources, or has super verbose resources that requires a PhD in brain power to peruse

Asking-for-help anxiety on the internet due to how finicky engineers can really be, and also running the risks of just upsetting them (I don't like to upset people). Also knowledge gatekeeping in the form of ghosting and private servers.

GP being an important technological field, yet relatively undocumented (in terms of public resources). It's like looking at a vast sea in front of you, which you know when you take a dive, you'd find lots of sea life, but it's so dark down there that you just can't visibly see where to swim.

And I guess most of you are going to look very badly at me, but let me tell you; for the past few months I've been grudging through even just the basics of GP, and I realized I actually do want to make GP a career. I love it, there's so many things that once you learn; just opens up your mind to how our favourite techs really work and also the world. But also, I'm technically the type of guy who looks at the clock and say "I'm taking so long...".

Sorry everyone, but I caved, I'm submitting to terminal brain-rot (ironic for me to say). I need help, but I'm afraid. I'm afraid of asking my questions because I have social-ptsd from stackoverflow and Discord servers. AI replaces that for me because it won't try to hurt me (I'm not being sarcastic).

As for what I'm using to supplement my learning journey; Claude and SuperGrok.
Anyway, just a rant, obviously for attention. I'm hoping if others feel the same way... If not, then fine, I suck, I guess. But a guy's gotta do what he has to do, even if using controversial tools.

I know it's modern and can do things that older APIs like OpenGL can't but how many developers are benefiting from the added verbosity and complexity?

The OpenGL reddit has more members and higher engagement than the Vulkan reddit despite the fact that OpenGL hasn't been updated in 7 years.

Personally, I would prefer if an API like Metal had cross platform support, it's modern and far less verbose.

Please help with feedback

I want to start writing graphics on C++. what can you advice advise

My particles feel like they’re ignoring gravity, I copied the code from SebLague’s GitHub

https://github.com/SebLague/Fluid-Sim/blob/Episode-01/Assets/Scripts/Sim%202D/Compute/FluidSim2D.compute

Either my particles will take forever to form a semi uniform liquid, or it would make multiple clumps, fly to a corner and stay there, or it will legit just freeze at times, all while I still have gravity on.

Someone who’s been in the same situation please tell me what’s happening thank you.

I'm trying to transition the project I've been following LearnOpenGl with to a modified version of The Khronos Groups new Simple Vulkan Engine tutorial series. It uses an entity component system.

My goal is to get back to a basic triangle and I'm ready to create the entity and see if what I've written works.

How should I represent my triangle entity in OpenGl?

Should I do like the tutorial has done with the camera component and define a triangle component that has a vbo and a vao or should each of the individual OpenGl things be its own component that inherits from the base component class?

Would these components then get rebound on each update call?

How would you go about this?

This paper called "The interactive digitizing of polygons and the processing of polygons in a relational database" from 1978 claims that you should store polygon data in a relational database.

Could it have been that we somehow missed the best possible 3D model format? That the creation of OpenUSD, glTF, FBX, etc. were all a waste of time?

Like you can do set operations on databases, so you essentially get CSG for free. Why does this have only a single citation? Why is no one talking about this?

Link to paper: https://dl.acm.org/doi/abs/10.1145/800248.807371

Look I've seen the stuff on shadertoy and youtube. Damn it is so cool. For some background I am a CS major in my third year. I've taken linear algebra in preparation. I bought a VR and have learned about unity (even some of their shader stuff) on my own as preparation for making cool VR graphics (that's what I'd like to do). I have been wanting to do graphics since high-school (and have done some minor studying). I am taking a graphics class this quarter, and god damn it is... boring. I'm wondering if you guys had any similar experiences; we're learning about lines and shapes and pixels and dear fuck it sucks. I'm wondering if this is like the Mr. Miyagi "washing the car" type shit. I am struggling to read the textbook or listen to the lectures because it is near the most uninteresting thing I have learned in my CS schooling yet! I can see how people could make cool things even with these basic concepts, but it is presented so terribly.

TLDR: Basically, when does it get interesting? Does this mean graphics programming isn't for me or should I Stick with it? Did you have similar experiences?

Someone reached out to me for help in another sub.

When I explained to them how to do what they wanted, they decided to patronise and insult me using AI because I'm not an English speaker.

Then they accused me of theft after telling me they'd given me 'a script that fails' to achieve anything..

This is a Draw Engine MORE performant than Nanite.

It's loosely based upon voxel technology and was originally written in PTX (assembly) before I ported it be compatible with more than Cuda..

I call this engine:

NADE: Nano-based Advanced Draw Engine

I'd like to give this away when it's finished..

A friend of mine asked me whether he should learn HLSL or node graphs to get into shader development. Personally, I find code much easier to read and write. With node graphs I often feel like I'm staring at someone's "murder board", where I have to trace connections all over the place to understand what's happening. That said, I didn't wanna give him a biased answer. So I'm curious how others here see it:

- Which do you find easier to read and maintain: code or node graphs?

- Did graph editors make shaders more accessible for you, or less?

- Do you think graphs are feasible for complex shaders, or is there a point where someone who started out with node graphs should move on to code?

I am exploring graphics programming in rust and currently going through the wgpu tutorial. The idea I could program everything and it has support for vulkan, metal, OpenGL and wgpu is making a lot of sense.

Imagine creating a game and users can demo in the browser. Or yet with fast internet speeds like 6GB per second they have in Japan; play the game on the internet, instant access, jump straight in. Isn’t this the future? Instant access to games. Everything in the cloud, downloaded and loaded, cached? Maybe some smart sort of smart loading where the game is initialised and textures etc are downloaded from the moment of purchase or the start button is played? Idk 6Gb per second surely if the world continues in this directing cloud gaming will be a thing and wgpu seems like the framework that is heading towards that..?

Not to compare web development to graphics development but webdev has got to a place where if you you’re not using a framework it’s comparable to pumping up car tires with a bicycle pump or a ball pump. It will work but I mean why do it unless that’s all you had? The abstraction layer of wgpu may cost nanoseconds but won’t this improve over time as more vendors are invested in this technology? And aren’t modern day gpu’s and CPU’s advanced enough to compensate that?

TLDR; I’m learning graphics programming in Rust with wgpu, and I like that it supports Vulkan, Metal, OpenGL, and WebGPU all at once. It feels like the future: imagine games running instantly in the browser or streamed over ultra-fast internet, with smart loading and caching. Cloud gaming could make “instant access” standard.

Yes, wgpu adds a small abstraction cost, but like frameworks in web development, it makes things practical and productive. And with modern GPUs/CPUs, plus growing vendor investment, that overhead is tiny and will likely shrink further.

I hope now more people will be interested in it and this tool will grow and bring joy for the engine and tech art programmers all over the world.

I'm learning about ray tracing and I figured I should share my progress. It is simple, but good to follow for beginners in ray tracing.

https://ruurdsdevlog.wordpress.com/2020/03/02/writing-a-small-raytracer-1/

TLDR: Graphics programming for the most part isn't common, even more so using WebGL/GLSL. What are your thoughts on using JS and the libraries that make it more accessible?

Some context, I'm a frontend web developer and work with JavaScript/TypeScript daily. I gained an interest in graphics programming through watching Acerola on YouTube. I mainly wanted to produce post processing effects, but more so generate/manipulate images.

I found it hard to jump into writing shaders with unity, and GLSL for WebGL is honestly a mess with too much overhead needed. With that, JavaScript is missing a lot of the basic things one would normally use. Things like generating Perlin noise or Vector types.

So far, I've created my own Perlin/Value noise library, quite a few filter effects (such as gaussian blur, B&W + colorize, wave distortion, edge detection, ect.), and even implemented various types of image scaling methods from box/tent to Lagrange-Chebyshev interpolation. Along the way I've also created a few GEMM utilities, but also quite a few calculus and trig utilities.

I'm currently working on creating Vector classes (2, 3, and 4, including their respective integer variants), in addition to a Color class. The Vector classes are based on C#, Unity, and Godot, with a few more additional features. The Color class is primarily based on Godot, but heavily expands on the blend method to support basically all the modes you would find in Adobe Photoshop. It uses sRGB/linearRGB for the most part, but can convert to/from HTML, HSV, HSL, and okLCH.

Over on r/javascript, all of this is well outside the realm of the casual web developer and is exceptionally niche. However, I'm noticing a trend of more games and interactive graphics being build with JS, typically using bloated libraries for rendering/physics.

So, what are your thoughts on having a "bare bones" library that implements what's missing in JS for graphics programming(minus the rendering parts)?

I'm a first year CS student, I'm completely new to Graphics Programming and wanted to get my hands on some Graphics API work. I primarily use a mac for all my coding work, but after looking online, I'm seeing that OpenGL is deprecated on mac and won't run past version 4.1. I also see that I'll need to use MoltenVK to learn Vulkan, and it seems that DX11 isn't even supported for mac. Will this be a problem for me? Can I even use a mac to learn Graphics Programming or will I need to switch to something else?

Hey r/GraphicsProgramming,

First and foremost i know it‘s probably a frequent asked question but thought maybe id get some newer answers/different perspectives.

I'm 21, from Germany, currently in the 3rd year of a software development apprenticeship (similar to a vocational training program, 3 years total). I've been learning graphics programming for about 6 months now - started with a software rasterizer, currently working through LearnOpenGL.

My concerns:

1. AI & Learning: I'm using Claude as a tutor while learning - like it helps explain concepts, review my code, and scaffold boilerplate (CMake, etc.). But I'm deliberately NOT using AI agents to write code for me, because I feel like I need the foundational knowledge first. My plan: Master the basics manually, then use agents once I have enough experience to properly review their output. Is this the right approach? How do you all use AI for learning without becoming dependent?

2. Career path: The job market seems rough right now (especially entry-level). I'm considering:
   - Option A: Finish apprenticeship (end of 2027), then immediately look for junior graphics/graphics-adjacent roles in Germany/EU
   - Option B: Finish apprenticeship, then do a Bachelor's in CS with focus on Visual Computing/Computer Graphics (would finish at 25)

   Which path makes more sense in 2026? Is a degree still valuable for graphics programming, or is portfolio + experience enough?

3. AI's impact on the field: I see AI coding agents getting better at writing shaders, scaffolding renderers, etc. Should I be worried about job security? Or is graphics programming one of those fields where deep expertise will always be needed? My dream is to work at a studio like Rockstar, CDPR, or similar - is this still realistic? (I know far stretch to the biggest studios so i keep it low)

4. International mobility: I'm German, but ideally want to work outside Germany eventually (UK, Canada, US, etc.). How portable is a German apprenticeship + portfolio? Or should I aim for a degree to make visa/international applications easier?

What I'm asking:
- How do you use AI for learning graphics programming without losing depth?
- Apprenticeship + portfolio vs. CS degree for graphics programming in 2026?
- Is the job market really that bad, or is it just entry-level noise?
- Any advice for someone in my situation?

Im generally interested going deep and in depth into these systems and get my hand dirty but what the current models do (and further in the future) im not quite sure how to plan it out

Thanks for reading this wall of text. Any advice is appreciated!

Cheers from Germany 🇩🇪

I am a software developer, not so young anymore, but I always like to try to update my coding skills and try to add more and more features into a small OpenGL engine on which I work as a hobby.

But the recent results in AI are starting to discourage me, in the fear that all the effort we are doing will be useless soon. I've seen some results with StableDiffusion + ControlNet that seem mind blowing. You can give a wireframe image as an input, and get a realistic image as output.
The only problem with the current state of those tools is that they lack coherence, and they are still slow to process for example 60 frames per second.
But given the speed of how this incredible AI progress is going, I won't be surprised if soon those two problems will be solved.

I would like to know other people and graphics programming enthusiasts about this topic, so I thought this would be the good place where to have a discussion on this. Thank you :)