ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
phire_ has joined #zink
phire is now known as Guest4585
phire_ is now known as phire
Guest4585 has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #zink
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #zink
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #zink
pac85 has joined #zink
<pac85> zmike: so last time we discussed that we would need separate progs for variants. Now doing this means that having prog->libs->libs as a set makes no sense because each prog always stores exactly one pipeline lib right?
<zmike> 🤔
<zmike> maybe? I'm super far out of context on zink atm but iirc this was to store all the variant gpl libs
<pac85> prog->libs->libs stores one element per varaint, if we have one prog per variant then that's 1:1
<zmike> right...
<zmike> it does seem that way
<zmike> I'm still not a fan of the extra cpu overhead that will come from a two tiered hash table lookup like this, but that's probably something that can be improved after the initial impl
<pac85> great, I wanted to check with you just to make sure I'm not doing things totally differently from what you imagined when we discussed them
<pac85> the hashing that becomes two tired is that for the pipelines right?
<zmike> well that's for like
<zmike> if a program changes between draws, then there's a lookup based on the shaders to get a prog
<zmike> and that will be the unoptimized ubershader prog
<zmike> and that will contain its own table of variant progs
<zmike> which are all optimized
<zmike> so once the unoptimized prog is found, then there will have to be a second lookup to check for optimized pipeline variant
<pac85> I see
<pac85> I can keep all the pipelines in the unoptimized prog hash table
<pac85> So those aren't scattered around many tiny hash tables
<zmike> hm
<pac85> That way we'd have as many lookups as before
<pac85> just that instead of looking up the lib we lookup the prog
<zmike> the issue with that is then the async creation would need to access the base prog
<zmike> from a thread
<zmike> though I guess a temp prog could be created for that and then delete and add the pipeline into a ht?
<zmike> we're getting into deep handwave territory now
<zmike> so yeah, maybe that would work indeed
<pac85> Isn't this synchronization already handled?
<zmike> kinda but also no
<zmike> the existing code only handles unoptimized variant -> optimized variant
<zmike> so the shaders are identical
<pac85> Oh yeah I see
<pac85> So I suppose for now I'll store the pipelines in the variant prog, then we can deal with this
<zmike> currently a zink_gfx_pipeline_cache_entry is 1:1 for unoptimized->optimized
<zmike> yea probably
<pac85> Thanks for the tips!
<zmike> good luck
eukara has joined #zink
pac85 has quit [Quit: Konversation terminated!]
italove has quit [Quit: The Lounge - https://thelounge.chat]
italove has joined #zink
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #zink