Error handling and panic in observablehq notebook #165
Description
Hi,
Sorry for opening the issue directly on github, but I cannot see this repo in the dropdown menu in https://antv-issue-helper.surge.sh
I created a reproducer in ObservableHQ for a panic when using a specific shader:
https://observablehq.com/d/bece57b91ebd5a40
I'm using a compute-toys notebook fork which pulls in the latest version @antv/[email protected]
The setup works for the origami shader, however when using shader code that compiles and runs fine in compute.toys (see https://compute.toys/view/1079) I can get the following stack trace in the console:
glsl_wgsl_compiler_bg.wasm:0x23257e Uncaught (in promise) RuntimeError: unreachable
at __rust_start_panic (glsl_wgsl_compiler_bg.wasm:0x23257e)
at rust_panic (glsl_wgsl_compiler_bg.wasm:0x2318d1)
at std::panicking::rust_panic_with_hook::hdb857edf4e61fe11 (glsl_wgsl_compiler_bg.wasm:0x216e3e)
at std::panicking::begin_panic_handler::{{closure}}::hef75e0b11b6899ae (glsl_wgsl_compiler_bg.wasm:0x21dd09)
at std::sys_common::backtrace::__rust_end_short_backtrace::h2c4c1ce3acc2944e (glsl_wgsl_compiler_bg.wasm:0x2321dc)
at rust_begin_unwind (glsl_wgsl_compiler_bg.wasm:0x228274)
at core::panicking::panic_fmt::hf20f9922c43dc05c (glsl_wgsl_compiler_bg.wasm:0x22ca20)
at core::result::unwrap_failed::h92d50af5668640d2 (glsl_wgsl_compiler_bg.wasm:0x21f486)
at wgslcomposer_wgsl_compile (glsl_wgsl_compiler_bg.wasm:0x180ba4)
at Rr.wgsl_compile (glsl_wgsl_compiler.js:211:12)
$__rust_start_panic @ glsl_wgsl_compiler_bg.wasm:0x23257e
$rust_panic @ glsl_wgsl_compiler_bg.wasm:0x2318d1
$std::panicking::rust_panic_with_hook::hdb857edf4e61fe11 @ glsl_wgsl_compiler_bg.wasm:0x216e3e
$std::panicking::begin_panic_handler::{{closure}}::hef75e0b11b6899ae @ glsl_wgsl_compiler_bg.wasm:0x21dd09
$std::sys_common::backtrace::__rust_end_short_backtrace::h2c4c1ce3acc2944e @ glsl_wgsl_compiler_bg.wasm:0x2321dc
$rust_begin_unwind @ glsl_wgsl_compiler_bg.wasm:0x228274
$core::panicking::panic_fmt::hf20f9922c43dc05c @ glsl_wgsl_compiler_bg.wasm:0x22ca20
$core::result::unwrap_failed::h92d50af5668640d2 @ glsl_wgsl_compiler_bg.wasm:0x21f486
$wgslcomposer_wgsl_compile @ glsl_wgsl_compiler_bg.wasm:0x180ba4
wgsl_compile @ glsl_wgsl_compiler.js:211
(anonymous) @ compute-toys.js?v=4&…7b91ebd5a40@314:485
(anonymous) @ compute-toys.js?v=4&…7b91ebd5a40@314:478
eval @ observablehq-17:43
await in eval (async)
eval @ observablehq-295:4
(anonymous) @ worker-488e6463.js:2
Promise.then (async)
ea @ worker-488e6463.js:2
value @ worker-488e6463.js:2
(anonymous) @ worker-488e6463.js:2
Promise.then (async)
value @ worker-488e6463.js:2
value @ worker-488e6463.js:2
Pr @ worker-488e6463.js:2
value @ worker-488e6463.js:2
value @ worker-488e6463.js:2
define @ compute-toys.js?v=4&…7b91ebd5a40@314:698
value @ worker-488e6463.js:2
(anonymous) @ worker-488e6463.js:2
Promise.then (async)
Ea @ worker-488e6463.js:2
define @ worker-488e6463.js:2
rs @ worker-488e6463.js:2
(anonymous)
Additional context
Chrome on MacOS Version 122.0.6261.94 (Official Build) (arm64)
I have noticed the following in regard to errors and error handling in general:
- Since I've made the
runfunction take in the shader string, there are cases where in particular reusing the prelude without binding for instancetime.elapsedwill result in these errors being constantly spammed in the console.
GPUValidationError {message: '[Invalid CommandBuffer] is invalid.\n - While calling [Queue].Submit([[Invalid CommandBuffer]])\n'}
GPUValidationError {message: '[Invalid BindGroup] is invalid.\n - While encoding …r].SetBindGroup(0, [Invalid BindGroup], 0, ...).\n'}
Using a trick such as:
var ignore = time.elapsed / time.elapsed; // to avoid rewriting run without the time bindings.
var uv = (fragCoord * 2. - resolution.xy) / resolution.y * ignore;
Works to bypass that problem and avoid having to reinitialise each cell with a different set of bindings.
-
Is there a better way to enable using a notebook to progressively build a compute shader? Maybe some variables can be initialised and made available to the page first, like
deviceand only runningcreateProgram()anddevice.createComputePipeline()on each cell? If you had a example notebook with this approach that would be great to be able to use observablehq to explain shaders step by step. -
Some code that runs on
compute.toysdoesn't work withg-device-api. This seems to have to do with type checking.
let a = hash1(p+vec2(0,0));
compute.toys seems able to infer the types but this will spam this error message with g-device-api:
Device.ts:210
GPUValidationError {message: '[Invalid CommandBuffer] is invalid.\n - While calling [Queue].Submit([[Invalid CommandBuffer]])\n'}
The fix is easy enough, but the error handling and lack of error messages makes it difficult to use.
let a = hash1(p+float2(0,0));
// or let a = hash1(p+vec2(0.,0.));
- In general, when there is an error that spams the console, even when the code is fixed in the same session/notebook, the messages continue to appear in the console (I'm not sure if there's still a context behind the scenes that is not cleaned up, or if the messages have been buffered). It requires reloading the notebook for the messages to stop.
Thank you very much for the great library, I'm really looking forward to using it more in observablehq and I hope my remarks are helpful to improve the error handling experience!
Cheers,
Jun