sumoon has quit [Remote host closed the connection]
dubiousness has quit [Remote host closed the connection]
sumoon has joined #zink
dubiousness has joined #zink
sinanmoh- has joined #zink
sinanmohd has quit [Remote host closed the connection]
pac85 has joined #zink
<pac85>
So far I haven't tackled async compilation of variants (lots of time has been eaten by the shader passes). I was considering a few alternatives. I guess the first point I'd like to have clear before I explain more of my plans is whether entire pipelines should be created asynchronously (so updating module cache+pipeline compilation in the job) or whteher GPLs should be created for variants and fed through the current logic (so
<pac85>
fast linking at draw time)
<zmike>
it should use the same mechanism that non-legacy pipelines use
<zmike>
i.e., precompile only the libs/objects and fast-link at draw-time
<pac85>
makes sense. Now regarding the shader module creating though. I'd imagine it should also happen in the async job right?
<zmike>
right, it should all go through the same entrypoints that are used now
<zmike>
I'd think for the precompile path it could work something like:
<zmike>
* for normal execution, create all pipelines as they are created now
<pac85>
Something that worried me is that the modules cache is not thread safe right? I'd imagine I should add add an entry for the module in the main thread and then populate it in the job?
<zmike>
* when first legacy feature is seen, begin additionally creating legacy pipelines during precompile (yes, this will technically stutter, but it will almost certainly happen during some load screen and will improve timing for non-legacy use)
<zmike>
what do you mean "modules cache"
<pac85>
prog->shaders_cache
<zmike>
ah yes
<zmike>
the reason it isn't is because the main thread waits on the precompile fence before proceeding to pipeline creation
<zmike>
so it's effectively threadsafe, even if there is no lock
<zmike>
so with the legacy pipelines, I'd expect it to work the same way, where legacy pipeline shaders/modules would get created in the same place so that the precompile fence would gate those too
<zmike>
that sound reasonable?
<pac85>
Yeah sorry I was goinf through the code to make sure I understand
<zmike>
sure, no rush
<pac85>
When you say "legacy pipeline shaders/modules would get created in the same place" what do you mean by "in the same place"?
<zmike>
hm
<zmike>
thinking on it again, I think maybe this idea could be streamlined further
<pac85>
mmm I wonder if we are talking about the same thing. The uber emulation objects are compiled when regular precompilation happens, this is already in place. I was talking about compiling specialized shader variants that would then replace the uber shader.
<zmike>
ah ok, we weren't talking about the same thing then
<zmike>
I was imagining that would happen through the usual mechanism too
<zmike>
by going through zink_gfx_program_compile_queue
<zmike>
the somewhat tricky thing there is going from the ubershader nir to the optimized nir since that would require keeping the (serialized) nir for both types of shaders around
<pac85>
Btw I get what you where suggesting for the uber shader now. Yes I'm pretty much already doing it (excect conditioning it on whether a legacy features have ever been seen, but I had that planned)
<zmike>
cool
<pac85>
So for the specialized shaders, do you think we should build entire pipelines asyncrhounsly directly? So no GPL
<zmike>
no, we still want gpl
<zmike>
ideally this shouldn't add any new mechanisms for compiling shaders/pipelines
<zmike>
no GPL means requiring either full ds3 (which very few drivers support) or shader objects (which only nv supports) and neither of those options are desirable
<pac85>
Yes that makes perfect sense. So the thing is that we only ever generate shader variants synchrounsly right now right? The reason I was concerned about prog->shaders_cache is that we now need to do something like `update_gfx_shader_module_optimal` from the cache thread
<zmike>
why is that needed?
<pac85>
When do we generate the modules for the specialized variants? Drawtime?
<zmike>
ahh I see what you mean
<zmike>
this is the tricky part that I was mentioning
<zmike>
there is currently no difference between unoptimized and optimized shader modules
<pac85>
exactly
<zmike>
hm
<zmike>
okay, how about this:
<zmike>
* when creating the shader modules, have a new array dim to prog->shader_cache for [nonlegacy|legacy], synchronously add an unpopulated zink_shader_module to it with a fence and enqueue the nir compilation
<zmike>
* once that job is done, zink_get_gfx_pipeline() can get a new template for USE_LEGACY for programs using legacy features, and it can have a matching hash table dimension in prog->pipelines
<zmike>
* similarly, prog->libs can get an array dim for the GPL libs in order to continue using the same mechanics there
<zmike>
which should maintain all the 1:1 relationships that currently exist for all those things, including being able to compile optimized variants from each zink_gfx_pipeline_cache_entry
* zmike
squints
<zmike>
did that make any sense?
<pac85>
Yes! Sounds great! It is similar to what I was planning to do (at least the creating an unpopulated cache entry and populating it later)
<pac85>
Thanks!
<zmike>
👍
<zmike>
basically the codepaths for compiling all this stuff are already very complex, so ideally we want to avoid adding anything new/exciting there if possible
<pac85>
One small thing I wasn't (and still aint) sure about is where to put the fence. Should I just throw it inside zink_shader_module?
<zmike>
yep
<pac85>
Great! I'm getting into implementing that now. Thanks again!
<zmike>
antonino 💪
<pac85>
😊
<zmike>
pac85: actually one minor tweak: I think instead of doing extra array dims you can just add new variables like legacy_$name
<zmike>
to avoid unnecessarily growing array dims that will never be used