02:28Lynne: is one truly unable to get the raw uint representation of VK_FORMAT_R16G16B16A16_UNORM?
02:29Lynne: the validation layer says "the descriptor requires UINT component type, but bound descriptor format is VK_FORMAT_R16G16B16A16_UNORM."
02:30airlied: you'd probably have to alias it
02:32Lynne: whyyyyyy
02:32Lynne: isn't this why we have image views?
02:41Lynne: MUTABLE fixes it, but now I need to keep track of each representation of each format
03:58janiscicka: so once again the collision amount grows with one operand being small and other big such as 1 and max-1. where as it shrinks where they are 1 and 1, then only collision is 2 and 0 per sum 2. So altogether when the fixed 561 value is received and once more encoded, there can be only one realization and hence zero collisions for all. so when 6+1=7 561 encoding can do any of the 1+6 2+5 3+4
03:58janiscicka: 0+7, but which one realizes? Well that depends on the other operand and intermediate arithmetic of it -- last which is internal sum. The secret is behind the fact that either operand is always a full power which is always present in the encoded values either operand. You know what this jewish crookface Ermine said btw? Intel and AMD is under his protectorate, hahaa a joke of the century by
03:58janiscicka: the minix nutbolt who get swatted in germany. He said, he's gonna hire a russian killer at me , i reminded him that jewbum you need money for that, trash you have none :)! So AMD and INTEL enjoy the THANK YOU warrior dog freed for their interanal relations and moneyless protectorate by jewish crooknose. Be also thankful that you have lost all the clients and domination in technology to
03:58janiscicka: arm/nvidia, cause of such crooks present overall, i also comment that many jewish crooknoses from russia were circulating mental illness sociology talks about me, so i comment they have indeed not much to do with russians, since the emphasis is on jewish crooks, they are homeless bums and tailcells of americans.
12:42ngcortes: zmike, I'm seeing a test failure on intel gen9 running zink: https://mesa-ci.01.org/gl_main/builds/8351/results/2822815714
12:43ngcortes: I think it's caused by mesa=59487e4a61e713107bfb62d5f8bd15137e0659fe
12:44zmike: ...but that's the one that fixes modifier selection on gen11+ 🤕
12:48ngcortes: zmike, that's just my guess anyway. I'll do a proper bisect
16:49ngcortes: zmike, okay i've confirmed that's the commit. i guess some of that code affected gen9 as well :/
16:50zmike: ngcortes: maybe https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31686 ?
16:50ngcortes: it looked like from the results I saw that before that commit the test in question was skipped by gen90
16:50ngcortes: *gen9
16:51ngcortes: zmike, I'll run it through CI's slick little MR tester ;) http://mesa-ci-jenkins.jf.intel.com/job/public/job/review_mr/122/console
16:52zmike: ERR_NAME_NOT_RESOLVED
16:52zmike: but I'm sure it's great
17:04ngcortes: lol
18:47karolherbst: who are the current maintainers for virgl?
18:57airlied: karolherbst: Gert Wollny
18:57karolherbst: thanks!
20:11karenw: Err, I've noticed that using the latest mesa every process has /home/karenw/.cache/mesa_shader_cache_db/part{#}/mesa_cache.{db,idx} open. That's 100fds leaking into every process. I'm assuming someone forgot to set them cloexec?
20:14benjaminl: doubling-checking my understanding of nir semantics: each storage location can be assigned to at most one var?
20:14benjaminl: (so, for example 'nir_get_variable_with_location' would be unique)
20:16psykose: karenw: looks like https://gitlab.freedesktop.org/mesa/mesa/-/issues/11810
20:18karenw: psykose: Ah, thanks. Open MR. I will keep an eye on it.
21:21DavidHeidelberg: psykose: btw. what about some nice review for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72897 ? Alpine can have lovely mesa tests now :P
21:21DavidHeidelberg: Pretty please 😉
21:23DavidHeidelberg: even better, I'll bump mesa to 24.3.5 and drop the patch which got in...
21:24psykose: i'm not involved with alpine so i'm not sure how i'd review that
21:25psykose: looks fine however
21:26DavidHeidelberg: oh, I had feeling you been historically?
21:27DavidHeidelberg: *in past
21:27psykose: sure, i was a maintainer for a few years
21:27DavidHeidelberg: oh kk :) thanks for heads up tho :) I'll ping ncopa
22:15ngcortes: zmike, http://mesa-ci-jenkins.jf.intel.com/job/public/job/review_mr/122/ results from testing your mr. maybe needs to be rebased?
22:17Sachiel: doubt he can see any jf.intel.com sites