Great stuff. I find it really funny that a big feature of modern API's is that applications place barriers instead of being handled by the driver, and we all tried it for a while and then threw up our hands and decided to write graph systems to automatically place them because it was too hard.
graphicsguy
I like to not think of anything as "absolute" or "dealbreaker" (within reason. If there's a culture of harassment I'm gone, for example). But spend intentional time throughout your career reflecting on what matters to you in terms of team culture, code culture, career growth opportunities, compensation, etc. There are a lot of factors to being happy in your work, and a lot of ways to get there. Be intentional about it, and try to always move toward it. It matters a lot more than whatever software you're writing.
Man it sounds like you've had a rough go. I'm sorry that's been your experience.
Graphics Programmer here.
More likely you would just write data to a buffer (basically an array of whatever element type you want) rather than a render target and then read it back to the cpu. Dx, vulkan, etc. all have APIs to upload / download to / from the GPU quite easily, and CUDA makes it even easier, so a simple compute shader or CUDA kernel that writes to a buffer would make the most sense for general purpose computation like an advent of code problem.
As a graphics programmer in the games industry, it's always exciting to me when people discover how much fun all this stuff is
This is interesting. I've always wondered "could I write something that would execute an .hlsl shader on the CPU". After reading this, no I don't think I could lol
Launch your .exe from renderdoc and take a gpu capture. From there you should be able to see:
- Did it actually dispatch more than 1 draw call? If not, then there's a problem in your source file not dispatching all your draws
- If it dispatched multiple draws, inspect the VS output. Did they all just project offscreen or to a singular point or to the exact same points so they're all on top of each other? If so you have an error in your VS shader or your constants
- If the VS output is correct, then the problem lies in your pixel shader or output merger. Pixel shader might be 0'ing out your pixels, blend state might be alpha-0, write mask might be turned off, a whole bunch of possibilities.
Renderdoc is your best friend for these bugs
Ya fair enough. I'd put my "razor" at behaviour that targets vulnerable / minorities, which is probably broader / vaguer than just slurs, but it's going to be a spectrum of opinions and preferences
This.
I ask my boss about project-wide stuff that might impact me and my team, discuss strategy / priorities / roadmaps, ask them to weigh in on anything where I need project leadership to help resolve an issue, and any perfunctory "goals" stuff (I hate it so much haha)
You're right that it's messy and imperfect and false positives can be really frustrating.
But the alternative - no efforts to maintain a safe space - is that vulnerable people are typically the target. Toxicity typically punches down.
I'll happily trade some clunky inconvenience so that those people can safely participate
My broken brain just goes "but how would a decompressor know if '3101' was originally '30' or 101 '3's in a row?"
Download renderdoc: https://renderdoc.org/ It's a great, easy graphics debugging tool.
There, you should be able to inspect your draw call and see what's going wrong.
But also, on the topic of API's. OpenGL is basically obsolete as you suggested, but Vulkan / DX12 / Metal are a huge pain. I'd recommend DX11 if you have windows access, or WebGPU if you don't. For WebGPU you can write it in javascript or natively in C++ / Rust (good tutorial here: https://eliemichel.github.io/LearnWebGPU/)
That being said, if all you want to do is live on the shader side and you don't want to write the API side, then Electronic Arts recently open sourced a great tool called GiGi that lets you get right down to authoring shaders and connecting them together. Think ShaderToy but WAY MORE FEATURES. https://github.com/electronicarts/gigi