At the moment, it assumes that all SSBO accesses are writes, once shaderpipeline lands we can sort out readonly accesses based on the qualifiers in the shader
This means that p3d_LightSource[n] will be fetched once off the LightAttrib, written to the matrix cache, and then indexed into by the various ShaderMatSpec. This should be significantly more efficient, but the main aim is to prepare for a new binding system in the new shader pipeline
User structs are still an exception as of now
This does require gl-immutable-texture-storage to be on, so it is not enabled by default unless that variable is set. That is not a breaking change since before this change, support was never enabled to begin with
Previously every input was fetched as a matrix. Now, every input is fetched as a vector, with matrices taking up multiple vectors. This saves a lot of copying and a lot of space in the cache.
Furthermore, integer state-based inputs can be defined (for future use)
Naming still needs to be revised, since it's called the "mat part cache" etc.
Multiview textures are now handled as a single texture context instead of as one texture context per view. This should be marginally more efficient, but more importantly, it paves the way for implementing multiview textures as subviews of an array texture down the line, which paves the way for hardware-accelerated stereo rendering (where the left and right views get rendered simultaneously to different layers of an array texture).
The difference between a multiview texture done this way and an array texture is that the views of a multiview texture will still be treated as individual textures from the shader's point of view, only the views will be sharing the same storage on the GPU. This can be done by using a feature offered by graphics APIs that is (serendipitously) also called "texture views", where it's possible to create multiple texture objects that point to layer ranges of a bigger array texture.
That part has not yet been done as doing this in OpenGL will be a little tricky due to texture views being an optional feature (so both paths would need to be implemented), but texture views are native in Vulkan (and D3D10+ for that matter), so doing this now allows me to implement multiview textures natively on the Vulkan end right from the start, and OpenGL can follow later if desired.
Furthermore, this commit includes:
- OpenGL: Overhaul texture creation and binding
- OpenGL: Change how reloading a texture with mipmaps works
- OpenGL: Use DSA in a couple of places
- OpenGL ES: Add support for buffer textures
- OpenGL: Remove support for bindless textures for now; this was never implemented in a very useful way, not used to my knowledge, and it is better to re-implement it later after the new shader pipeline lands
- DirectX9: All views of a texture are uploaded at the same time
- TinyDisplay: Support multiview textures natively (consecutive storage in memory)
- General: Per-page texture update tracking is working properly now for multiview textures
This vector implementation does is optimized for the case of having only a small number of elements, which are stored directly on the vector object rather than being allocated from the heap. If the capacity exceeds this small number, then a heap allocation is done.
This should improve performance in a couple of cases where vectors typically store 1 element and rarely more than that.
These support the most features, including cube map arrays (which aren't even supported in glslv/glslf)
This improves the quality of error messages, eg. using cube map arrays will no longer display a cryptic error about no overload of texCUBEARRAY() being available
rdb