Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How do I become a graphics programmer?

gpuopen.com

Post reply on HN
Print view View original

71–80 of 207 posts

Re: How do I become a graphics programmer?

#71

Post by ryandrake »

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 across each major desktop and mobile platform.

Where did it get me? Not very far, really. First of all, almost nobody cares about OpenGL anymore--it's kind of dead with the two major OS vendors finally abandoning it. Go to any "HN Who's Hiring" and text search for OpenGL. 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.

The smaller the piece of the machine you focus on, the more of a world-class expert you need to become in order to make it your whole career. So, unless your plan includes becoming the next John Carmack or something, I'd recommend going broad rather than deep.

Re: How do I become a graphics programmer?

#72

Post by jherico »

raytopia wrote: post #68

If you want to be a retro graphics programmer reject shaders and return to glBegin.

I'm sure there's a set of shaders that will basically let you emulate the fixed function pipeline without having to endure the shitty performance implications of passing a vertex list to the GPU every single frame.

Re: How do I become a graphics programmer?

#73

Post by achierius »

charcircuit wrote: post #56
delta_p_delta_x wrote: post #41

Earlier quoted context omitted.

Web dev is sufficiently abstracted from the browser and the hardware that a skilled web developer doesn't really need to know the internals of the V8 engine or how a browser works. A web back-end developer probably doesn't need to deal with the browser at all. Graphics programming skill (by 'skill', I mean being able to write a shader pipeline that both satisfies the art direction and performs well), on the contrary,…

All programmers at a certain level must understand the lower levels of the stack they are building upon. I think most people can get by with just learning the abstractions that are provided to them. With time people can learn more and more about lower levels as they specialize. Most people who become graphics programmers don't need to know the low levels of how a GPU works, so I personally do not think that is a good…

Are you a graphics programmer, or are you just saying this because that's true in the CPU world (where you have experience)? From both my own and my colleagues' experiences, I would 100% disagree: the nature of GPU architectures means you are forced to deal with super low-level details from the very beginning. Part of this is because graphics (and GPGPU compute) programming is inherently performance-constrained: if it wasn't, you could just do your work on the CPU with much less of a headache. Even just generally though, the path to running code on a GPU is much simpler — the hardware does less work for the programmer, there's no operating system to manage threads, everything's a single binary, etc. — which means that there's less to insulate you from what's underneath.

Re: How do I become a graphics programmer?

#74

Post by kllrnohj »

SeanAnderson wrote: post #6
bsder wrote: post #3

This isn't hard: DirectX 12 and C++ and Visual Studio (not VSCode) and Windows on an NVIDIA card. Vulkan basically isn't relevant anymore unless you are doing Android. Metal similarly unless you are doing iOS. As a Linux user, this pains me. But it's just life. Windows-land is soooo much better for graphics programming that it's absurd.

How does this sentiment align with the advent of WebGPU?

WebGPU needs to cater to the lowest common denominator so it's unlikely to replace DX12/Vulkan/Metal in the demanding usages. It's always going to lag behind on features, capabilities, and performance.

But for the long tail of image filters, video effects, more graphically basic games - yeah, it's a great fit there. Probably.

Re: How do I become a graphics programmer?

#77

Post by mabster »

quelsolaar wrote: post #46

C is a perfectly good alternative to C++ for Graphics programming. OpenGL and Vulcan are C APIs and DirectX has a C wrapper. Some games like Call of duty are written in C, but C++ is more common.

I've done games in both. My favourite is mostly imperative C++ so you can use templates.

Re: How do I become a graphics programmer?

#78

Post by mabster »

dagmx wrote: post #47
vivty wrote: post #30

Earlier quoted context omitted.

Maybe i am wrong, but this tweet and wikipedia directly contradicts what you say (id tech does indeed use vulkan on windows): https://twitter.com/billykhan/status/1028133659168186368 I am just doing game dev on the side but i think nowadays the graphics abstractions are fairly similar in how they work (the modern abstractions, i.e. Metal, D3D12, Vulkan). Of course ideally you choose the graphics abstraction that is "…

You are correct that idTech targets Vulkan (and they have some great GDC talks to boot) They are however very much the minority. I am suspect of your claim about Vulkan abstraction layers running better than DX12. If there is a performance difference, it’s likely elsewhere in the stack and just tangentially related.

I'm surprised by that as well.

I haven't done this stuff for quite a while, so my memory might be foggy, but the main advantage of Vulcan was that you can control all the CPU locking rather than the API doing it. This allows you to do stuff like prepare on one thread and submit on another, etc.

But that would be negated if you're using an abstraction layer.

Re: How do I become a graphics programmer?

#80

Post by crq-yml »

dragontamer wrote: post #40
ChuckMcM wrote: post #23

Earlier quoted context omitted.

I feel like this comment perfectly captures the difference between programming and coding. Programming comes from a place of first principles, the goal being to understand what is needed completely so that a solution that meets many parallel constraints can be constructed. Coding comes from a place of completing a task, the goal being to get from the requirement to the operating task in as short a time as possible so…

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 lighting calculations, or really to make the rasterizer fast in any way. That wouldn't be the point of the exercise. It could be done entirely with a fixed-size bitmap and a setPixel(x, y, v) call.

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.

Learning to work on production rendering engines would involve reading and studying existing implementations, reading the relevant research papers along the way.

Post reply on HN