- Allows the compiler to devirtualize the get_hash_impl call, in theory
- Reduces the overhead of checking the configuration variables every time in return_new
- Avoids recalculating the hash on calling get_unique
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 hashes are used in various places in the Panda codebase (for integrity checks, not for crypto), so using an internal implementation allows retaining this functionality when building Panda without OpenSSL.
Based on the following public domain implementation:
https://github.com/B-Con/crypto-algorithms
OpenALAudioManager::update iterates through all currently playing sounds
via a std::set / phash_set object, _sounds_playing.
If a stream queue corruption was detected during OpenALAudioSound::pull_used_buffers,
the logic added in a895890 would call cleanup() on
the sound if we could not successfully locate the target buffer and log an error.
However, the act of calling OpenALAudioSound::cleanup would lead to calling
stop() (since the sound was actively playing). In OpenALAudioSound::stop(),
we would then proceed to call _manager->stopping_sound which would erase
the current sound from _sounds_playing (while we still held an iterator
to it). Per STL standard and real-world observation, std::set::erase
will invalidate the current iterator held in update (https://en.cppreference.com/w/cpp/container/set/erase).
This leads to a segmentation fault when we attempt the next iteration on the loop.
To resolve this, let's ensure we don't hold onto invalid iterators during the updating of playing sounds.
Fixes#1452
rdb
max
LD
Brian Lach
git2323
John C. Allwein