<pac85>
the precompiled shaders never get subsituted with optmized pipelines in the ctx->dirty_gfx_stages branch unless a variant is requested*
<zmike>
that's the separable branch
<zmike>
which is only hit for non-optimized programs
<zmike>
so anything related to optimized pipelines is irrelevant
<zmike>
a separate shader program can't be optimized
<pac85>
Ok lets see if I understand correctly. separable programs don't need to be replaced with full programs however when variants are needed they still need to be because separable programs can't be updated?
<zmike>
separable programs do need to be replaced with full programs
<zmike>
that's the point of the branch
<pac85>
but why do they only get replaced when the optimal_key is not default?
<zmike>
because separate shaders only precompile default variants
<pac85>
Sorry but I'm a bit confused. In the ctx->gfx_dirty branch prog->base.cache_fence is always checked to see if the optimized program is ready, in the ctx->dirty_gfx_stages that fence is never checked, only waited for when variants are needed. Now with my new system we never need to wait on that fence (we still do for thingd not supported by uber but lets set that aside for simplciity) so I'm not actually shure what to do in the ctx-
<pac85>
>dirty_gfx_stages branch
<zmike>
it should be the same as it is now?
<zmike>
or does your ubershader thing also handle all the current (non-st) shader variants too?
<pac85>
well it doesn't but my plan was to suppor them as well. st key and zink key are not treated that differently since they have the same needs once the lowering is moved into zink
<zmike>
hm
<zmike>
well this part is specifically dealing with the zink key
<zmike>
so until that's supported it still needs to fence on the non-separable program
<pac85>
The thing is that so long as separable programs are bound there is no way to move out of the uber shader. This means that so long as the ctx->dirty_gfx_stages brnach is taken the specialized programs that get compiled in the bacmground get ignored basically
<pac85>
yes I still have the logic to eait on the fence
<pac85>
you can look at my code in my MR it should be fairly up to date
<zmike>
I'm not sure I've got the bandwidth to ctx switch into that today
<pac85>
No worries I understand
<zmike>
not sure what you mean about being unable to move out of the ubershader for separable programs
<zmike>
that's the point of the is_separable flag
<pac85>
Uhm so so long as that flag is set they don't need to get replaced? I suppose that makes sense in zink currently but in my branch the separable progs that get precompiled are always uber shaders
<zmike>
no, as long as that flag is set it means there is a background compile active for the "full" program which is not separable
<zmike>
...so yes, once ubershaders support the non-st variants then it'll be fine, but until then it still has to sync
<pac85>
Yeah I get that. The problem I'm talking about is that if variants are compiled asynchronously then both the ctx->gfx_dirty and ctx->dirty_gfx_stages (whihc is also setwhen st keys change) have to handle them, which in turns means needing the logic to replace separable programs without blovking (as well as blocking when uber doesn't support a key) in both branches basically. I hope this makes sense it's kinda hard to explain
<zmike>
yeah, I get what you mean, I'm just explaining why it doesn't work that way currently
<pac85>
Ah alright. Yeah I get it now.
<pac85>
Thanks! currently I'm trying to debug something in the new logic