Logging? Other error mechanisms?

[Mark Sibly]

Hi,

I'm am trying to hunty down a bizzare bug and noticed the wgpu::Device::SetLoggingCallback function so thought I'd give it a try, but the logging callback never seems to be called. Do I have to do anything else or is it perhaps WIP?

Are there any other error checking mechanisms besides the error, logging and shader compilation callbacks?

Bye!

Mark

[Kai Ninomiya]

I believe you need to process events (similar to what you need to get requestAdapter, requestDevice, mapAsync, etc. to do things).

dawn::native::InstanceProcessEvents or wgpu::Device::Tick (both nonstandard)

wgpu::Instance::ProcessEvents (semi-standard but not sure if it works in Dawn yet)

The other error checking mechanism is PushErrorScope/PopErrorScope just like in the JavaScript API, but that's for when you want to specifically handle an error at runtime, not generally for debugging unless you need to narrow down the scope of where an error comes from.

-Kai (he/they)

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/d75bd55b-548a-4465-8dc3-e55dcdd899d8n%40googlegroups.com.

[Mark Sibly]

Thanks for that, I will give it a whirl!

I did just find the bug though: I was failing to set a bind group which appears to cause rendering to just fail completely, nothing gets cleared, nothing gets drawn,  no error or anything. Perhaps this should cause an error?

One thing a tiny bit inconvenient about bind groups is that their index is implicit, ie: it's given by the order of the bind group layouts in the pipeline layout when you create a pipeline. This means that if you want 'gaps' in bind group indices you need to add an empty bind group layout to the pipeline layout and (as I've just found out) bind an 'empty' bind group when drawing. This seems a little inconsistent with individual bindings which do have an explicit binding index.

Not a big deal really, just yet another trap for young players I guess!

Bye,

Mark

[Mark Sibly]

OK, please ignore my complaint about the missing bind group error, I didn't realize you now have to call Device::Tick() for the error callback to be called - you didn't used to!

All this processing events stuff is news to me, I'm still using synchronous CreateDevice() which seems to be working fine, is it getting removed? Should I be using RequestDevice instead?

Does this mean Tick() now invokes the MapAsync callback too? I remember it used to happen in Device::Queue() but having direct control over this is much better.

Bye!

Mark

[Austin Eng]

We're gradually moving the callbacks to fire only when explicitly asked for. The end goal is that you call wgpuInstanceProcessEvents which should already work today! and eventually wgpuDeviceTick will be deprecated and removed. I think that yes, Tick / ProcessEvents makes the MapAsync callback occur, as well as the OnSubmittedWorkDone callback.

I'm not sure about wgpuAdapterCreateDevice. It is only available in Dawn, not in wgpu-rs, and we haven't agreed upon adding it to the shared webgpu.h header. We also haven't discussed it though. So there's a chance it will stay as a native-only feature, or it will be removed.

SetLoggingCallback sets the callback for other informative logs, but not errors.

So, if you make a Dawn device with the "dump_shaders" toggle enabled, the content of the shaders and compiled shaders will be sent to the logging callback.
It's a Dawn-only thing right now.

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CAK32ozikyfQNo1Odggv3nz4bB0GqGQ_MzXUtR-EtDU2E8GAO4A%40mail.gmail.com.

[Mark Sibly]

Thanks for all that, I've updated my project to use RequestDevice instead of CreateDevice and wgpuInstanceProcessEvents instead of Tick.

Bye!

Mark

[Kai Ninomiya]

On Fri, Apr 14, 2023 at 7:07 PM Mark Sibly <mark...@gmail.com> wrote:

Thanks for all that, I've updated my project to use RequestDevice instead of CreateDevice and wgpuInstanceProcessEvents instead of Tick.

Bye!

Mark

On Sat, Apr 15, 2023 at 9:08 AM Austin Eng <en...@google.com> wrote:

We're gradually moving the callbacks to fire only when explicitly asked for. The end goal is that you call wgpuInstanceProcessEvents which should already work today! and eventually wgpuDeviceTick will be deprecated and removed. I think that yes, Tick / ProcessEvents makes the MapAsync callback occur, as well as the OnSubmittedWorkDone callback.

I'm not sure about wgpuAdapterCreateDevice. It is only available in Dawn, not in wgpu-rs, and we haven't agreed upon adding it to the shared webgpu.h header. We also haven't discussed it though. So there's a chance it will stay as a native-only feature, or it will be removed.

SetLoggingCallback sets the callback for other informative logs, but not errors.

So, if you make a Dawn device with the "dump_shaders" toggle enabled, the content of the shaders and compiled shaders will be sent to the logging callback.
It's a Dawn-only thing right now.

Note wgpuDeviceSetUncapturedErrorCallback (which is standard) should receive any WebGPU errors (like validation errors) that aren't caught by error scopes.