tracing macros in naga_oil could have finer-grained controls

[nicopap]

It's hard to debug bevy's renderer without having recourse to reading the tracing logs. Welp. I previously said it was relevant to bevy, but I don't think so.

Here is my suggestion. I think one of the two should make using logging easier:

• Split naga in more modules, so that the TRACE macros have different modules, and it is possible to silence specific messages
• Use DEBUG log level for the "with defs" message.

[robtfm]

we can definitely change things to make them more usable. do you mean the "with defs" trace from compose.rs@664 ? i'm a bit surprised that's useful, it was only added to debug issues with ensure_imports not generating the right versions of modules, but the other "with defs" logs are debug already.

personally i use the shader dump from "parsing" message primarily, i find often the only way to see what's gone wrong is to have the full shader at the point the error occurred, but i agree it's very noisy as is. i think maybe it would be best to write out the full shader to the filesystem when an error occurs (and probably only when a "dump_errors" feature flag is set). we could also add some comments with the source file and the effective shader defs inline in that error dump too, then maybe the log messages wouldn't be needed much at all.

[nicopap]

Yeah my bad. I was talking about compose.rs@664, but it's not that relevant, I used it to learn which defines are set in a given shader. But bevy_render also dumps the defs with DEBUG bevy_render::render_resource::pipeline_cache: processing shader

Concerning dumping the generated shader. It's probably worthwhile, similar to a compiler asm output. Not only good for debugging broken shaders, but also sussing out performance pitfalls.

In asset-v2 bevy could have a toggle that dumps the generated shaders into a directory.