00:48 mareko: what's the biggest thing that NIR is currently missing besides a fully optimizing varying linker?
00:50 zmike: documentation?
01:20 tleydxdy: for gpu soft reset, would the application know it did bad? like with vulkan robustness or something similar
01:21 DemiMarie: karolherbst: any plans to purge LLVM from Mesa?
01:22 DemiMarie: mareko: what would it take for NIR to generate CPU SIMD instructions directly?
01:22 karolherbst: sadly.. no
01:22 karolherbst: it would be a lot of work with no real pay off besides dropping LLVM
01:23 karolherbst: I don't think people here want to add various CPU archs and deal with that nonsense inside mesa just to support llvmpipe
01:23 karolherbst: also having a _real_ C parser is also something nobody wants to do
01:23 karolherbst: C alone is a mess, but then you got the macro language on top
01:24 karolherbst: and then somebody would also have to manage the OpenCL C stuff with all the builtins and everything
01:24 karolherbst: just boils down to more work
01:24 DemiMarie: karolherbst: Ask Walter Bright about how hard it was to write a C parser for the D compiler. To be fair, he was the only person to have ever written a Standard C++ compiler solo IIRC.
01:25 karolherbst: I'm sure it's easy to write one that kinda works, I'm sure it's near impossible to write a compliant one
01:25 DemiMarie: karolherbst: Walter Bright had the advantage that he already maintains a C compiler.
01:26 karolherbst: well.. we don't :)
01:26 karolherbst: anyway, I think C is the simple part
01:26 karolherbst: the preprocessor is the one worrying me
01:26 karolherbst: and CL does have weirdo additions for that
01:27 DemiMarie: karolherbst: is calling `/usr/bin/cpp` an option?
01:27 karolherbst: so you can include files, but instead of looking in a filesystem you have this runtime map and stuff
01:27 karolherbst: sadly, no
01:27 karolherbst: because CL C is different
01:27 karolherbst: the semantics are more or less the same, just that you can provide "header" files as CL program objects with a header name and you have to replace that stuff at runtime
01:27 karolherbst: it's pretty wild actually
01:27 DemiMarie: I know of D and Haskell implementations of the C preprocessor
01:28 karolherbst: the question is: do they actually compile every valid source file
01:28 DemiMarie: A Rust one for rusticl would likely be ~5,000 SLoC (about the size of the D one)
01:28 karolherbst: and do it correctly
01:28 DemiMarie: The D one can handle libc headers IIRC
01:28 karolherbst: yeah, that's a 5k loc we'd have to maintain
01:29 DemiMarie: what if there was a Rust crate that implemented the C preprocessor?
01:29 karolherbst: mhhh
01:29 DemiMarie: (to be clear: I am NOT offering to implement one!)
01:29 karolherbst: then we'd also have to recreate the spirv-llvm translator part
01:29 karolherbst: or rather parsing CL C and output spir-v
01:29 DemiMarie: that said, I am more interested in the AMD backend
01:29 karolherbst: yeah...
01:30 DemiMarie: which (IIUC) is a PITA
01:30 karolherbst: I think nobody is interested in actually doing the work required to ditch llvm
01:30 DemiMarie: are there plans to ditch LLVM for the AMD backend?
01:30 karolherbst: for ACO?
01:30 karolherbst: that's up to the radeonsi driver
01:30 DemiMarie: no idea what Mesa internal code names are
01:30 karolherbst: but I think there are some looking into this
01:31 DemiMarie: What would the advantages be?
01:32 karolherbst: no llvm
01:34 cwabbott: there's ongoing work to be able to use ACO instead of LLVM in radeonsi, but it's going to be a long effort
01:34 karolherbst: yeah, and the people working on it alreayd hate me for wanting real function call support in that as well :P
01:34 karolherbst: still need to find a poor sould doing that for intels compiler for me 🙃
01:36 mareko: ACO doesn't support CDNA
01:36 cwabbott: a number of driver-specific details were implemented via driver callbacks in the NIR-to-LLVM translation pass and they need to be transitioned one-by-one to NIR passes
01:37 karolherbst: well.. lucky that I don't care much about CDNA either
01:37 karolherbst: or does radeonsi care about CDNA?
01:37 mareko: yes
01:37 karolherbst: mhhh
01:37 mareko: it's just for VAAPI and OpenMAX
01:37 karolherbst: sounds like there is still a lot of work ahead then :)
01:37 karolherbst: ahh
01:42 mareko: CDNA can't do any graphics, but it has video hw and can do postprocessing via compute
01:45 mareko: the video gallium frontends support compute-only chips with video hw
01:45 mareko: rusticl should work on it too
01:53 airlied: is there much aco needs to support cdna?
01:53 airlied: I thought it was pretty much the same compute cores
01:54 airlied: maybe an instruction or two extra
01:55 karolherbst: mareko: in theory yes, but I've experienced some bugs with the compute only blitter/copy... I have to look into it but setting COMPUTE_ONLY triggered some weirdo bugs in that area
01:56 karolherbst: but given that images with clover+radeonsi never really worked that's also not really surprising
02:00 airlied: you don't get blit if you have compute only
02:00 airlied: or you have to use a compute based blit path
02:14 karolherbst: yeah and I think the compute based on isn't entirely working alright
02:14 karolherbst: I'd have to check again
02:23 mareko: the compute blit only works to the extent required by VAAPI and OpenMAX
02:24 airlied: yeah so CL probably has larger expectations around that
02:31 mareko: resource_copy_region should work, blit isn't used by vaapi/openmax
02:32 mareko: I think I have a full compute blit implementation locally (only scaling and filtering is missing AFAIK)
02:33 mareko: (missing in the main branch I mean)
03:49 zzoon[m]: airlied: I've updated the MR for hevc decoding.. that makes it work on gen12(alderlake)
03:49 zzoon[m]: btw there are some failures of cts on gen12.. even if h264 decoding..
04:12 airlied: zzoon[m]: would be good to get some ideas of where cts is failing, but it could also be CTS bugs
05:07 kode54: neat
05:07 kode54: latest drm-xe-next kernel doesn't bring up my displays
05:08 kode54: I've already reported it
05:28 tarceri: Welp I just spent 4 hours rechecking my code and looking for bugs. All because of one little feq instead of ieq
05:29 tarceri: Can someone hit reset on today please
07:14 airlied: thellstrom: seems to be a regression with drm/ttm: Reduce the number of used allocation orders for TTM pages
07:14 airlied: build regression on ppc64
08:53 DavidHeidelberg[m]: looking at alyssa "asahi: Convert to SPDX headers", any other driver maintainer wants to follow?
09:13 pinchartl: DavidHeidelberg[m]: I thought most drivers used SPDX headers already
09:13 pinchartl: (the SPDX-License-Identifier should come before the copyright lines)
09:14 pinchartl: ah, drivers in mesa
09:14 pinchartl: I thought you meant kernel drivers :-)
09:34 DavidHeidelberg[m]: pinchartl: exactly, the Mesa drivers :)
09:39 pepp: DavidHeidelberg[m]: I plan to do this for radeonsi too
09:51 DavidHeidelberg[m]: nice :)
10:42 karolherbst: mareko: anyway, atm I'm not using the blit callback at all and I think the problems were around resource_copy_region, but I'm not 100% sure on that. I used to had wrappers for blit, but never used them. Anyway, CL doesn't really have blit operations, just some image <-> buffer copy functions and atm quite some of it is implemented in software only anyway
10:43 karolherbst: but I do want to revive COMPUTE_ONLY because that will be the trigger to enable SVM and/or use compute contexts to allow longer running kernels and stuff on some drivers
11:45 uajain: hello, I wanted to know if there's a correct way to flush the DRM request/queue, committed using drmModeAtomicCommit () with DRM_MODE_PAGE_FLIP_EVENT passed in
11:49 emersion: there's no queue, no buffering, it's a direct IOCTL
11:55 uajain: Ok. What I'm noticing is that a request (say T) is committed successfully for disabling the display pipeline - but _after_ that a request with DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK is calling the page_flip_event handler
11:55 uajain: that request is T-1
11:56 uajain: What I don't understand is - if the pipeline is disabled successfully, how come I am noticing a page flip event being generated afterwards
11:57 uajain: when there's no queuing etc.
11:57 emersion: page flip events happen asynchronously, when the page-flip happens
11:57 emersion: well
11:57 emersion: you could say that there is a queue of 1 slot
11:58 uajain: Correct.
11:58 emersion: user-space does drmModeAtomicCommit(), that programs the hw, and after vblank kernel sends the event
12:01 uajain: ok, so I really have to see if I disable the pipeline - what happens to a vblank event.
12:01 uajain: My goal is to cancel that page_flip event entirely - when I disable the pipeline itself
12:03 MrCooper: atomic KMS API offers no way to cancel anything yet
12:04 uajain: indeed, because I haven't found a way yet - after reading drm documentation and many IOCTLs description
12:05 uajain: so I guess the only way I have forwards to handle the stop/disable state in userspace and early return; in the page flip handler
12:06 MrCooper: karolherbst: GCC 13 in F38 generates a -Wdangling-reference warning about src/gallium/frontends/clover/spirv/invocation.cpp:link_program()::&bsec , does that look legit?
12:10 uajain: We got similar in libcamera as well with GCC 13 but turned out to be false positive
12:11 uajain: Upstream bug report : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
12:13 MrCooper: thanks, looks like it won't be fixed though sadly; is there any workaround?
12:13 karolherbst: yeah.. it does look kinda dodgy to warn about it
12:13 karolherbst: disabling that buggy warning then?
12:14 MrCooper: GCC bug report above says it's not fixable in the compiler, but the false positive rate is low
12:14 karolherbst: I don't agree with the reasoning, maybe we have to keep commenting on the bug saying it is widespread?
12:14 karolherbst: heh
12:14 karolherbst: famous last words
12:14 MrCooper: k, I'll disable it for now, thanks
12:14 karolherbst: according to what is the false positives rate low? nobody filing bugs because nobody uses it?
12:15 MrCooper: ("disable" as in "make it not fatal in CI")
12:15 karolherbst: right
13:33 zmike: tarceri: we've all been there
15:07 gfxstrand: dcbaker: How're you coming with meson crate support?
15:07 gfxstrand: dcbaker: I just updated my syn dep yesterday and it was a PITA because I had to re-meson 3 repos. :-/
15:26 dcbaker: gfxstrand: things are moving forward. One of the gstreamer guys is in the same position and has been fixing a lot of bugs and adding features we need
15:26 gfxstrand: Ok
15:46 karolherbst: dcbaker: so I also digged deeper into that isystem bug, and it appears when you use a dependency with `include_type : 'system'` it adds those isystem arguments. Bindgen doesn't filter those out, but normal C targets do... So now that's kinda an annoying situation
16:06 dcbaker: Hmmmmm. Okay, that is annoying. Of course isystem is just annoying because people aren’t using it for what it’s for but for it’s side effects…
16:06 karolherbst: apparently here it's when the llvm dep was flipped: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7632
16:07 karolherbst: but yeah.. I think we have to assume that isystem args are passed to bindgen and it kinda has to deal with it in a way without breaking random stuff :(
16:09 karolherbst: it's just sad that I need this to fix actual bugs :(
16:11 anholt: hakzsam: any chance you could look into the radv + pipeline cache fix regression?
16:11 hakzsam: sure
16:13 anholt: thanks!
16:39 dcbaker: karolherbst: of course. That isn't actually what -isystem is for, that's just a side effect of -isystem. I'm 50% of the way to writing patches for clang and gcc to add -iexternal which works just like -I except it surpresses warnings. Let me see what I can do about that today
16:40 karolherbst: mhh, so it would require patched gcc/clang?
16:41 dcbaker: I mean, the problem here is that people don't actually want what -isystem is meant for, which is pushing include paths later in the resolution order
16:41 dcbaker: they just don't want warnings from the headers of external projects
16:41 karolherbst: right...
16:41 dcbaker: but we need to handle this correctly with bindgen
16:42 dcbaker: and by this I mean -isystem
16:42 karolherbst: right...
16:43 karolherbst: the issue is just that there is an -isystem/usr/include and it messes up everything. For normal compilers it's all filtered out depending on what the compiler says is the default include path and stuff
16:44 karolherbst: tried to mimic it but kinda got painful real quick
16:44 dcbaker: yeah... I mean ideally we'd just re-use the code that already exists for clang
16:44 karolherbst: mhhh right..
16:45 dcbaker: I'm just not sure how painful that is going to be
16:45 karolherbst: very probably
16:45 karolherbst: I looked into it, but I stopped at "we have to make sure the clang _we_ ask is the same clang bindgen uses"
16:45 dcbaker: yeah.... which has interesting interactions with cross compiling
16:46 dcbaker: since bindgen will always be run from the build machine, but the rust target might be built for a different host machine
16:46 karolherbst: mhhh
16:46 karolherbst: right
16:47 karolherbst: anyway.. the bug I'm trying to solve and where I need this is, that I want to do this "check the build-id from where that symbol came from" and for that I need bindings to LLVM :( I could of course hardcode a mangled symbol name, but....
16:56 dcbaker: yeah.... We need to fix this anyway
16:57 dcbaker: also.... we have a dependency.as_system() but not an inverse function...
16:57 dcbaker: as a workaround maybe we could do something like dep_llvm_includes = dependency('llvm', ...); dep_llvm = dep_llvm_includes.as_system()
16:57 karolherbst: yeah.. though I don't think it makes sense to overwrite this? dunno.. There is probably a reason why the dependency is marked as system
16:58 karolherbst: but it just shouldn't add isystem for paths which would get filtered later on anyway?
16:58 karolherbst: mhhh
16:58 dcbaker: yeah
16:58 dcbaker: wait...
16:59 dcbaker: I thought we did filter /usr/lib/include already in the llvm dependency handler... Is llvm coming from cmake or llvm-config?
17:00 karolherbst: uhm.... no idea
17:00 karolherbst: `dependency('llvm', ....)'
17:00 karolherbst: whatever that ends up doing I guess
17:03 eric_engestrom: dcbaker: if/when you send that -iexternal upstream, please drop me a link; I'd be interested in following along :)
17:03 MrCooper: dcbaker: FWIW, -isystem does generate warnings, they just don't result in errors with -Werror; I'd want that to be the same with -iexternal
17:37 karolherbst: dcbaker: I suspect it uses cmake as meson searched for cmake right before reporting the llvm dep
17:38 karolherbst: but yeah.. there is an -isystem /usr/include arg coming from it
17:38 dcbaker: That might be the issue. I think the llvm-config path will strip that, but the cmake path doesn't seem to.... I can fix that
17:38 karolherbst: cool!
17:39 karolherbst: would be cool to get it done for 1.2 so I only need to bump the version once for the bugs I have :3
19:10 cheako: Hi, this is interesting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z2T5WKUTHNLS2SVCVAWNYYRIBK3NGF32/
19:12 HdkR: TL;DR? They switching to something better than ML?
20:02 dcbaker: karolherbst: the more I think about it, the more I think that we should just always drop default include dirs when converting to a system include, it's not even really an LLVM problem, it's really just a "/usr/bin/include" should always be dropped when the dependency is a system type
20:03 karolherbst: yeah.. probably
20:12 dcbaker: which is going to be an enormous amount of work... back to the LLVM cmake aproach
20:45 alyssa: robclark: on asahi, --use-gl=egl only works for me if I also pass --in-process-gpu, otherwise it bugs out with "GPU process exited unexpectedly: exit_code=5" and falls back to software
20:45 alyssa: is this familiar?
20:47 robclark: alyssa: ok, I'm going to guess you are talking about chrome/ium? Try disabling gpu sandbox?
20:47 alyssa: happens regardless of no sandbox
20:47 alyssa: and yeah I meant chromium, whoops thought I specified, heh
20:52 alyssa: i.e. neither --disable-gpu-sandbox nor --no-sandbox make a difference, but --in-process-gpu does "fix" it
20:52 alyssa: I don't particularly care personally, but was wondering whether this was known snafu for gles + desktop linux
20:58 robclark: I don't think I've tried to specifically use gles on desktop linux, tbh
20:58 alyssa: yeah, incredibly valid.
20:58 robclark: gpu sandbox tends to be the problem over and over again because it needs to know certain driver specific paths to let punch thru the sandbox
20:59 alyssa: nod.
20:59 alyssa: only reason it was interesting was EXT_ms_rtt testing ;)
21:00 zf: is it possible for more than one process to use RADV_THREAD_TRACE at a time?
21:01 zf: I'm guessing probably not...
21:08 alyssa: ngl the seemore demo is really growing on me
21:08 alyssa: like a talking plant
21:11 HdkR: I used to really like Intel's old Order Independent Transparency demo
21:12 HdkR: Luckily that feature really took off.