This addresses the `BestPractices-Arm-vkCreateSampler-lod-clamping` message from ARM:
65b79bac61/layers/best_practices/bp_descriptor.cpp (L103-L110)
Rather than clamping the LOD in the samplers, instead rely on the Image-View's `vk::ImageSubresourceRange` to limit the number of sampled LODs.
Currently, only game-textures actually have MipMaps, so this does not introduce any additional mip-map sampling or filtering anywhere. If any code want's to actually limit the number of LODs sampled, then they would allocate an additional ImageView for the range of MipMaps to be sampled.
Co-authored-by: flyinghead <flyinghead@users.noreply.github.com>
* cmake: use c++17
* Use std::size
* Use std::make_unique
* Use std::clamp
* Use structured binding
* Use [[fallthrough]]
* Use enable_if_t/is_enum_v/is_integral_v/is_same_v
* Use if constexpr
* Use try_emplace
* Use auto for iterators
* Use inline variables
oit: skip to new frame even if previous frame was never presented
libretro: quad pipeline used for overlay must use subpass 2 in per-pixel
overlay: delay destruction of VMUs images
libretro: WaitIdle on queue instead of wait_sync_index
BufferData was always allocated in host visible mem, regardless of the
mem property argument.
NVidia gpus don't support blitting to 565 and 5551, which is needed for
mipmaps, so convert to 8888 instead.
Use optimal tiling for oit pointers image (linear not supported by
nvidia and probably slower anyway)
oit screen drawer uses multiple final attachments
Set non-oit depth attachment as transient and lazily allocate mem
fetch color format, storage buffer alignment and stores/atomics support
at init
support for framebuffers used as input attachments
use Allocator instead of VulkanAllocator
return handles instead of unique handles
Flyinghead