03:38DavidHeidelberg: rant: I wonder why there are people with developers rights, without issue ticket open for granting the access, who clearly have not much idea how even merge process works... :(
03:40yshui: zf, there's a WIP extension for present timing https://github.com/KhronosGroup/Vulkan-Docs/pull/1364
03:41yshui: maybe that's what you are looking for?
03:50mupuf: DavidHeidelberg: Sad to hear... but the process should be that people can be called out for being anti-social
03:51mupuf: that's how it has been in Mesa, for as long as I have been involved (10+ years already, jeez)
04:07zf: yshui, that's solving a different problem, and provides no way to wait for a present without explicitly scheduling it
06:05nowallchanged: I had not promised a whole lot, but things i hyped up, i delivered in some early form, but just for some redemption that i did not talk for no reason, but at the same time i did not search for a way to show that i am better or supreme, as to what MrCooper believes, it just interests me but it's the numeral systems that are so strongly laid out however i dislike being chipped and this so
06:05nowallchanged: called bio-chip technology on the same system design is how they actually own me, it's not nice and in that regard i search for some retaliation indeed, allthough originally i did not mean to cause you any defeats to show that i am better , because in computer science just the operation of powers of two's that they figured out is brilliant in hw, they all know how this presentation can
06:05nowallchanged: be cheated on, but i know too yes, so this is not the reason i was bio-chiped, gene-mutation and hidden donor for others i have been, and this indeed is abuse not merely an irc kickban or heated argument, or bringing intel marketing strategy down, it's just tremendous conspirational fixing abuse against any of the laws. So what comes out from such abusers bedactivity or mouths isn't my
06:05nowallchanged: cup of tea to enjoy, they are fucking trash in life, who parasite on donors alike, and trash them at the same time immensely. AIDS is one of the biggest such trashes illnesses they are not resillient on. It's painful to deal with scam doctors, truely painful no matter how strong i am they find a way to cause hugest issues and defend it by fraudulent backtracking.
06:58nowallchanged: it's an important corner stone to figure out, how such chips and bio-socs are being signalled, how much real memory they actually have,what battery lifetimes they offer, how extremely fast is their operation on packed arithmetic, and since the commit is very lawless i.e regulated by laws, and straight against me, harass them back with my strenghts so yes, retaliate for such activity,
06:58nowallchanged: hold them choaked. It's not a battle with other computer enthusiast or any sort of supremacy demonstration AFAIK.
07:19MrCooper: zf: FYI, GLX_OML_sync_control timestamps also correspond to first pixel out, and the Vulkan functionality is likely based on the same kernel functionality, so the timing is unlikely to be much different
07:19MrCooper: linkmauve zf: no need for CPU access to a dma-buf, just copy from it with the GPU
08:44diagnosticdrible: justice as well as large forces that grow every day to combat conspiracist and result fixers are behind my name, we gonna combat the world dominating scammers who mandate misleading regulations that they break for their own benefit and terror, also we gonna save dutch people from floods. So my behaviour there stored in form of irc logs was expected success, i have huge alliance and
08:44diagnosticdrible: people who protect me where as i protect them behind my back. So on the long run we tap all those monsters , this conspiracy is not made by universe or god, it's human action based result fixing terror, how human was made is something we do not know however, those forces who commit fraud and betrayal are hypothetically known to be of human being kind a network of greedy envious type
08:44diagnosticdrible: of self-announced kings who we make things very short and straight you have no rights to play god.
11:16K900: Caught my weird DMUB crash: https://gitlab.freedesktop.org/drm/amd/-/issues/3647
11:19zmike: eric_engestrom: what's the next branchpoint date?
11:53yshui: zf: hmm, then i didn't understand what exactly you need to do... present_timing does what glXSwapBuffersMscOML does IIUC? and present_wait doesn't really have an equivalent in GLX. can you explain exactly what wine does? does it present to an offscreen surface then wait on it with glXWaitForSbcOML?
12:23drumandtroll: I have all the modules already developed and specifications too. It was not outrun either, i was not likely the first who discovered that magic, bio-chips will be huge paranoia for anyone, they are very easy to manufacture and cheap and highly powerful to tap into abuse based people clans. I worked in mysery i lived the abuse, they ain't gonna get away from me. I am just setting up my
12:23drumandtroll: labs , during my time at social program, i have bought and also people gifted me so many mid-end computers, which are easy to fix to perform better. So even though i designed also the tcp/ip v4/v6 arp/ndp intruding systems i did not mean this to tap people, it's people who abuse others get just physically chipped and sanctioned, they will enter the jail by force. But Linus is pretty
12:23drumandtroll: intelligent though sometimes abrasive, any kernel can meet the criteria of superior systems, android dominates the world today, but as Linus said it's not at all permanent status, but i feel like intel was about to me much huger success if they had my code, their biggest mistakes with amd was not to enter the market of mobile systems, i could easily make that possible on x86 asics
12:23drumandtroll: systems and also fpga's , not sure if they had such legacy under their control, why they delay with this?
12:51eric_engestrom: zmike: mid october; sorry for being behind on this
12:51eric_engestrom: ("this" = documenting the next release cycle)
12:53karolherbst: jenatali: does dxil or d3d in general support image loads with a scalar result or is it all a vec4?
12:54jenatali: karolherbst: Textures/images in D3D can be 1-4 components
12:54karolherbst: sure, but I mean the shader load instruction
12:55karolherbst: in opencl C image_load returns a scalar value for depth images
12:55jenatali: The actual load instruction returns a 4-component struct always
12:55karolherbst: okay
12:55jenatali: Except for comparison sampling IIRC
12:55karolherbst: I guess I'll lower it inside nir_lower_cl_images then for image_load
12:55karolherbst: comparison sampling?
12:57jenatali: Shadow sampling?
12:57karolherbst: ahh
12:57karolherbst: mhhh
12:58karolherbst: so for CL_DEPTH images you could indeed emit a single component load?
12:58jenatali: You pass a float in, you get back a 1.0/0.0 per pixel that can be blended for linear sampling
12:58karolherbst: I see
12:59karolherbst: though CL_DEPTH is funky, because you can only really implement using non depth formats
12:59jenatali: FWIW in the DXIL backend for nir, we do pay attention to component counts and only "extract" the right number of elements from the 4-component struct, since DXIL is scalar they all need to end up as different SSAs anyway
12:59karolherbst: ohhh, I see
13:00karolherbst: so for you it would actually make sense to keep the image_load scalar
13:00jenatali: Yeah probably
13:00karolherbst: though you already have the same situation with tex instructions and those are already always vec4
13:01karolherbst: so I guess you already have optimization in place to ditch unneeded component loads
13:01jenatali: Nah I just had to do some weird things for an image that has both loads and atomics on it. Atomics require that the image only has 1 component from the DXIL side, so then a 4-component load doesn't work
13:01karolherbst: though tex ops are funky
13:01karolherbst: ahh
13:02jenatali: I don't really feel strongly, whatever you choose to do I can make it work
13:02karolherbst: we already have two flags on nir_lower_cl_images, I could turn it into a option struct and add another option for lowering scalar return types
13:08jenatali: Sounds probably more complicated than it needs to be but 🤷
13:26karolherbst: yeah.. maybe I just always lower it... and if somebody minds they can add a flag
13:43DavidHeidelberg: karolherbst: Heya, btw. noticed that "program@execute@global-offset@3d- input dependent" also fails across all drivers, do you expect test or rusticl?
13:47DavidHeidelberg: nevermind, found the mesa bug
13:47karolherbst: yeah...
13:47karolherbst: it's a weird bug
13:47karolherbst: people consider fixing it in the spirv translator
13:47karolherbst: Intel's official stack is also kinda affected by this
13:47karolherbst: just different
14:18Company: so, we have another "fun" issue with Mesa in GTK and I'm not sure how to deal with it:
14:19Company: 1. Mesa code uses vk_error() in error conditions
14:19Company: 2. vk_error() emits a debug report message with VK_DEBUG_REPORT_ERROR_BIT_EXT
14:20Company: 3. The spec states in https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkDebugReportFlagBitsEXT.html that this means that "the application has violated a valid usage condition of the specification"
14:20Company: 4. GTK turns that into a critical error message and certain apps abort in that case.
14:21Company: 5. Mesa driver initialization also uses vk_error() in failure cases
14:21Company: 6. Lots of apps now abort with messages such as:
14:22Company: ../src/panfrost/vulkan/panvk_physical_device.c:653: WARNING: panvk is not a conformant vulkan implementation, pass PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1 if you know what you're doing. (VK_ERROR_INCOMPATIBLE_DRIVER)
14:22Company: ../src/nouveau/vulkan/nvkmd/nouveau/nvkmd_nouveau_pdev.c:76: VK_ERROR_INCOMPATIBLE_DRIVER
14:22Company: etc
14:29alyssa: Company: imho, these are panvk/nvk/etc bugs
14:29alyssa: and each vk driver should be fixed to be quiet
14:29alyssa: devs often compile mesa with only the driver we care about so we don't notice ;)
14:31DemiMarie: alyssa: on a related note, how did you manage to make Honeycrisp conformant while PanVK isn’t? Are you just that good?
14:31Company: alyssa: would you still want it to print the error messages with some other method?
14:31K900: I don't think anyone is particularly working on PanVK?
14:31K900: Or at least was, until recently
14:32K900: It's been picking up for a bit
14:32Company: looking at https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvkmd/nouveau/nvkmd_nouveau_pdev.c for example, "NVK Requires a Linux kernel version 6.6 or later" seems kinda useful
14:36karolherbst: jenatali: fyi: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30831/diffs?commit_id=f869934f8a45466be52109be0282206ad140a52c
14:36karolherbst: maybe we should handle it inside vtn instead? mhh
16:03alyssa: Company: turnip has TU_DEBUG=startup for this
16:03alyssa: personally (ie for honeykrisp) I don't see the point
16:04alyssa: back in my GL day, drivers silently failed to load and you just dealt with it ;P
16:04zmike: they still do
16:04alyssa: =D
16:05alyssa: zmike: who'd've thunk you would outlast me on "caring about GL"
16:05alyssa: ("I'm the GL chair. I'm obligated to care.")
16:05zmike: 🪑
16:05alyssa: so true
16:06zmike: I'm helping
16:06zmike: ...he said as he landed another huge refactor that broke everything
16:08Company: trying hard to ensure virtualization will never work
16:08Company: also, GL drivers do complain
16:10Company: MESA: error: ZINK: failed to choose pdev
16:10Company: libEGL warning: egl: failed to create dri2 screen
16:11Company: but those are debug messages, not error messages
16:12Company: or GTK is smart enough to ignore GL driver complaints
16:22jenatali: karolherbst: Looks reasonable to me
16:22karolherbst: testing here seems to be happy as well
16:22karolherbst: tried on iris, radeonsi, zink, no CTS regressions
16:22karolherbst: CL_DEPTH is so silly honestly, even like intel's official stack uses a red format for it
16:23karolherbst: the main reason is, that you can't implement fill effectively otherwise, or gurantee that values aren't clamped by some internal magic
17:04zf: yshui, what we need is to be able to wait for a present to "complete" in some sense without needing to explicitly schedule it. VK_EXT_present_timing doesn't offer that. GLX_OML_sync_control provides glXWaitForSbcOML() which does
17:04zf: MrCooper: hrm, that doesn't match my reading of the spec, it says "at the completion of each buffer swap (e.g., the pixel copy has been completed or the hardware register that swaps memory banks has been written)"
17:05zf: are these guarantees functionally equivalent?
17:12zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31235
17:43soreau: hm, is there a way to see/dump the vulkan calls that zink is using?
17:45soreau: maybe VK_LAYER_LUNARG_api_dump?
17:46karolherbst: eric_engestrom: any reason why I shouldn't add entries to docs/relnotes/new_features.txt for rusticl stuff?
17:46karolherbst: just noticed this file exists a few days ago
18:01K900: Speaking of release notes
18:01K900: Where do I write a release note for packages
18:01K900: s/packages/packagers/
18:01K900: I've seen two people already get caught off guard by the new dri_gbm.so
18:14llyyr: +1 I think it'd be useful to have a meta issue or wiki page tracking notes of changes for packagers
23:58bluetail: I appear to fail to build mesa-git. I disabled a couple of options, it appears to fail to build libvulkan or so. https://0x0.st/X3nO.log
23:59bluetail: what I haven't yet tried was to disable d3d12