Diamond75/Panda3DS
1
0
Fork 0
mirror of https://github.com/wheremyfoodat/Panda3DS.git synced 2025-04-21 12:59:14 +12:00
Code Issues Projects Releases Packages Wiki Activity Actions

A kissable commit

Browse source 
Minor fixes
This commit is contained in:
offtkp 2024-07-19 18:49:21 +03:00
parent 1b779cafa1
commit 78ac8d2c0d
10 changed files with 649 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

32
docs/3ds/async_shader_compilation.md Normal file
View file

@ -0,0 +1,32 @@
Async shader compilation should hide the problem of compilation stutter by using the ubershader when
specialized shaders are being compiled on a separate thread. To activate this mode, set shaderMode to hybrid
in config.toml
The way it works is the following:
A shaderCompilationThread is started, which holds its own separate OpenGL context.
The communication happens with two lock-free single consumer single producer queues, to avoid messing with mutexes and potential
deadlocks.
The configQueue, a queue that contains PICA::FragmentConfig objects. These objects dictate how a specialized shader should
be compiled.
The compiledQueue, a queue that contains CompiledShader objects which contain the compiled program.
When drawVertices happens, if shaderMode is set to Hybrid, this is what happens:
Emulator thread checks if the shader already exists in shaderCache. Only the emulator thread accesses the shaderCache, so no locks are needed.
If the shader exists and is ready (CachedProgram::ready == true) it uses it like normal.
If the shader exists and isn't ready, that means the shader compilation was queued but the compiler thread hasn't finished yet and sets useUbershader to true.
If the shader doesn't exist, it pushes to configQueue the current PICA::FragmentConfig (by copying it over) and sets useUbershader to true.
Then, at some point, the compilation thread will detect that there's configurations it needs to compile in configQueue.
The compilation thread will compile the shader and then get its binary with glGetProgramBinary. Then it will push this binary to compiledQueue.
On the other end, the emulator on every drawVertices will check if there's stuff in compiledQueue. If there is, it will use
glProgramBinary to convert the raw binary data into the program in shaderCache and set the CachedProgram::ready to true
Then, if the same PICA::FragmentConfig is needed again, it will be available in shaderCache.