In `naga:🔙hlsl`:
- Generate calls to `Interlocked{op}64` when necessary. not
`Interlocked{op}`.
- Make atomic operations that do not produce a value emit their
operands properly.
In the Naga snapshot tests:
- Adapt `atomicOps-int64-min-max.wgsl` to include cases that
cover non-trivial atomic operation operand emitting.
In `wgpu_hal::vulkan::adapter`:
- When retrieving physical device features, be sure to include
the `PhysicalDeviceShaderAtomicInt64Features` extending struct
in the chain whenever the `VK_KHR_shader_atomic_int64` extension
is available.
- Request both `shader_{buffer,shared}_int64_atomics` in the
`PhysicalDeviceShaderAtomicInt64Features` extending struct when either of
`wgpu_types::Features::SHADER_INT64_ATOMIC_{ALL_OPS,MIN_MAX}` is requested.
---------
Co-authored-by: Jim Blandy <jimb@red-bean.com>
It's already documented that to unmap a buffer it has to have been mapped.
Vulkan was the only backend that was returning an OOM on missing `Buffer.block` but `Buffer.map_buffer` already returns an error in this case.
naga doesn't have a `serde` feature, instead having separate
`serialize` and `deserialize` features, so things that want to
modify the serde handling must check for either of those, not
for `serde` itself.
Consolidate the explanation of buffer mapping in the documentation for
`Buffer`. Change the example code to actually compile, given that the
`map_async` callback needs to share access to the buffer with
`map_async`'s caller. Mapping isn't pretty, but covering that up in
the docs doesn't improve matters.
For `BufferSlice`, `BufferView`, and `BufferViewMut`, consolidate
extended explanations and background in the docs for types, rather
than scattering it around in the docs for associated functions.
For `Buffer::slice`, `BufferSlice::get_mapped_range`, and
`BufferSlice::get_mapped_range_mut`, update documentation to provide
necessary details, but defer to types' docs for background.
The Vec only ever contained 0 or 1 command buffers.
We now acquire an encoder on every submit for pending writes but that's not a problem since those are coming from a pool anyway.
* Expose gpu allocation configuration options
This commit adds hints to control memory allocations strategies to the configuration options. These hints allow for automatic profiles such as optimizing for performance (the default, makes sense for a game), optimizing for memory usage (typically more useful for a web browser or UI library) and specifying settings manually.
The details of gpu allocation are still in flux. The goal is to switch vulkan and metal to gpu_allocator which is currently used with d3d12. gpu_allocator will also likely receive more configuration options, in particular the ability to start with smaller memory block sizes and progressively grow the block size. So the manual settings already provision for this upcoming option. Another approach could be to wait and add the manual option after the dust settles.
The reason for providing presets and defining values in the backends is that I am convinced that optimal fonigurations should take hardware capabilities into consideration. It's a deep rabbithole, though, so that will be an exercise for later.
* changelog
* Update CHANGELOG.md
Co-authored-by: Andreas Reich <r_andreas2@web.de>
* Add a comment about not entirely knowing what we are doing
---------
Co-authored-by: Andreas Reich <r_andreas2@web.de>
