01:43 alyssa: mareko: https://github.com/KhronosGroup/VK-GL-CTS/commit/6057d2df3332b9f234e196088267c350abfe71ea
02:54 DemiMarie: robclark: for dGPUs, would it be reasonable to just pin all pages granted to guests? I’m not sure if the async #PF mechanism makes sense for faults in GPU memory.
07:12 happiestguy: Generally you always eliminate
07:12 happiestguy: error, sorry
08:10 pq: jessica_24, if you or Louis happen to wonder why I'm not replying to VKMS/IGT discussions, I'm currently going through the new KMS color pipeline UAPI series, and I have limited time per day for KMS in general. UAPI and color spec stuff tend to take precedence for me.
09:54 eric_engestrom: mareko: I'm not sure if this is what you mean by "lacks those files", but it might be because you're on an old version and you're missing the commit alyssa pointed to
09:54 eric_engestrom: if you mean something else, please elaborate :)
11:40 karolherbst: dcbaker: do you know if anybody ever looked into integration error/warnings better with vscode through the meson extension? It would be kinda cool to get live suggestions and stuff, but I also have no idea how complicated it would be to set it all up
11:42 karolherbst: mhhh...
11:42 karolherbst: https://rust-analyzer.github.io/manual.html#compiler-feedback-from-external-commands
11:46 karolherbst: kinda sounds like the extension needs to support this natively and it's up to meson to run things in a way so it could hand this information out to vscode...
12:01 karolherbst: seems like it works for c/c++ code.. mhh, guess I'll need to figure out how to do that for rust indeed...
13:31 Ristovski: karolherbst: for C/C++ you can use mesons compile_commands.json with something like https://github.com/MaskRay/ccls/, works great
13:32 Ristovski: not sure if meson extension sets that up natively, i dont use vscode
13:37 tzimmermann: jani, a question about your edid rework. i want to implement drm_connector_helper_funcs.detect_ctx by testing for edid data. can i simply call drm_edid_read() and test the result?
13:41 pq: I just symlink meson's compile_commands.json what build dir to the src root dir, then clangd is usually happy for C.
13:41 pq: *from build dir
13:42 pq: no idea if that would be enough for meson+rust too
13:49 karolherbst: yeah.. it's not sadly..
13:52 pq: right, why would rust-analyzer even look for a compile_commands.json
13:53 karolherbst: rust-analyzer is all set up correctly, but the "problem" view in vscode needs special handling I think
14:21 happiestguy: about yesterday i am not familiar as to how stack traces are taken, maybe someone could talk about that, i speculate that it's isa dependent and very hw dependent based of cpu, calling convention and RAS maybe, however since you are at open source game entirely, maybe it's worth to program it through the interconnect instead and have hw agnostic and isa agnostic layer of that. So that pci queues would dump the trace or dma , wonder if
14:21 happiestguy: anyone has pondered about that? It would just log the program counter , like its all the same if you place that in same location in the bar. Then you could annotate the functions say some crash signal gets handed to dma, it would jump to routine to decode libs function encodings or demangle or something, so first part was statement that i am not super familiar as to how actually the stack traces are collected. You make sure that dma
14:21 happiestguy: never torns and dma compute machine sequences from cornell can do whatever you want. So second part is an idea .
14:26 happiestguy: similarly you could put part of the error recovery and scheduling to that part of the chip, and forward tags with anything that is there for hw wise in the rack or laptop.
14:34 mareko: eric_engestrom: I'm on the "main" branch of dEQP
14:34 mareko: eric_engestrom: alyssa points to vk-gl-cts, but I mean dEQP
14:44 happiestguy: that would take the technology maintainers or fixers work load to minimal though, maybe they end up getting paid fewer, imagine you have bunch of servers where something goes down it would send you a report or even error recover the whatever backend or solution.
14:44 karolherbst: jenatali: I fear that LLVM-17 will require us to link nirs instead of spirvs...
14:44 karolherbst: asI have 0 hope of this issue to be solved upstream
14:45 karolherbst: as their suggestion is just "convert to LLVM and link there"
14:46 jenatali: Fun
14:47 karolherbst: well... I have a hack for spirv-tools, but it's a hack and I think it would violate the spir-v spec to link functions of different signatures together
14:48 karolherbst: but I haven't completed the code, becuase uhh.. the code is kinda hard to follow
14:48 DemiMarie: karolherbst: I can say that Digital Mars D (the reference D compiler) has its own C compiler (including preprocessor) that is only a few thousand LOC.
14:48 karolherbst: that doesn't help us
14:48 karolherbst: like not at all
14:48 DemiMarie: I meant as an alternative to clang for OpenCL
14:48 karolherbst: does it support function overloading?
14:49 karolherbst: does it support vector types?
14:49 karolherbst: does it support all the CL bits including attributres and everything?
14:49 DemiMarie: Nope
14:49 DemiMarie: It’s meant to parse system headers for FFI.
14:50 karolherbst: sure
14:50 karolherbst: but we'd need a couple of features on top of basic C
14:50 DemiMarie: might be possible to add them, might not be
14:50 karolherbst: yeah.. but it's work I'd rather not do
14:50 DemiMarie: I just saw that people here are complaining a lot about LLVM and thought I would offer an alternative.
14:52 DemiMarie: Less “use this” and more “Walter Bright was sufficiently unhappy with existing C compilers that he just wrote his own.”
14:52 karolherbst: but it's also a tooling issue, because people will use clang to compile their stuff to SPIR-V and that's also broken
14:53 DemiMarie: Yeah, that will need to be fixed in LLVM.
14:53 DemiMarie: I guess I was thinking that Mesa already has a compiler for GLSL, why not add another one?
14:55 Calandracas: using clang to compile to spir-v is not recommended?
14:55 karolherbst: it's broken with llvm-17
14:55 karolherbst: like...
14:55 karolherbst: for linking purposes
14:55 karolherbst: llvm-17 doesn't have typed pointers anymore
14:55 karolherbst: so on an IR level you don't know what pointer arguments to function actually are
14:56 karolherbst: so you can't emit the proper type for spir-v
14:56 karolherbst: as long as you don't have to link it's all fine
14:57 Calandracas: oh so its only a problem if you're linking the spriv into another executable?
14:57 karolherbst: yeah
14:58 karolherbst: nobody else runs into it, because all other CL impls rather translate from spir-v to LLVM IR and link on the LLVM level where none of this matters
14:58 karolherbst: but uhhh...
14:58 karolherbst: I'd rather not do this round-trip for rusticl
14:58 DemiMarie: LLVM IR is not a good GPU IR
14:59 Calandracas: well thats the point of spirv :P
14:59 karolherbst: the thing is, that in mesa most drivers don't use LLVM for codegen, but we translate from spirv to some internal IR to backend stuff
15:01 karolherbst: jenatali: maybe we should just import the spirv-link code and hack it up, so we don't have to bother anybody with whatever hacks we'd use...
15:01 karolherbst: yeah... maybe I just do that instead...
15:01 karolherbst: it's a pain, but... whatever
15:02 DemiMarie: Doesn’t this mean that LLVM is emitting incorrect SPIR-V?
15:02 karolherbst: that's correct
15:02 DemiMarie: LLVM isn’t one of those projects that will just revert the offending change, though.
15:03 karolherbst: yeah, they won't
15:03 karolherbst: it's like a big rework on their IR
15:03 jenatali: karolherbst: I don't really have strong opinions here
15:03 DemiMarie: Someone from Azul wrote that nobody has ever successfully used LLVM as a black box. Anyone who uses it will run into LLVM bugs and they will need to fix them.
15:04 karolherbst: yeah.. I'll just import the linker, it's not a lot of code and doesn't see a lot of changes...
15:04 karolherbst: it's pretty self contained tbh
15:08 happiestguy: hardware agnostic or isa agnostic stack traces could be useful for super execution engine too, and in that case there are more routines that have to be stable all the time, like traversing the graph of intermediate results, and some routines are for pushing the io, but dma chipset is not going to hang AFAIK like cpu would or gpu, so it some substance of thinking the least, whether you see that beneficial. the new format of single
15:08 happiestguy: stepping is pc based, it has no hardware isa specific registers, so if i implement this, i push io so that downconversion forwards the results to two separate logics, in other words you call two times the value to two different pc's , io you call always this way, so its fully automatic, dma logic in pipelined fashion writes them, so value says how many ios to write and dma writes them all, and if you enter the debug flags it can dump
15:08 happiestguy: all virtual dest registers for every pc , cause there is no point to support isa specific registers, so many arch to maintain otherwise. There are in the end two outputs the main debugger output is showing the registers, and hash debug output is showing virtual registers.
15:13 alyssa: mareko: dEQP lives in vk-gl-cts nowadays though?
15:15 alyssa: karolherbst: ack on vendoring spirv-link yeah
17:04 thenicestman: so what estonians arranged in cambodia was, that new generation of khmers and all this trash in the worldd you none ever wanted to see, king pins of porn and their sluts were screaming in public places about wank worded songs, making solid indications to of that along with appearances of mine, so called brainless bangers from all around the world went along with that, so khmer and united states local powers with fishermen nets captured
17:04 thenicestman: them, aussies, south-africans, nigerians, finnish , estonians all that criminal deluded shit, caused every star and all people not to visit cambodia anymore after i left, so the expectation is , that all those people will be executed, some by cambodian powers and world goes also against this scam, estonians will be murdered by local russians and so it goes, cause this shit is worth treatment alike, they injured me not once and projected
17:04 thenicestman: complete fraud into world, tourists do not like that, and cambodia is out of visitors horizon now, none wants to go there anymore, this shit gonna be treated i gotta be honest with you they knocked out many people already doing that, and the extorter whores they are toothless porn heros today, and none even wanted to initially medicate them after assault, cause they assaulted me so many times ontop. Whatever the knock out paul wise
17:04 thenicestman: aussie is saying i do not care, he gets executed as soon as he drops his nose into vacation eras again.
17:06 CounterPillow: #define DRM_FORMAT_Y0L0 fourcc_code('Y', '0', 'L', '0')
17:06 CounterPillow: excuse me
17:09 zmike: mareko: great news
17:09 zmike: I have fixed your nemesis
17:09 zmike: KHR-Single-GL46.enhanced_layouts.xfb_capture_inactive_output_component
17:10 zmike: errr...well, I made it POSSIBLE for it to be fixed, anyway
17:10 zmike: I think you're still (pre-opt_varyings) doing something wrong
17:27 thenicestofthemall: and this code i have had anyways , but i have not cleared the pille of vulnerabilities to implement it to myself cause i do not share it, about those dudes in cambodia, they wanted to buy the hotel, but in reality they were short of all the money to do that, but continued to give empty promises, and you are only good at saying how you fuck my wife, who was just a abnormal finnish cow, nothing technical you even know
17:27 thenicestofthemall: anything about, and for trashing me so deep and lame during vaccation and harassing all the world tourists away, you get executed if you continue along the lines with that borderline monster, you are not allowed to do such things, and i do not deal with human shit, its that trash laura gloria lesbian whore bisexual human shits who did that, i threw them out from our hotel, but the so called owner who owes million dollars to
17:27 thenicestofthemall: my dad, wanted anal from the cow. And threw out me, but he is as much penniless trash as everybody else who scared the customers away. And as much as monster criminal as you, so he gets handled soon as as bitch did. There were lots of dead bodies there already who claimed how they fuck my wife.
17:27 thenicestofthemall: its only garbage what you talk
19:11 eric_engestrom: mareko: oh, the project that became the cts? I had no idea it was still getting separately dev'ed
19:15 eric_engestrom: mareko: if you want to patch things to make that deqp work too I have no objection, but I have no interest either so I won't write that code :P
19:19 eric_engestrom: mareko: I assume this is about the `src/gallium/drivers/radeonsi/ci/radeonsi-run-tests.py` part of 78ea3bb43dc37013c3ab87c261ef5987d5e876fa; it should be trivial to have a simple "does the file exist at that path, then pass that, otherwise pass that other path"
19:25 airlied: .
20:00 mareko: alyssa: since when?
20:00 mareko: alyssa: how do I build deqp there?
20:01 mareko: it has only glcts and glescts
20:01 mareko: no branches or tags for deqp
20:01 zmike: just build from main
20:01 zmike: and you get both
20:02 mareko: zmike: I still need 2 build directories for gl and gles
20:02 zmike: what?
20:02 zmike: why?
20:02 mareko: different tags I guess
20:02 zmike: I guess if you're intentionally building the tags?
20:02 mareko: no
20:02 zmike: but main should contain everything
20:03 mareko: zmike: need -DGLCTS_GTF_TARGET=gl or gles32
20:03 zmike: GTF isn't required for ES though
20:03 zmike: I don't think I've ever even tried to run it
20:04 mareko: why is it even an option then?
20:04 zmike: historical reasons?
20:05 zmike: there is currently an effort to port the kc tests which have no core cts coverage to core
20:05 zmike: and then kc will probably get deleted or something
20:07 mareko: zmike: how do you cmake glcts to get everything?
20:08 zmike: -DDEQP_TARGET=x11_egl_glx -DGLCTS_GTF_TARGET=gl
20:08 zmike: for x11
20:08 zmike: can also DEQP_TARGET=wayland or surfaceless
20:08 alyssa: note surfaceless doesn't work with the EGL or Single-context tests so you lose robustness coverage
20:09 zmike: yep
20:09 alyssa: mareko: the 2 build dirs thing for gl/gles is annoying but only actually matters when submitting GL+GLES to khronos
20:09 mareko: if I do that, I get:
20:09 mareko: -- GLCTS_GTF_SUPPORT_OPENGL = ON
20:09 mareko: -- GLCTS_GTF_SUPPORT_GLES32 = OFF
20:09 zmike: right
20:10 zmike: but you don't need GTF for ES
20:10 zmike: if you really want to run those tests you need multiple build dirs
20:10 zmike: but again, you don't need to
20:10 mareko: why not?
20:10 zmike: it's not a requirement
20:11 mareko: zmike: are they the same tests as gl or why?
20:11 zmike: no clue
20:12 zmike: like I said, I've never run them
20:12 zmike: I'd guess it's just swizzling API entrypoints to use ES in existing tests
20:13 mareko: we have different failures in gles than in gl
20:13 zmike: huh
20:14 zmike: well like I said, they're not required
20:14 zmike: I think we even dropped the GTF requirement for big GL with a CTS release a year or two ago?
20:14 mareko: what is GTS?
20:14 mareko: *GTF
20:14 zmike: kc?
20:14 zmike: the thing we're talking about
20:15 mareko: ok
20:15 alyssa: zmike: btw i'm deleting all my layer ID code now
20:15 zmike: do it
20:15 alyssa: i think this is thanks to your spec change
20:15 alyssa: or maybe i just did bad at r/e the first time
20:15 alyssa: P
20:15 alyssa: :P
20:16 alyssa: (It's always thrilling & terrifying when I use hw features that the prop driver doesn't, given i have no docs.)
20:19 alyssa: I don't know why I thought this didn't work. I remember trying it.
20:32 alyssa: Oh well, won't look a gift horse in the mouth
20:38 Ristovski: but perhaps he has more gifts
21:03 alyssa: so true
21:04 ccr: a pinyata full of confetti and candy?
21:22 mareko: eric_engestrom: where did you get the caselists in https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/ci/deqp-radeonsi-stoney.toml?ref_type=heads ? both glcts and deqp repositories lack them
21:25 mareko: alyssa: ^^
21:25 mareko: zmike: ^^
21:25 zmike: external/openglcts/data/mustpass
21:25 zmike: something like htat
21:25 zmike: that's from the main cts repo
21:26 mareko: zmike: why are the paths different in the toml file?
21:27 zmike: because in ci they get copied from other places
21:33 mareko: I see, thanks
22:23 Lyude: I assume this is a no but is there any way I could figure out where a message from the kernel log is getting printed if I both: can't grep for it (basically every word in this message appears to be through multiple layers of macros, or some sort of printf arg), and the kernel's not spitting out this info already in the message?
23:01 alyssa: Lyude: ouch
23:05 Lyude: alyssa: yeah haha, seems like a good case for us to be adding that info to messages we print from the kernel by default