09:40 <pac85> zmike: why does zink_create_gfx_program deserialize stages[]->blob and reserializes it into prog->blobs[]?

12:35 <zmike> pac85: because prog has to keep its own copy of the nir to do interstage i/o passes

12:35 <zmike> shaders may be used in multiple programs, so i/o can't be modified on the shaders themselves

12:55 <pac85> zmike: ah I had missed the call to assign_io. I asked because I need to avoid this being done every time a program variant is created.

12:57 <zmike> what do you need to avoid, specifically?

12:57 <zmike> I'd think that all the variant progs should be "owned" by the ubershader prog

12:57 <zmike> and so they can just reuse the same blobs (weak refs)

13:23 <pac85> zmike: yes that makes sense, currently I create the variant progs with zink_create_gfx_program so I end up with stuff I don't need. I suppose I shoudl have a separate function to create the variant progs. Another problem I have is that the uber progs can be generated from separate shaders and those end up without the blobs

13:24 <zmike> separate shaders should still take the current codepath

13:24 <zmike> so what you'll want to do there is have a two-step async compile process: 1) async compile a "real" prog which uses an ubershader 2) async compile variants

13:25 <zmike> or at least it seems to me like this would be the simplest method

13:26 <pac85> Mmm the way I had it currently is that the uber prog is either separable or real, and I never make a real uber prog when separate shaders are used. I thought this would be more efficient but it leads to this problem.

13:27 <zmike> yeah it doesn't really matter if it takes an extra couple frames to get optimized pipelines though

13:27 <zmike> compared to the extra code complexity

13:35 <pac85> Yeah I actually thought doing it this way would make it simpler because I don't need that logic to replace programs anymore, but turns out it isn't simpler. Thanks for the advice!