LÖVR uses d32f by default, but that's not guaranteed to be supported.
However, GPUs must support either d32f or d24, so we can fall back to
d24 reliably.
- You can nest texture views (make a view of a view).
- You can do transfers on views (copies, clears, blits, etc.).
- You can give labels to views.
- API changes
- Rename Texture:newView to lovr.graphics.newTextureView.
- Constructor takes a table of options (order was too confusing).
- Remove Texture:isView/getParent, since views can be used for everything now.
- Better matches what LÖVE ended up doing.
- Fix bug where :getType on a view returned parent type.
The vertex-only shader requires too much juggling of shader stage flags
and pipeline layout compatibility when e.g. binding push constants and
descriptor sets.
- Undeprecate ShaderType (it's good actually, kinda like a pipeline bind
point and more specific than having lovr trying to make sense of a
random set of stages).
- Use a default uniform block instead of push constants. The Constants
macro now maps to a uniform block declaration.
- It is no longer possible to create a shader by giving a single
DefaultShader string (you can still give a per-stage DefaultShader
though).
- lovr.graphics.compileShader now takes all stages instead of a single
stage. In general we need all stages when compiling GLSL because
default uniforms require linking across stages.
Goal is to support more combinations of shader stages, both for
vertex-only shaders and mesh/raytracing shaders in the future. In
general most of the logic that conflated "stage count" with "shader
type" has been changed to look at individual shader stages.
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.
- 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).
- 'sample' now implies both sample and linear filtering (practically always
true for all formats lovr supports)
- 'render' now includes 'blend' for color formats (also practically
always true except for r32f on some old mobile GPUs)
- 'blit' now includes 'blitsrc'/'blitdst' because lovr doesn't support
blitting between textures with different formats
- 'atomic' is removed because lovr doesn't really support atomic images yet