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 is more idiomatic, simplifies the code, makes it easier to port to eg. HPy later on, and makes it easier to use the limited ABI (where it can be optimized to a tail call) later on
A polyfill is provided for compatibility with Python versions 3.8 and 3.9
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.
The order of arguments is now the same as in Python (with the callable first), sort and priority arguments have been added, and new tasks can be added directly to a chain
This prevents having to recalculate the internal bounds (which may be quite slow to compute, but not actually necessary if there are user bounds present) to get the nested vertices
rdb
kamgha
WMOkiishi
Disyer
Timothy Paustian
Frang
Cary Sandvig