On Tue Jan 23 21:16:01 2024 +0000, Stefan Dösinger wrote:
This is mostly a note for myself for future reference: One quality aspect of the serialization backend is how fast the cache file is loaded into memory. I fed the a somewhat populated cache from Diablo 2 resurrected to the tests/d3d12.cross64.exe, which creates and destroys devices a lot. My simple reader did rather poorly - it increased the test runtime from ~25 to ~55 seconds with the code that actually creates the pipelines disabled. I didn't implement nor test any alternative backends yet :-)
I am adding some thoughts on sqlite here, for lack of a better place to record them:
The sqlite feature set is fairly nice for what we need. The sqlite project advertises the use as a data storage format even if the SQL functionality isn't needed. Afaics it should support partial loading from disk into memory, although I didn't verify this in practise yet.
sqlite's build system is a bit peculiar: In a first step it uses TCL and other scripts to merge all source files into one "amalgamation" sqlite3.c file. In all likelyhood we'd check that sqlite3.c file into Wine's git repo either in libs/ or dlls/winsqlite3/ itself. One complication is that the parameters passed to the TCL generators are different for Windows and Linux targets. We'd probably want to submit a patch to sqlite3 to add the ability to pass --useapicall from the Unix Makefile to upstream sqlite.
Judging by Microsoft's sqlite3.h header they use sqlite version 3.29.0. They made some adjustments to the header, mostly adding NTDDI_VERSION #ifs. I don't think we care about those differences.
If we use sqlite3 for the shader cache I think we should go for it hook, line and sinker and use the SQL query functionality to search for cache keys. I'd expect it to be more performant than homebrew code.