* Avoid deadlock when stopping video dumping
* Use static_cast, make quit atomic
* One more atomic load
* Use suggested lock instead of atomic
* Fix locking
* gl_rasterizer_cache: Mark file-scope functions as static where applicable
Prevents -Wmissing-declaration warnings from occurring and also makes
these functions internally linked.
* gl_rasterizer_cache: Remove unused local std::string variable
Despite being unused, compilers are unable to completely remove any code
gen related to the construction and destruction of this variable, since
the destructor of std::string is non-trivial.
Thus, we can remove it to reduce a minor amount of unnecessary code
generation
* gl_rasterizer_cache: Mark hash implementation as noexcept
This shouldn't throw.
* gl_rasterizer_cache: Remove unused variable in ClearAll()
* gl_rasterizer_cache: Make use of const on references explicit
While declared as auto&, these actually behave as const auto& variables,
due to the constness of the container being iterated. We can make this
explicit for readability sake.
* gl_rasterizer_cache: Resolve truncation warnings
The size is forwarded to a std::memset call, which takes a std::size_t
as its size parameter, so we can just make this change to silence the
warnings.
* gl_rasterizer_cache: Resolve variable shadowing warnings
Prevents a -Wshadow warning from occurring.
Prevents the internal buffer in the std::optional from being zeroed out
unnecessarily and instead sets the validity byte only in some
implementations.
While we're at it, we can make use of std::move to eliminate unnecessary
heap reallocations from occurring.
Allows us to avoid even more string churn by allowing the AddLine
function to make use of fmt formatting so the string is formatted all at
once instead of concatenating multiple strings.
This is similar to how yuzu's decompiler works, which I've made function
the same way in the past.
Same behavior, no heap allocation.
strings returned from glGetString() are guaranteed to be static strings,
so this is safe to do. They're also guaranteed to be null-terminated.
Some implementations can use the std::nullopt_t constructor of
std::optional to avoid needing to completely zero out the internal
buffer of the optional and instead only set the validity byte within it.
e.g. Consider the following function:
std::optional<std::vector<ShaderDiskCacheRaw>> fn() {
return {};
}
With libc++ this will result in the following code generation on x86-64:
Fn():
mov rax, rdi
vxorps xmm0, xmm0, xmm0
vmovups ymmword ptr [rdi], ymm0
vzeroupper
ret
With libstdc++, we also get the similar equivalent:
Fn():
vpxor xmm0, xmm0, xmm0
mov rax, rdi
vmovdqu XMMWORD PTR [rdi], xmm0
vmovdqu XMMWORD PTR [rdi+16], xmm0
ret
If we change this function to return std::nullopt instead, then this
simplifies both the code gen from libc++ and libstdc++ down to:
Fn():
mov BYTE PTR [rdi+24], 0
mov rax, rdi
ret
Given how little of a change is necessary to result in better code
generation, this is essentially a "free" very minor optimization.
* video_core: reduce string allocations in shader decompiler
* use append for indentation instead of resize
Co-authored-by: Mat M. <mathew1800@gmail.com>
Same behavior, but doesn't result in an allocating copy of the passed in
string. Particularly given the string is only compared against other
existing strings.
Several standard constructors generally check if objects can be moved in
a non-throwing manner (usually via std::move_if_noexcept) to preserve
its exception guarantees. This means that if these were used with
certain containers any reallocations internally would cause resource
churn, as copies would be necessary instead of moves.
This way, if they're every used in that manner, the right behavior is
always performed.
