The buffer size was being aligned to `D3D12_CONSTANT_BUFFER_DATA_PLACEMENT_ALIGNMENT` (256). The buffer size value is used as the binding size (when none is specified), causing `arrayLength()` to return values larger than what users of the API specified for the buffer size.
This entirely consists of conditionally replacing `Mutex` with `RefCell`,
then making sure that this doesn’t accidentally happen if we are also
exposing `Send + Sync`.
* Add basic drm support to vulkan backend
* Move vulkan drm implementation to its own module
* Properly feature gate drm support and add safety docs
* Disable drm on wasm targets
* Remove old fixme comment from vulkan drm backend
* Move cfg check inside drm module
* Use expect instead of allow for create_surface_from_drm
* Document that drm is not available on apple platforms
* Initial(untested commit), vulkan and gles only supported
* Maybe fixed compiles for metal and dx12
* Hopefully fixed compiles for other backends and updated to functional(?) vulkan thing
* Fixed the clippy warning
* Fixed silly documentation mistake
* Fixed issue with multiview feature
* Dummy commit for dummy CI
The CI pooped itself, hopefully this fixes that. Will probably be undone either way.
* Re trigger CI checks, to avoid #7126
* Changes based on code review
* Fixed clippy warning, broken cargo.lock
* Unfucked cargo.lock for real this time
* Switched match to if-let in accordance with review
* Updated changelog
* Fix CI error
Done from web out of impatience
* CI is very angry 😡
Made CI less angry by fixing formatting(hopefully). This commit was also done from GitHub web.
* Removed comment in following request
* Update wgpu-hal/src/vulkan/adapter.rs
---------
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
This allows `wgpu-hal` to be used in `no_std` environments, except that
currently, only the `noop` backend supports `no_std`.
In the future, `cfg(all(gles, webgl))` should also be `no_std`, but that
requires further work.
Co-Authored_by: Kevin Reid <kpreid@switchb.org>
Weaken our dependence on the `once_cell` crate by using functionality
from `std` instead that was upstreamed from `once_cell`, this time with
what's available in Rust 1.80+.
It's not yet possible to eliminate this dependency entirely, but do what
we can for now.
This was previously an `allow`-by-default warning in Clippy's `pedantic`
group, but with Rust 1.83 it was promoted to a `warn`-by-default member
of its `complexity` group.
Co-Authored-By: Kevin Reid <kpreid@switchb.org>
If it is undefined behaviour for loops to be infinite, then, when
encountering an infinite loop, downstream compilers are able to make
certain optimizations that may be unsafe. For example, omitting bounds
checks. To prevent this, we must ensure that any loops emitted by our
backends are provably bounded. We already do this for both the MSL and
HLSL backends. This patch makes us do so for SPIRV as well.
The construct used is the same as for HLSL and MSL backends: use a
vec2<u32> to emulate a 64-bit counter, which is incremented every
iteration and breaks after 2^64 iterations.
While the implementation is fairly verbose for the SPIRV backend, the
logic is simple enough. The one point of note is that SPIRV requires
`OpVariable` instructions with a `Function` storage class to be
located at the start of the first block of the function. We therefore
remember the IDs generated for each loop counter variable in a
function whilst generating the function body's code. The instructions
to declare these variables are then emitted in `Function::to_words()`
prior to emitting the function's body.
As this may negatively impact shader performance, this workaround can
be disabled using the same mechanism as for other backends: eg calling
Device::create_shader_module_trusted() and setting the
ShaderRuntimeChecks::force_loop_bounding flag to false.
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.
