Fix an issue where temporary textures could be reused too early by a different thread.
authorSteinar H. Gunderson <sgunderson@bigfoot.com>
Sat, 15 Jun 2019 17:55:46 +0000 (19:55 +0200)
committerSteinar H. Gunderson <sgunderson@bigfoot.com>
Sat, 15 Jun 2019 17:55:46 +0000 (19:55 +0200)
commiteb8cf910538590de513a07ab02ea79605b912192
treefe552925483bc2f8a5a6365db9f9127f9104c742
parenteff011224abc5dc81f801f3ea44572287a55bcac
Fix an issue where temporary textures could be reused too early by a different thread.

When an EffectChain is done rendering (ie., has submitted all of the GL
rendering commands that it needs to), it releases all of the temporary
textures it's used back to a common freelist.

However, if another thread needs a texture of the same size and format,
it could be picking it off of the freelist before the GPU has actually
completed rendering the first thread's command list, and start uploading
into it. This is undefined behavior in OpenGL, and can create garbled
output depending on timing and driver. (I've seen this on at least the
classic Intel Mesa driver.)

Fix by setting fences, so that getting a texture from the freelist
will have an explicit ordering versus the previous work. This increases the
size of ResourcePool::TextureFormat, but it is only ever used in a private
std::map. std::map is node-based (it has to, since the C++ standard requires
iterators to it to be stable), and thus, sizeof(TextureFormat) does not factor
into sizeof(ResourcePool), and thus, there is no ABI break. Verified by
checking on libstdc++.
resource_pool.cpp
resource_pool.h