PR #6150 suffered a much larger rebase "hell" than I anticipated. On
my Linux box I made this change, but lost it while force-pushing from
Windows (and created some other compiler errors while at it...).
By disabling all features on `glutin`/`glutin-winit` (the latter only
uses `x11`, and only forwards `wayland` to `glutin`) we may have dropped
a lot of "unused" dependencies for other GL backends, but also made the
crate unable to import X11 (Xlib/Xcb) and Wayland handles into EGL.
Also import the missing `glutin::context::Version` struct again which
was added last-minute to #6150 (to make sure my Intel card on Windows
creates a GLES 3.0+ instead of GLES 2.0 context) while the import was
accidentally squashed into #6152 (not merged yet).
* [wgpu-hal] Upgrade `glutin` to `0.31`
`glutin 0.30` onwards completely refactored its internals to no longer
be reliant on `winit`, as they (by default) have no direct relation
except needing to perform _some_ operations (platform-specific) at
strategic times in window creation and event loop handling. Most of
that is handled by a new `glutin-winit` introp crate, while the core
`glutin` crate now exclusively focuses on wrapping the various OpenGL
context APIs (CGL, EGL, WGL, ...).
This does result in a little more verbose handling to get the right
`GLDisplay`, `GLConfig`, `GLContext` and `GLSurface`, but gives much
more control and makes all intricacies more explicit. Most of the
code was copied from `glutin 0.31`'s example crate, with the code for
transparency support removed.
Note that the example doesn't at all handle event loop events properly:
resizes and redraws are not listened to, and mobile-specific surface
events (`Resumed` and `Suspended`) are equally ignored.
* [wgpu-hal] Implement proper `Surface` availability semantics in `raw-gles` example
This option was only evaluated for Metal backends, and now it's required
there so the option is going away. It is still configurable for tests
via the PipelineOptions struct, deserialized from .ron files.
This also fixes some type problems with the unpack functions in
writer.rs. Metal << operator extends operand to int-sized, which then
has to be cast back down to the real size before as_type bit conversion.
The math for the snorm values is corrected, in some cases using the
metal unpack_snorm2x16_to_float function because we can't directly
cast a bit-shifted ushort value to half.
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.
* 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>
Fix two major synchronization issues in `wgpu_val::vulkan`:
- Properly order queue command buffer submissions. Due to Mesa bugs, two semaphores are required even though the Vulkan spec says that only one should be necessary.
- Properly manage surface texture acquisition and presentation:
- Acquiring a surface texture can return while the presentation engine is still displaying the texture. Applications must wait for a semaphore to be signaled before using the acquired texture.
- Presenting a surface texture requires a semaphore to ensure that drawing is complete before presentation occurs.
Co-authored-by: Jim Blandy <jimb@red-bean.com>
This proves a flag in msl::PipelineOptions that attempts to write all
Metal vertex entry points to use a vertex pulling technique. It does
this by:
1) Forcing the _buffer_sizes structure to be generated for all vertex
entry points. The structure has additional buffer_size members that
contain the byte sizes of the vertex buffers.
2) Adding new args to vertex entry points for the vertex id and/or
the instance id and for the bound buffers. If there is an existing
@builtin(vertex_index) or @builtin(instance_index) param, then no
duplicate arg is created.
3) Adding code at the beginning of the function for vertex entry points
to compare the vertex id or instance id against the lengths of all the
bound buffers, and force an early-exit if the bounds are violated.
4) Extracting the raw bytes from the vertex buffer(s) and unpacking
those bytes into the bound attributes with the expected types.
5) Replacing the varyings input and instead using the unpacked
attributes to fill any structs-as-args that are rebuilt in the entry
point.
A new naga test is added which exercises this flag and demonstrates the
effect of the transform. The msl generated by this test passes
validation.
Eventually this transformation will be the default, always-on behavior
for Metal pipelines, though the flag may remain so that naga
translation tests can be run with and without the tranformation.
