[23:03:12pm] <Samual> You available?
[02:16:31am] <LordHavoc> hi
[02:17:49am] <Samual> oh hey, I was wanting to discuss something we've had a bit of an issue with Xonotic (from feedback) -- Many people dislike the stutter given from compiling glsl shaders in real time, i'm curious whether there's anything good we can do to remedy this? (Like e.g. caching these compilations or such)
[02:19:59am] <LordHavoc> sure
[02:20:17am] <LordHavoc> can make a list of permutations that are needed and the next time it restarts the renderer, recompile those same permutations
[02:20:22am] <LordHavoc> caching that list on disk
[02:20:29am] <LordHavoc> doesn't speed up the compiler any though
[02:20:57am] <Samual> The goal I have is to basically fix the constant stuttering while already in gameplay
[02:21:15am] <Samual> That's the real problem, so indeed that would actually be really helpful :D
[02:21:24am] <LordHavoc> for a more aggressive solution, http://www.opengl.org/registry/specs/ARB/get_program_binary.txt
[02:22:58am] <LordHavoc> an important detail of that extension is to cache it to disk *after* it was used
[02:23:04am] <LordHavoc> because that may affect compilation
[02:23:14am] <LordHavoc> (indeed, it's basically guaranteed to depend on how it is used)
[02:23:27am] <LordHavoc> could do caching in a renderer quit scenario
[02:23:33am] <Samual> hmm
[02:23:40am] <LordHavoc> so that all observed situations are already accounted for in that run
[02:24:28am] <LordHavoc> because you'll still get new compiles silently in the driver when new state combinations are used
[02:24:42am] <LordHavoc> you want to make sure that all state that is likely to be encountered has already been encountered before dumping it to disk
[02:24:55am] <LordHavoc> state recompiles are much quicker than the initial tokenize though
[02:28:15am] <Samual> This actually wouldn't solve the issue totally though, as people would still have to compile the permutation when observed for the first time - But that means much smoother gameplay later on anyway as you wouldn't have to recompile after every single new match
[02:28:37am] <LordHavoc> right
[02:28:59am] <LordHavoc> binary shaders are vendor-dependent and GPU-generation-dependent and even GPU-dependent in some cases
[02:29:01am] <Samual> (Unless..... well, we couldn't provide a "default" cache, as it's really dependant on that on specific renderer.. right?)
[02:29:14am] <Samual> ah right
[02:30:45am] <LordHavoc> now we could cache with a hash of the driver info
[02:30:53am] <LordHavoc> so that at least for known combinations it comes precompiled
[02:30:57am] <LordHavoc> but that may be a rather large and sketchy cache
[02:31:35am] <Samual> Not worth it, probably way too many options to even make a dent haha
[02:31:55am] <LordHavoc> D3D has a somewhat different solution - the Microsoft shader compiler outputs a heavily optimized blob in a specific known format (not vendor-specific or even GPU-specific in any way), and then that gets recompiled by the driver a bit more quickly than the source would, but "a bit more quickly" doesn't mean a lot
[02:33:30am] <Samual> Ah, that makes sense -- still this would be the better solution I think
[02:34:35am] <Samual> Anyway, could you look into implementing this feature later? Doesn't seem THAT difficult but I don't really understand this all too well -- And it would certainly make a huge difference regarding performance I think
[02:34:57am] <Samual> If you don't have time, maybe divVerent could
[02:38:13am] <LordHavoc> put it on the tracker, the extension makes it pretty obvious how it should be used, take note in the tracker that shader cache writing should probably be done on quit
[02:38:51am] <Samual> Which tracker?
[02:39:36am] <LordHavoc> xonotic?
[02:40:00am] <Samual> haha just making sure, didn't know if DP had its own tracker or such :P
[02:40:18am] <Samual> but, okay, thanks for the info mate