64

Most of the code I write nowadays is for GPUs using a dialect of C. Anyways, due to the hardware of GPUs there is no convenient debugger and you can't just print to console neither.
Most bugs are solved staring at the code and using pen and paper.

I guess one could call that a quirk.

Comments
  • 4
    Curious party here, what kind of GPU's are you developing? What's your software dev stack? I'm curious how that works.
  • 7
    @NeatNerdPrime
    It's a surprisingly mundane stack really.
    I develop exclusively for 'consumer' cards (very high-end ones though think RTX 2080TI), on account of not being able to afford Quadro...

    I use OpenCL to get the GPU to compute stuff. The way this works is that you write the GPU code in a C dialect and ship the source code with your application. OpenCL then figures out what machine language the GPU uses and compiles the code for it every time the programme starts(there are ways to have the GPU code precompiled but that's the easiest way).

    I write the rest of the application in C++, as it is my prefered language and because it gives you controller over memory which makes getting all the data from your CPU to your GPU easier.

    I then use super common libraries for UI stuff and whatnot, QT in my current project.
  • 11
    @shoop
    Hahaha.

    Only in an annoying way, sometimes I set up a buffer where I can write data to from the GPU and then read it on the CPU. This works alright until you fuck up the buffer setup because you're annoyed and you get to debug THAT first. And also everything on a GPU is multithreaded so you get raise conditions in your debugging buffer.

    Fun times.
  • 0
    @Batburger How'd you find yourself getting into gpu programming? Seems like a niche category of programming.
  • 0
    I usually divide and conquer when debugging gpu code. You only leave the part of code that you know works, even if it does nothing, but at least it doesn't crash or introduce a problem, and then slowly add parts in predicting what should be the output and if it isn't I ask why
  • 0
  • 0
    Javascript. That's your ticket to a better workflow.
  • 2
    You have control over the GPU, correct?
    For logging... just put strings of colored pixels on-screen. Just, like, one per log command would do if you don't have too many, or in a known order maybe?
  • 0
    so there was a value in writing code on a piece of paper on the uni exams
  • 0
    Not GLSL by any chance?
  • 0
    Reminds me of the good old days of coding through hyperterminal, it runs so slow that you better off dry running with pen and paper beforehand.
Add Comment