• 1 Post
  • 17 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle
  • 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



  • 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.







  • 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







  • I worked remotely for the first 2 years of the pandemic. It was fine at first but when I switched teams and no longer knew everybody from before the pandemic, the social loss started to wear on me. It’s not like we had social meetings on my old team, but I think I was able to pretend better or something when I knew everyone in real life.

    I also started to struggle to stop working and I hated that and hated the space occupied by my workstation.

    I also have a lot of equipment (console dev kits in games industry) and it takes up a lot of precious space.

    For all those reasons I’m back in the office 100%. Also I prefer to collaborate in person in my job (it’s much easier to hash things out with an artist in person).

    Still, there are some things that are permanently changed in ways that make me sad. There will always be some remote folks, so every meeting must be remote accessible (and rightly so), which means we still have to sit on zoom calls a lot of the time. Also zoom has lowered the friction to having a meeting, so we end up having way more meetings.

    I don’t begrudge the WFHers. I want everyone to have what they want and be happy, and particularly for the parents out there, the saved commute time and flexible hours are a godsend.


  • Also if you branch on a GPU, the compiler has to reserve enough registers to walk through both branches (handwavey), which means lower occupancy.

    Often you have no choice, or removing the branch leaves you with just as much code so it’s irrelevant. But sometimes it matters. If you know that a particular draw call will always use one side of the branch but not the other, a typical optimization is to compile a separate version of the shader that removes the unused branch and saves on registers


  • graphicsguytoC++Why use pointers?
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    1 year ago

    Pointers also allow you to do fun and dangerous things like casting between types!

    For example, if you’re implementing your own memory allocator, at the base level your allocator only really cares about how many bytes are being requested (along with alignment, offset, other things) so you’d probably just implement it to return a char*, u8*, or void* pointing to the blob of memory you allocated with new, malloc, or whatever scheme you’ve cooked up. The calling code or higher level allocator code could then cast it to the actual type