How do I become a graphics programmer? • Hacker News Board

Re: How do I become a graphics programmer?

#151

Post by account42 » Thu, Nov 23, 2023, 1:35 PM UTC

dagmx wrote: post #22

slabity wrote: post #9

Earlier quoted context omitted.

> Vulkan basically isn't relevant anymore unless you are doing Android. Why do you say this?

I’m not the person you asked but my 2c (since I agree with their point on Vulkan) Very few video games are made with Vulkan. DirectX is the primary API. Android is the only place where Vulkan really has an interesting market share. For a beginner, it has an incredibly steep learning curve vs DirectX as well. So given the low usage and high friction to pick it up, you have a really poor ROI. DirectX and Metal are much…

> For a beginner, it has an incredibly steep learning curve vs DirectX as well.

That's only because you refer to DirectX as a whole which includes plenty of older and APIs. If you want to start with those you can just as well start with OpenGL. if you want to jump straight into D3D 12 then that's not much differrent from Vulkan.

Re: How do I become a graphics programmer?

#152

Post by account42 » Thu, Nov 23, 2023, 1:48 PM UTC

lopkeny12ko wrote: post #2

Ah, the AMD Game Engineering team, the same fine folks who implemented driver-level "optimizations" for Counter Strike that resulted in thousands of players getting permanently VAC banned.

You can't possibly hold AMD responsible for the behavior of third party black boxes? If Valve makes assumptions about the graphics drivers beyond the API then that's on them.

Re: How do I become a graphics programmer?

#153

Post by The_Colonel » Thu, Nov 23, 2023, 2:04 PM UTC

pjmlp wrote: post #110

vlovich123 wrote: post #100

Earlier quoted context omitted.

I feel like better expertise targets tend to be more durable. In other words, rather than expert in a specific technology or technique, the best experts had the ability to develop expertise in any given technology within a space and often overlapped cursory knowledge with other spaces. I met plenty of graphics experts at Oculus and they didn’t care so much about whether it was D3D or Vulkan - originally they were D3D…

When people like Bjarne Stroustoup, Herb Suttter, Andrei Alexandrescu say they are by no means a C++ expert, always beware of anyone that says otherwise. Same applies to most languages, unless they are talking about toy languages. Even something like C or Go, have so much room to debunk such experts. Between compilers, versions, language evolution, runtime, standard library, OS specific behaviours,....

I get the overall point, but this humility makes it difficult to use some kind of grading/levels.

Take e.g. MS Office as an example of a large C++ project. Certainly, there are developers with just "average" knowledge of C++ working there. Then there are people having strong/advanced C++ knowledge.

But in a project like MS Office there are certainly devs who are still much stronger in the language, best in the project/company, but still likely below people like Stroustoup or Alexandrescu. How to call those? I think avoiding the term "expert" just to be consistent with the above-mentioned humility is impractical.

Re: How do I become a graphics programmer?

#154

Post by CyberDildonics » Thu, Nov 23, 2023, 2:05 PM UTC

adamnemecek wrote: post #102

CyberDildonics wrote: post #90

Earlier quoted context omitted.

So what? You don't think they might need to learn math or a graphics API or fundamentals first? You think they need to compile a rust webgpu implementation first because it's small? How does this make any sense?

What do you think wgpu is if not a graphics API?

You can use it in a browser without compiling anything. Have you ever taught someone from scratch? You don't invent nonsense rabbit holes and barriers to entry to make things harder.

Re: How do I become a graphics programmer?

#155

Post by david-gpu » Thu, Nov 23, 2023, 2:08 PM UTC

ryandrake wrote: post #71

stemlord wrote: post #11

I would suggest that beginners not lead with "which tools should I capitalize on" and instead, take a step back and ask "what do I want to make"? Don't lose focus on the final output as you make your first steps. In the world of computer graphics today there are so many tools that abstract away various steps in the process of drawing pixels to the screen that you could very easily waste too much time suffering with l…

Listen to this guy, great advice. Early in my career, I set out to become an "OpenGL expert" and I'd say I mostly got there. I mean I'm no Mark Kilgard and haven't written any textbooks, but I dove super deep into the technology, and gained at least a decade of experience working on all levels of the API from the driver level to conformance tests and performance tuning, up the stack to game and application code, and…

> Sure, I could have gone and re-skilled and learned another similar graphics API, but the second problem is nobody really needs people who write low-level Direct3D or Vulkan or Metal anymore because that's all abstracted for you by engines. And there are max 5 or 6 companies in the world that even have the need for people who can do low-level graphics drivers. It's a career-limiting niche.

I did that for a living and can only agree partially.

First, the part were we agree: only a handful of companies hire graphics driver developers. This means that if this is your career you need to be willing to either put up with the idiosyncrasies of your employer or be willing to move geographically. As a result, people tend to stick to the same employer for many years.

As for OpenGL becoming obsolete, it's like anything else in tech: you need to keep up with whatever is in demand. Vulkan/Metal/DX12 didn't appear out of thin air, they were created by the exact same folks who worked on older APIs for many years, so it really wasn't a huge paradigm shift for driver developers.

GPU driver development is a perfectly valid career choice with good job stability and very decent pay.

What I disliked about it is that, perhaps contrary to what you are saying, I felt that it was rather repetitive and after having worked on a few different GPU generations. Innovation happens in other areas like GPU architecture, not in driver development, but that's a topic for another day.

Re: How do I become a graphics programmer?

#156

Post by CyberDildonics » Thu, Nov 23, 2023, 2:08 PM UTC

TheRoque wrote: post #94

CyberDildonics wrote: post #91

Earlier quoted context omitted.

Using webgpu makes sense, but that isn't what they said. They said compiling a rust webgpu implementation.

