04:14gilimanjaro: Why abortion leftover based suicidal crook tyrans such as airlied do not get real followers in this world is already answered in that same sentence. Jewish crooks get followers among jewish crooks, and we put them onto a pan soon as told, and cook them, otherwise they will eat us, yes i have followers everywhere i go, and the Finnish anus sluts are overwhelming to be gotten rid of, since
04:14gilimanjaro: i have so much better women you can keep those anuses, it's a public disgrace and spam and my reputations dirtying, naming such as my connections or wives, if they come to my territory with their fellon negros and scum brother vikings and other africans, they get killed as jews , long life otherwise elsewhere they have with scam niggas and their scum based suicidal crank gangsters of scam
04:14gilimanjaro: and theft. Trannies and LGBT and such as angry fuck crocodiles like laura and gloria is the tops you can ever score anyways, such shit our businesses have banned due _their_ abuse i had nothing to do abusing them, i want not to know such nor to deal.
04:18airlied: case nir_call_op_
04:18airlied: oops
04:18HdkR: case nir_subroutine_return:
05:25jnoorman: anholt: thanks, and nice! will give that a spin.
09:54mripard: mlankhorst: ping?
10:34karolherbst: mareko: some users have been reporting that on APUs rusticl reports low memory, reason is mostly that I only report "total_device_memory" from "query_memory_info" atm. I was wondering if radeonsi could set `uma = true` on APUs and then rusticl could report total_device_memory + total_staging_memory? Not really sure what's the best way to go about
10:34karolherbst: this, because I don't want to do this for discrete GPUs, but atm radeonsi always sets uma to false
10:36karolherbst: could also add a new cap that indicates that frontends should report both values together as the available GPU memory
10:37karolherbst: but then reporting the device as dedicated is also not quite correct...
13:20zmike: mareko: how does symbol resolving for GL symbols work when glthread is enabled/disabled? I'm trying to untangle all this trickery and it's very complex
13:21MrCooper: not sure offhand why glthread would make a difference for that?
13:21zmike: I'm trying to comprehend how e.g., an app resolves glDrawArrays in mesa
13:22zmike: when glthread is enabled, the glthread marshal code is called by the app
13:22zmike: and when glthread is not enabled it goes straight to mesa
13:23zmike: I guess it's all off the dispatch table, which then gets overridden when glthread is enabled?
13:23MrCooper: application calls go via a GL dispatch table
13:24MrCooper: yep
13:25MrCooper: from the app PoV there's no difference
13:25zmike: right, okay
13:25zmike: this is starting to make sense
21:27mhenning: Is there a way to add a in internal interface for the vulkan runtime to call into a driver? (That is, a function that isn't part of vulkan or an extension)
21:47mhenning: hmm looks like there are some func pointers on vk_device