Alex

Since the recent camera oriented renderer updates, the system which prepares the depth texture is now `prepare_core_3d_depth_textures()`. This issue is still valid otherwise.

One complication here is that even if the depth buffer is marked `TEXTURE_BINDING` it's not trivial to access the depth texture once it's written to. It's currently spawned on demand...

Ace! I'm interested! Given that the pre-pass would reduce overall fragment cost, is the doubled vertex cost that much of a worry?

Great work @agausmann ! Is your crate ready for publishing? Also, may I recommend you add your lib to https://github.com/rust-embedded-community/usb-device so that it's easier for people to find? I'm going...

Did you make any progress with this? I also need DMA to PWM output.

I'm hoping to DMA to PWM duty cycle so that I can drive WS2812 asynchronously since they're vey time sensitive (synchronous timing is getting messed up by my other interrupts)....

Wow, you went above and beyond here. Thanks! Yes, I'll be using a pulse train too. I think my requirements are very similar. I'm using RTIC, so I'll just lean...

_FYI This is my first PR, just in case you need to poke the CI server._ Also I'm not a huge fan of external nodes referencing `core_3d::graph::node::TRANSPARENT_PASS` (e.g. bevy_ui), since...

>Would it be possible to add an empty node that's called FINAL_PASS that runs after the TRANSPARENT_PASS? That way other nodes that depend on the main pass won't need to...

> Couldn't you make the 3 nodes into a subgraph? I think this would even make these changes non-breaking. Nice idea. Yes, I'll reconfigure and update this PR today.