mirror of
https://github.com/Cesarus85/ringfall-mjolnir-vr.git
synced 2026-10-17 11:00:27 +02:00
Stefan MaierandClaude Opus 5.5
a79dab53d1
The Quest's driver compiles and links a shader program the first time it is drawn with, 10 to 30 ms each, which the frame waits for: a long frame at a map's start (14 programs, 256 ms) and near its end (61 in 780 ms), seen in VR as stale frames. - port/linux/src/xgpu_program_cache.c: a linked program is written to shader_cache in the data folder, named by its sources' hash, with its binary (glGetProgramBinary), the driver that made it (GL_RENDERER and GL_VERSION) and both sources. Asked for again it is loaded with glProgramBinary when the driver, the sizes, the checksum and the sources agree; otherwise compiled as before and written again. A refused binary only falls back to compiling. - d3d8_gl.c makes its shaders with their sources and compiles them only when a program of them must be linked (shader_make, program_make), so a program from the cache costs no compile. Each program entry keeps its cache key and lists itself once per map. - Each map keeps the programs it drew with (shader_cache/maps/<map>.txt, written every 20 s while it grows and as the map goes). As a map loads (game_initialize_for_new_map, a port: hook) its programs are loaded from their binaries; after a driver update compiled again from the kept sources, in the background with GL_KHR_parallel_shader_compile where the driver has it (polled each frame, binaries written two a frame), else for at most two seconds of the load. - display.shader_cache (true) turns it off; the folder is emptied past three quarters of 192 MB or 12000 files at the start, and may be deleted. - VR's long frame line now also says how many programs came from the cache and what textures were uploaded (and decoded from DXT: the Quest has no S3TC), menu pictures decoded and render targets made, and in how long, for the menus' long frames that compile nothing. Checked: the APK builds; the desktop and web paths compile; a host harness with a mock driver went through the first run, a second run (all loaded), a driver change (compiled from the kept sources, with and without background compiling), a corrupt and a truncated file (compiled again) and a missing list. On the emulator (no binary formats) the cache logs itself off and a 4-bot game on Blood Gulch runs as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>