3 ms·
Don’t be too down on yourself. There’s actually more overlap between graphics programming and other disciplines than you might image. Imagine the gpu is your “s
by ninepoints 5y ago
Don’t be too down on yourself. There’s actually more overlap between graphics programming and other disciplines than you might image. Imagine the gpu is your “server” and each cpu core is your “client.” We have a difficult job of feeding tons of data to keep the server occupied. We have to worry about memory hazards, as well as cpu-cpu synchronization and cpu-gpu synchronization. Like server engineers, we think about pipelining, data consistency, caching, compression, and more. The assets themselves need to be streamed from disk/network to memory, so that’s another systems programming concern.
This all happens independently of the actual kernels/shaders we dispatch on the GPU itself (where the 3d math and all that comes into play). There are definitely rendering programmers that specialize more in the stuff above though.
- chii 5y ago> we think about pipelining, data consistency, caching, compression, and more. but i think all of these are incidental complexity brought on by the physical world, practicality of the hardware and api calls. The _actual_ complexity in graphics rendering is the maths required,as well as understanding of the physics/modelling of the materials etc, and how to cut down unnecessary computation etc to achieve the framerate target.
- ninepoints 5y agoMy point is that there are plenty of engineers that work with graphics pipelines that don’t actually think about the 3d stuff that much. It’s one of many available avenues of specialization.