Make wgpu_hal::api::Empty into a usable Noop backend for testing.
#7063
Conversation
Most of validation is in wgpu-core anyway, so I am not sure how much useful would empty wgpu backend be. |
Thank you for that clarification; I wasn’t sure if that was true, and it is quite important for some testing purposes that validation is performed. |
There was a problem hiding this comment.
This is so cool and I've been wanting to have this for a very long time!
I think we can handle the Backends bitflag like this:
- We include the
Emptybackend as in this PR. - We add a
EmptyBackendOptionswhich has a single booleanenable, which defaults false.
This way the empty backend is "enabled", but doesn't actually return any adapter until the enable boolean is set.
Though now thinking about it, if this is feature gated anyway, does it matter? Maybe it does because of feature unification?
We just never wired it up properly.
I'm unaware of any, and if it's there, we can break it, this wasn't a feature we advertised.
Noop backend is a pretty good name, I think changing is is a-okay
I wouldn't worry about it, I think just always returning zeros (or whatever data you wrote it) for mappings is okay. |
kpreid
force-pushed
the
noop-via-hal
branch
3 times, most recently
from
d9e803d to
22572ce
Compare
Indeed, we need to not return a noop backend just because some other package, which is either uncareful about minimal features or has a non-test-only use case for it, has enabled the feature.
Done.
I've now added support for copying and reading buffers, because that seemed likely to be valuable — it will allow full testing of any module/middleware whose job is “put things in a buffer in the proper layout” — and because having it helps prove that the buffer mapping code I need anyway is actually correct; the previous iteration of this PR was actually unsound. Texture support would also be very useful, but significantly harder and so I didn't include it in this PR. |
kpreid
changed the title
Instance::noop() to create a guaranteed nonfunctional instance for testing.wgpu_hal::api::Empty into a usable Noop backend for testing.
|
This just needs conflicts fixed then we're good to go. |
This is in preparation for making it a more substantial test stub, able to execute nontrivial code, and usable from the safe `wgpu` API.
This will allow using it in tests of wgpu resource management code that does not actually require a backend. * `enumerate_adapters()` returns an adapter instead of failing. * `open()` returns a device instead of failing. * `create_buffer()` allocates actual memory. * `map_buffer()` actually provides access to that memory. * `clear_buffer()` actually clears the buffer. * `copy_buffer_to_buffer()` actually copies data. * Fences actually work (trivially, because all operations are synchronous). Future work could include implementing texture copies, timestamp queries, and the clearing part of render passes.
Head branch was pushed to by a user without write access
|
Whoops, I rebased but without having fetched today. Should be good to merge now. |
|
@cwfitzgerald My pushing disabled auto-merge so you're going to have to hit the button again. …also I see you're planning to squash this, so I had better pre-squash it so the commit messages aren't lost. Grumble grumble. |
|
I can rebase, I just wasn't sure if they were standalone |
|
All the commits I previously pushed were self-contained and (should) pass tests. Shall I restore them? Right now I have squashed to one commit, but I don't prefer that. |
|
I have now re-pushed the version with incremental, informative commits. |
|
Yeah just let us know when we can rebase and merge, and we will. We're going to add this to the pull request template shortly. |
Connections
Prototype implementation of #5236.
Description
This allows users to create a nonfunctional
wgpuinstance by setting options to use theNoopbackend (formerlyEmpty), which allows creating resources and issuing commands (that will never run) without having any actual GPU or other device available. This is intended to be used in unit tests for code which manageswgpuresources. It does so by exposing a safe means to createwgpu_hal::api::Empty, and by tweaking the behavior ofEmpty` slightly so that it allows more things to succeed.Resolved questions:
This is a draft because I am unsure about many elements and want to get feedback before I put more work into it. Particularly:It seems to me not ideal that this depends onwgpu-core— butEmptywas already there. I was originally planning to write awgpubackend instead, but this seemed like a simpler place to start. If we like the direction this goes, then perhaps it would be even better to have awgpubackend so there is no need for a feature and no need to buildwgpu-core(e.g. for an application which uses WebGPU only).To get it to run, I had to add aIt is now necessary to specify a special option.Backendsbit forEmpty, which means thatBackends::all()includesEmpty. But applications which ask forBackends::all()will then (semantically if not in practice) be saying they will accept a nonfunctional implementation.Are there any caveats to usingEmptythis way?It seems to be only used for some tests, so perhaps exposing it is incorrect/unsound in some way.Will making more of its operations succeed rather than fail break any of its existing usage?No.I named the public feature “noop” instead of “empty”, but probably there should be consistent naming — I just don't thinkRenamed all toEmptyis a good public name.Noop.Ideally the noop device would accept all commands, but become “lost” immediately upon any action that would be able to view the output (i.e. mapping a buffer for read). I don’t yet know how to do this precisely.The noop device now allows buffer manipulation but nothing else.Testing
Added a test function demonstrating minimum functionality. No manual testing or specific hardware required to test! That's the whole point!
Checklist
cargo fmt.taplo format.cargo clippy. If applicable, add:--target wasm32-unknown-unknowncargo xtask testto run tests.CHANGELOG.md. See simple instructions inside file.