There were numerous problems with the previous effort to add support for
linear views of sRGB storage textures. Here's another attempt:
- Images are always created with the linear version of their format.
- The default texture view uses the sRGB format if the parent is sRGB.
- Use ImageViewUsageCreateInfo to specify the usage for render/storage views.
- sRGB image views always have their storage bit forcibly cleared.
The storage view now behaves more like the existing renderView -- if we
detect that you couldn't use the default texture view for storage, we'll
create one that is guaranteed to be usable for storage bindings (by
clearing the sRGB flag on it).
Previously this would include multiple descriptors with the same
binding, which isn't allowed. Instead, just reuse the inter-stage
tracking/merging for intra-stage resources as well.
Files are created with 664 (though usually modified by umask).
Directories are created with 755 permissions.
Main motivation is to allow adb to access files on Android 12+
This allows them to be initialized/destroyed from multiple threads in
any order. Previously, the first thread to require a module had to be
the last thread to use the module, otherwise it would be destroyed too
early.
There are still a few issues. If the main thread doesn't require a
module, it won't pick up the conf.lua settings. Also graphics isn't
handling the shader cache writing properly. And I think this breaks the
headset-graphics refcounting. But these will be fixed in future
commits.
- Archive is now an object that has a refcount
- Archives are stored in linked list instead of array
- Not exposed to Lua yet, but could be in the future
- core/zip was merged into the filesystem module
- Mountpoints are handled centrally instead of per-archive
- Zip doesn't pre-hash with the mountpoint anymore
- mtime is truly only computed on request for zips
Mountpoints don't work properly yet.
- If you load an image with a non-blittable format, mipmap count will
default to 1.
- If you explicitly request mipmaps on a non-blank texture with a
non-blittable format, that's an error (rather than leaving mipmap
chain undefined or sliently falling back to 1 mipmap).
- Cubemaps can have any layer count that is a multiple of 6.
- A cubemap with more than 6 layers will be a cubemap array image view.
- This isn't perfect because it conflates regular cubemaps with
6-layer cubemap arrays.
- Enable the vk feature, handle the spv feature, add getPixel helper.