00:51mareko: anonymix007[m]: it depends on which NIR passes you run
00:57hendrikpaulson: I worked on memory management as much as I could and got it stable however things look easy now but still I am moving on as nothing happened but the freaks who put me under tyranny such as illborn people without any results will be continuously handled worldwide searched for and manhandled with force across any place in the world, some get executed too in a process since the most
00:57hendrikpaulson: poisonous snakes are weak we are already looking for a moment to drag Jack Deadman out from his public toilet Big Easy your deluded monkey who assaulted me , it’s that he is one of the list among many who dies overall. cause he ain’t gonna do much with the proportional force landed at him except die out, it’s over the years hundreds of such assaults were cowardly presented at me. so
00:57hendrikpaulson: neelix and many pop stars spamming wank tunes at my targets get just horribly beaten up etc. until that nonsense never hits me again if it does their struggles are made worse and worse etc. military supports me, underground supports me etc. really big reset will be done from planet earth, very high end losses Estonian monkeys will have its most unforgettably ill personnel having made
00:57hendrikpaulson: absurd and committed tyranny fro three decades and bit more in a row same for Jews. nonsensical monsters.
00:57hendrikpaulson: dedman
00:58mareko: have you tried asking ChatGPT about that
01:08hendrikpaulson: mareko you are wise man, I am already done with my work I only left watermark 44 there to fix against 42 , more updates I do not provide
01:09hendrikpaulson: it unstabilizes the world code is too high profile
01:09hendrikpaulson: I asked ChatGPT a bunch of things
01:09hendrikpaulson: most of what I already knew
01:13hendrikpaulson: I no longer have any new info yesterdays nouveau post established the algo I have a table written for this on paper too
01:15hendrikpaulson: currently users are interested to rip out acpi embedded controllers for x86 firmware blobs to change against oss ones
01:15hendrikpaulson: but I do not participate there
01:16hendrikpaulson: ultraviolet project affects also my MacBook through its programmable emi or something
01:16hendrikpaulson: input devices are cracked
01:16hendrikpaulson: occasionally
01:17hendrikpaulson: plausibly certain wavelength of light can disturb something deterministically
01:19hendrikpaulson: desktops do not have those issues and run on top of oss sw linux foundation and ibm project like yocto
01:19hendrikpaulson: as I am not that active anymore if someone found a fix to embedded controllers you may mail me
01:20hendrikpaulson: I have two such laptops waiting for security fixes
01:21hendrikpaulson: for both of those snb ones I bought new brand new batteries and otherwise much like those laptops
01:28hendrikpaulson: if you did not realize those were five first powers that I authored they get read out actually 32 or 4 or such amounts together before the index increases with supporting formulas
01:28hendrikpaulson: too broad subject ChatGPT is silent about such high profile methods
01:45hendrikpaulson: the truth is I am unaware why that hits me there are many possible reasons millionaires like my dad orbit in the interesfields of private investigators and legal forces too, much seems like currently handling this fw is thing I do not have time for, it’s painful and hard task and coreboot is supported only for some ddr memory bars
01:47hendrikpaulson: core boot is pain and due to disability money removal I am contracted to do daily job next week
02:16hendrikpaulson: I understood nothing about the people in Cambodia either, the old tricks landed with crankgangsters dickpics and flashers and humiliations with using their known sluts, they appeal that I have heal none of this was my problem those are legendary idiots whose tricks most local people here know I am not going to negotiate with such, and I have nothing to heal from such except the
02:16hendrikpaulson: injuries of physical ones which just can’t be healed from. some retarded talks as to how I do not love myself, not worth to ever advise to listen to such hoe trash.
08:18MrCooper: mareko: don't engage with them, can only make things worse
10:34anonymix007[m]: mareko: it's enough to call spirv_to_nir and nir_to_spirv sequentially to trigger this. I don't think these functions should be running any passes which would do something like this.
10:34anonymix007[m]: Should I file an issue with more details?
11:57Tom^: im trying to debug using INTEL_DEBUG= and im seeing an awful slow "1376,6892,1119665160,0,1,copy,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,4689.479,1369.947" at each start of the frame. is there any way i can pin point a bit more why its slow? the gldrawarrays is fast until next frame and that slow copy shows again
12:03Tom^: using INTEL_DEBUG=noccs does make it a lot faster
12:37dj-death: Tom^: clearing compressed surfaces usually requires pipeline stalls
12:37dj-death: Tom^: INTEL_DEBUG=nofc should help too
12:39Tom^: dj-death: hm so does wayland compositors in general filter out compressed modifiers?
12:40Tom^: i guess thats more of a wayland compositor question but it feels like its getting stalled because of those CCS mods then
13:00zamundaaa[m]: [@_oftc_Tom^:matrix.org](https://matrix.to/#/@_oftc_Tom^:matrix.org): compositors generally don't filter any modifiers. It's an opaque list
13:18ccr:blinks.
13:28Tom^: zamundaaa[m]: hm fair enough.
13:49Tom^: dj-death: interestingly nofc didnt help much, but makes sense since there isnt much glClear going on, is some other kind of stall going on here
13:52dj-death: Tom^: yes there is
13:53dj-death: Tom^: the pixel shader doing the fast clear can't run in parallel with normal pixel shaders
13:56Tom^: actually comparing compositors, kwin doesnt even trigger a copy at all, and its immensly faster
14:04zmike: happy new year
14:16pac85: Happy gnu year
14:21glehmann: zmike: welcome back to the gallium mines
14:25zmike: thanks for keeping the canary burning for me
14:29Tom^: zamundaaa[m]: checking kwin's gbmgraphicsbufferallocator.cpp what's the recommended BO mechanism to pick a scanout format? is that even a thing? all it seems todo is set USE_SCANOUT and USE_RENDERING and call it a day
14:34MrCooper: for scanout formats you need to check the KMS plane IN_FORMATS property
14:38zamundaaa[m]: [@_oftc_Tom^:matrix.org](https://matrix.to/#/@_oftc_Tom^:matrix.org): format sorting is in OutputLayer::filterAndSortFormats
14:39zamundaaa[m]: Basically KWin sorts bpc 10>8>16, or if the user wants that, 16>10>8, and within a bpc group by alpha and bpp requirements
16:18Tom^: hm IN_FORMATS is matching, same with gbm modifiers/format and eglcreateimagekhr. i manually force filtered them out to not use CCS and use Y_TILED which they become when doing INTEL_DEBUG=noccs but im not seeing the same speedup as the noccs var, back to square one, can i debug this better somehow?
17:03mareko: anonymix007[m]: nir_to_spirv is for zink, I'm not sure it would work outside of it
18:02zf: is there any penalty to creating images with VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT versus just COLOR_ATTACHMENT?
18:11mareko: only for Z/S on AMD
18:14anonymix007[m]: mareko: I came across this problem with zink initially, but it can be reproduced with just these two functions
18:15cwabbott: anonymix007[m]: nir to spirv outputs vulkan spir-v and vulkan doesn't have the concept of uniforms or uniform locations
18:17kisak: what's the issue? NIR is an optimization oriented intermediate representation. I don't think it matters that you don't round trip unaltered since we generally always want a perf win.
18:18cwabbott: its only used by zink and gallium translates uniforms to a UBO internally before even hitting zink
18:20zf: thanks
18:34anonymix007[m]: kisak: I have SPIR-V shaders which are then converted to NIR and passed to zink. It produces SPIR-V shaders from NIR and these appear to be broken and result in broken colors
18:35anonymix007[m]: cwabbott: when I'm out of ideas about what could be wrong with this.
18:35anonymix007[m]:uploaded an image: (46KiB) < https://matrix.org/oftc/media/v1/media/download/AQQhoIDdeWoq3UpjKqhNQ2U96HogwmIO8Ae1VQrDDGaGL2_NDp0VmmPdYyl3amlfUX5_aLo6tPQJFG7edhYZxGtCeb14oh2wAG1hdHJpeC5vcmcvVlpUTmNCakZTcGhZZ1Zsa1NDY2xEcUlX >
18:37anonymix007[m]: For the reference, the left window is what I see after replacing shaders with the output from nir_to_spirv in the triangle sample.
18:45anonymix007[m]: I also see "layout(location = 0)" for both color and position inputs of the fragment shader and this probably aligns with the image
18:50anonymix007[m]: Here's what the shaders look like: https://paste.debian.net/hidden/0651b29d
19:00mareko: Vulkan SPIR-V and GL SPIR-V are slightly different I think
19:25anonymix007[m]: These output shaders should be Vulkan SPIR-V (as expected, these would be produced by zink after all), the input also were Vulkan: https://paste.debian.net/hidden/a64ec961
19:36jenatali: Looks unrelated to the shaders to me
19:38anonymix007[m]: The only difference between left and right triangles are these shaders. I don't see what else could be wrong
19:46jenatali: In the left triangle, green is in the bottom left and bottom right vertices, where the right triangle has blue in the bottom left. I don't really see how the shaders could change that
20:00anonymix007[m]: I *think* fragment shader just reads the position instead of the color (which should be at location=1, but it is miscompiled to location=0 which is the position) and writes it into the output color.
20:06glehmann: location 0 is not the position, which is entirely seperate and uses no location
20:08jenatali: Oh, yeah there's the problem: layout(location = 0) in vec4 _8; layout(location = 0) in vec4 _9;
20:08jenatali: Those should have different locations
20:08jenatali: In the VS
20:13jenatali: Would've been much more obvious using any other triangle layout instead of this right triangle with (1, 0), (0, 1), (1, 1)
20:15anonymix007[m]: Now the question is, why does spirv_to_nir followed by nir_to_spirv zero out the location?