On Sat Jan 6 11:48:38 2024 +0000, Stefan Dösinger wrote:
We don't need the SQL query machinery as the cache database is a simple key-value store. My systems libsqlite.so is about 1.5 mb vs a stripped vkd3d at 377kb. That said, I think Windows recently started shipping a build of sqlite itself. If we add this to Wine vkd3d could use externally provided sqlite in both a Unix and Win32 configuration. (Interestingly msi.dll reimplements SQL queries itself, but msi has to support a bespoke file format anyway) I also tried to identify Microsoft's shader cache format, hoping that they reused an existing database system. However, no file format identification tool I tried identified it. We can change the format in the future. Our own cache can be thrown away, so we don't necessarily need to maintain backwards compatibility with existing files (although we can, if we want to). It's worth waiting and seeing how games will use ID3D12ShaderCacheSession. I don't think the API is meant to allow games to ship pre-created cache files and depending on their contents, but that hasn't stopped Windows applications before. If we run into this kind of situation we'll have to reverse engineer Microsoft's format anyway.
I find 1.5 MB a reasonable price to pay for not having to maintain our own file format and ensure that it is reasonably efficient, concurrent and robust. As you say, nowadays SQLite is becoming more and more a staple dependency that you should just be able to assume that a given system offers; but even if that's not the case, I'd say that the balance is in favor of SQLite anyway.
It's true that this is a cache, so we can just drop it whenever some corruption occurs, but my feeling is that we can have a better result with less code on our side by using the wheel somebody already invented, and to me that's totally worth 1.5 MB that can even be shared with other potential users.
My two cents, though.