Since this is very straightforward to do, I took it as equivalent statements

You think writing javascript fragments in a browser that is already installed is exactly the same as learning to compile rust then compiling a third party webgpu project in it?

That's not even graphics programming and everyone already has something that works, how are they at all the same thing?

Re: How do I become a graphics programmer?

#157

Post by dragontamer » Thu, Nov 23, 2023, 2:33 PM UTC

crq-yml wrote: post #80

dragontamer wrote: post #40

Earlier quoted context omitted.

2D graphics with bitblits is a completely different paradigm. If you were using 2D GPUs from the 90s, or maybe a 2D Industrial PC's GPU, sure... Learning about Bitblits and rects is good. But if your goal is to program a modern shader on a modern platform (even if it's a 2D graphic), you should learn a modern graphics library. ------- A modern graphics API is laid out the way it is: to maximize modern performance on…

There's a lot of leeway to learn 3D principles through a basic software rasterizer. It does not take long - if you already have some awareness of the math, it's at most a few weeks to work through the essentials from a tutorial. Once you get to the point where you're drawing filled triangles through a projected camera, you can move on. There's no need to go into occlusion culling strategies, texture mapping or lighti…

> you learn the specific API incantation to bring one up

The graphics pipeline from geometry -> vertex shader -> pixel shader -> image is the damn point.

When the literal hardware is laid out in a certain way, you must learn that hardware layout and understand it. These API 'incantations' as you put it aren't high magic. They logically flow from the requirements of modern graphics programming.

If you just skip that stuff, you won't ever learn about modern GPUs, modern CPU->GPU data transfers, GPU parallelism or how a CPU calls the GPU routines to render.

Maybe you can make the argument that you should learn rasterizing first to simplify the learning process. But I would argue that it's easy enough to learn rasterizing when you get to the Pixel Shader step.

> The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers.

The argument against that is that you eventually have to learn today's hardware anyway. So you might as well start now.

Tomorrow's hardware is based on today's hardware. And today's hardware is based on yesterday's hardware.

It's all incremental progress. I'd personally say that OpenGL with GLSL might kinda sorta look like modern stuff (vertex and pixel shaders), but anything older (ex: 90s BitBlits) is so old it's just completely a waste of time.

Re: How do I become a graphics programmer?

#158

Post by dahart » Thu, Nov 23, 2023, 2:54 PM UTC

pjmlp wrote: post #111

TheRoque wrote: post #97

Earlier quoted context omitted.

Well, as someone looking to get into this field, I kind of disagree. A lot (if not all) job postings about graphics programming require you to know C++ beforehand. Sure, you can have another role, like gameplay programmer, and slowly work your way in graphics, and it's probably easier to do so, but in fine, for the graphics programmer role, C++ is required. What you are describing is more about someone who wants to b…

First learn the foundations, then the language. When I started, graphics programming was all about Assembly. Then it was about Object Pascal and C, then it was about C++, now it also requires C#. And who knows, maybe in 20 years, one of the C++ wannabe replacements manages to also have a spot, or some AI driven thingie. Those will solid foundations in graphics programming algorithms, will manage regardless of the lan…

> now it also requires C#.

For Unity games? What else? Just curious. I’ve been doing graphics programming for decades, and C# has never been part of it, and still isn’t on my radar.

Re: How do I become a graphics programmer?

#159

Post by dahart » Thu, Nov 23, 2023, 2:58 PM UTC

rajangdavis wrote: post #116

quelsolaar wrote: post #53

As a graphics programmer i think its good to have a well rounded idea about how graphics works. Here are some things I would expect a good graphics programmer to know, beyond just programming and an API: -Rotation view and projection matrices, and general vector math. -Shader programming. -Procedural primitives like voronoi, SDF and perlin. -Image Compositing. -Forward and deferred rendering. -Various sampling techni…

Where do you learn this stuff?

School, then work, is the most traditional route. If you’re past that point and want to learn, the best use of that list is to use it as a self-learning syllabus and set of search terms, so you can start to practice.

Re: How do I become a graphics programmer?

#160

Post by usrusr » Thu, Nov 23, 2023, 2:59 PM UTC

4death4 wrote: post #141

ryandrake wrote: post #71

Earlier quoted context omitted.

Listen to this guy, great advice. Early in my career, I set out to become an "OpenGL expert" and I'd say I mostly got there. I mean I'm no Mark Kilgard and haven't written any textbooks, but I dove super deep into the technology, and gained at least a decade of experience working on all levels of the API from the driver level to conformance tests and performance tuning, up the stack to game and application code, and…

Going broad rather than deep cuts both ways. Sure, you have more employment opportunities, but the value of your individual contributions has a ceiling. That means after a relatively short period of time, you plateau career wise. Like is a generalist with 15 years of experience really that much more valuable than one with 7 years? Not really. So if you want to progress beyond a generic senior engineer, then you need…

But how many of those deep specialists got there by rationally weighing pros and cons and then picking a strategy?

My guess would be that for every example who got there on the curriculum drawing board, there are at least two who just happened to be in the right place at the time the technology grew, four who got infatuated with "their" technology so much they'd specialize no matter the pay relative to generalists, and eight would-be generalists who failed to keep their generalization in balance through a sequence of projects built on top of the experience of those before.

GP mentioned Carmack, that outlier of outliers. He did not get there by picking one technology and burying himself deep, he did whatever was practical. At the time IrisGL begat OpenGL, Carmack was battling the limitations of EGA and CGA in the Commander Keen series and then moved on to create the 2.5D wonders that followed. But he was more than ready to retire his world class expertise in software rendering when OpenGL came into reach of PC hardware. Textbook generalist behavior.