Comment by jasonjmcghee | Hacker News Reader

Comment by jasonjmcghee | Hacker News Reader

Has anyone taken a crack at building a shading language debugger?

I want to be able to step through a shader and see the values at each step (ideally for any / every pixel)

The best case scenario would be while it's actually running, but simulating it seems like a great solution too.

These are the best I could find: https://github.com/burg/glsl-simulator and https://github.com/cdave1/shdr - both seem to be missing a fair amount of features, though shdr seems like much better support.

There's also: https://glsl-debugger.github.io/ but it doesn't support OS X and feels quite out of date.

There's "print statements" for wgsl: https://github.com/looran/wgsl-debug

I guess WGSL is the up and comer... as opposed to GLSL - but both would be great.

Anyone else have this hope/dream?

The hacks I use today are crazy - like conditionally exiting early based on a time variable and mapping values to colors.

So many folks I talk to are like, "yeah that's how it is". But this just seems not good enough to me...

RenderDoc has step-through debugging at a pixel and fragment level. Click a pixel in the render target view, then open the history and select the fragment to debug.

I think with that threejs' TSL approach there is an opportunity to simulate computations in JS instead of translating it to GLSL. Just need to write an eagerly-evaluating runtime for those EDSL expressions.

Once it's done, you'll be able to use the regular Chrome's Devtools debugger to step through TSL logic.

A nice thing is that would also allow you to unit-test your shading code using regular JS frameworks for testing.

There plenty of options in native APIs, the problem is that browser vendors keep ignoring 3D tooling.

The only thing that exists is SpectorJS and is barely maintained.

So you're left with having a native implementation of the 3D coding, face the challenge to differentiate between browser and web app calls, or classical print pixel debugging.

I fully agree that is crazy Khronos and browser vendors don't see this as an issue, after a decade.

Safari has a (somewhat basic) canvas debugger which also works for WebGL. Firefox had one but it was removed "due to lack of use" (wtf Mozilla?): https://firefox-source-docs.mozilla.org/devtools-user/deprec...

There is good tooling available, but it tends to be vendor-specific and sometimes quite expensive. Here is Arm's tool: https://developer.arm.com/Tools%20and%20Software/Graphics%20...

If you’re ok with debugging shaders themselves outside an engine, SHADERed does an excellent job cross-platform: https://shadered.org/blog

Looks super promising.

Don't see a OS X client and the web version seems quite buggy - a number of the ones I tried to open loaded infinitely (with errors in the console).

I'll give it a shot on Windows...

Edit: Yeah, this is certainly a step forward compared to what I've been doing.

Being able to choose a quad/triangle/pixel and step through breakpoints is fantastic.

Not the best interface / ux, but it's motivating.

Native graphics debuggers like those integrated into Xcode (for Metal) or Visual Studio (for D3D) allow shader step-debugging, as well as RenderDoc (but AFAIK not for all 3D APIs).

Reply on news.ycombinator.com