Let a draw run its own queued shader translation #1714

Merged

jarynclouatre merged 1 commit from fix/translate-on-wait into main

2026-11-10 14:48:22 +00:00

jarynclouatre commented

2026-11-10 14:23:14 +00:00

(Migrated from github.com)

Testing: RTX 4070 Ti Super, driver 621.14, Windows 11, Ryzen 7 9800X3D.

Build: on 88b554e the Windows DLL builds and tests/test_jobs_wait_runs_queued.py passes (clang on Linux; its source check now also covers the two translation pushes).

Route: the scripted 10-minute route from #1429, first visit, each run from the same fresh folder state. On 7d1562d and 779bdcf, 6 of 10 runs (main, and main with #1586 and/or #1627; three of the four without a stop had extra logging on) had one draw stopped for 4.9 to 7.8 s, most often in Hyrule Field right after a burst of new programs. The frame line counted the stop as a wait for shaders or pipelines while translation stayed at a few milliseconds a frame, which is time in the queue, not in translating. I did not catch one with the job itself logged. With this change on top of #1586 and #1627, 0 of 3 runs had a stop over 1 s:

	#1586 and #1627	with this
time lost against 60 fps, s	26.2	18.0, 17.1, 17.5
longest stop, s	7.1	under 1
Hyrule Field: time lost, s	10.8	3.3, 2.7, 2.9

It does not depend on those two; main showed the same stop (5.9 s in one of its two runs).

Refs #995

#1129 lets a draw that waits for its pipeline run the build itself when the job is still queued. The translation of a program met in play is pushed without its flag, so a draw that has to wait for its program (its targets hold no earlier picture) still waits for every job queued before it. On arrival in a new area those are pipeline builds and stage libraries at 0.5-2.5 s each on four workers. The graphics and mesh translation jobs now carry their program's ready flag, so jobs_wait takes the job out and runs it on the waiting thread, as it does a pipeline build. A translation is a few milliseconds of CPU work. Testing: RTX 4070 Ti Super, driver 621.14, Windows 11, Ryzen 7 9800X3D. Build: on 88b554e the Windows DLL builds and tests/test_jobs_wait_runs_queued.py passes (clang on Linux; its source check now also covers the two translation pushes). Route: the scripted 10-minute route from #1429, first visit, each run from the same fresh folder state. On 7d1562d and 779bdcf, 6 of 10 runs (main, and main with #1586 and/or #1627; three of the four without a stop had extra logging on) had one draw stopped for 4.9 to 7.8 s, most often in Hyrule Field right after a burst of new programs. The frame line counted the stop as a wait for shaders or pipelines while translation stayed at a few milliseconds a frame, which is time in the queue, not in translating. I did not catch one with the job itself logged. With this change on top of #1586 and #1627, 0 of 3 runs had a stop over 1 s: | | #1586 and #1627 | with this | |---|---|---| | time lost against 60 fps, s | 26.2 | 18.0, 17.1, 17.5 | | longest stop, s | 7.1 | under 1 | | Hyrule Field: time lost, s | 10.8 | 3.3, 2.7, 2.9 | It does not depend on those two; main showed the same stop (5.9 s in one of its two runs). Refs #995