00:12 jenatali: !27023 should fix it
00:12 jenatali: Only an 8 year old bug...
09:48 karolherbst: airlied, jenatali, gfxstrand: any thoughts on the llvm opaque pointers break linking spir-vs situation? tldr, the translator can't reconstruct a proper function signature, so the spirv using an external definition ends up generating the function all with uchar* pointers. We have three options here really: 1. link on an llvm level 2. make the translator always use uchar* pointers for function args (if exported) and cast to the proper thing
09:48 karolherbst: in the body 3. link on a nir level and just cast our way through that mess
12:43 mripard: lynxeye: I recall a discussion involving etnaviv something like 5-6 years ago about designing some userspace interface to express the memory access constraints a DMA device could have, but I can't find it anymore
12:43 mripard: iirc you were involved in it, do you remember when it occured or the name of the thread?
13:04 karolherbst: mhh.. I think I'm just gonna hack spirv-link, because I think the spirv target will fix it long term (question is if llvm-18 or 19 is read) and I don't feel like hacking up the translator
13:13 jfalempe: tzimmermann, sima, do you have time to review DRM panic (https://lists.freedesktop.org/archives/dri-devel/2024-January/436564.html) ?
13:43 sima: jfalempe, dropped some comments about the design and mostly locking issues, since I'm assuming that all the details around drawing have been polished nicely already
13:45 jfalempe: sima, thanks a lot, I'm looking into that ;)
13:47 jfalempe: sima, I though that in the panic handler, only one CPU was still online, and thus locking wasn't needed there ?
13:51 tomeu: DavidHeidelberg: I'm having a small problem with the alpine build job: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/53668235
13:51 tomeu: looks like xtensor isn't packaged, and I need it for my tests
13:51 tomeu: any ideas?
14:00 sima: jfalempe, but you're still not allowed to go boom on inconsistent state
14:00 sima: and I'm not sure you're actually guaranteed that the other cpus will stop, that needs inter cpu interrupts and who knows whether that works
14:01 sima: jfalempe, essentially the current panic code was developed with the "locking is optional" assumption, and john ogness is fixing that mistake since a few years now
14:01 sima: or well, trying
14:01 sima: the thing is, kms panic will be only one of an entire pile of panic dumpers/consoles
14:02 sima: we _must_ make sure that we _never_ make the situation worse and so prevent a subsequent console/dumper from doing its thing
14:02 jfalempe: sima, ok, got it, that also means that if one lock is taken at the time of panic, you won't see anything.
14:02 jfalempe: sima, but badly crashing is not a better option.
14:02 sima: jfalempe, also panics can come from nmi context, which can interrupt _any_ irq-disabled section or hardware interrupt
14:03 sima: jfalempe, yeah it has downsides, but if we end up breaking e.g. pstore or serial console in that case, then not only will you not get no kms output, but also no pstore or serial output
14:03 sima: you can try to be more clever with srcu, but it's _really_ hard
14:04 austriancoder: mripard: maybe this one https://github.com/cubanismo/allocator
14:04 sima: given how buggy hand-rolled driver locking in kms usually is, I have no confidence drivers will get it right
14:04 jfalempe: sima, Yes, I agree, it's still better to check with trylock() then
14:04 sima: jfalempe, also it will still be better than the current situation of no panic output on kms at all
14:07 jfalempe: sima, that depends on the locking time, I mean if the plane is locked 90% of the time, you won't see many panics. But that also means that the driver is very bad.
14:07 sima: jfalempe, the longest times are modesets usually, but at that point we don't have good chances anyway
14:07 sima: page-flips should be really quick
14:08 sima: and if we're unlucky and panic when that happens there's excellent chances it's the driver itself that went boom, and so a good idea not to touch it at all
14:08 sima: *the lock holding time for page flips should be really quick
14:08 sima: the actual flipping can take a while, but shouldn't matter
14:09 jfalempe: sima, hum I need to check, but for the mgag200 driver, we memcpy the framebuffer to video memory, and I think the lock is taken during this time.
14:09 sima: jfalempe, another thing to ponder is how long we want to hold the locks
14:09 mripard: austriancoder: yeah, looks like it is (and the related conversation here https://lore.kernel.org/dri-devel/8b555674-1c5b-c791-4547-2ea7c16aee6c@nvidia.com/)
14:09 mripard: thanks!
14:09 sima: jfalempe, isn't that done in the commit path, which (for flips) runs in a worker without holding locks?
14:10 sima: jfalempe, for full correctness with testing we should be holding locks until the panic printing is finished (to avoid the buffer disappearing)
14:11 jfalempe: sima, it's done in plane atomic_update()
14:11 sima: jfalempe, this might need a ->cleanup hook, not sure
14:12 sima: jfalempe, yeah that's in the worker for flips, not while we hold the lock
14:12 sima: well non-blocking commits to be precies
14:12 jfalempe: sima, ok good to know.
14:12 sima: for any blocking commits we still hold the locks for the entire thing, but iirc vsyrjala has floated patches
14:13 sima: jfalempe, another thing: for dynamic buffer managers where the buffer isn't pinned during its entire lifetime like with gem dma helpers
14:13 sima: we need to elavate the pin count to make sure it's not going away untimely I think
14:13 sima: at least for testing
14:14 sima: but I guess we'll look at that when tackling those drivers, imo not needed for the first version we merge
14:15 jfalempe: sima, ok thanks.
14:17 sima: jfalempe, also if the locking critical section is too big we could play some tricks with a spinlock just around assigning plane->state
14:17 sima: would still need a trylock in the panic handler, but chances you'll hit that are roughly zero :-)
14:18 bl4ckb0ne: tomeu: got a link to the source? i can package it for you
14:18 tomeu: bl4ckb0ne: that would be awesome, this is the repo: https://github.com/xtensor-stack/xtensor
14:19 jfalempe: sima, yes this can be optimize later, to increase the chance of seeing the panic.
14:19 bl4ckb0ne: thanks
14:19 tomeu: in case it helps there is already a package for https://github.com/xtensor-stack/xsimd
14:19 sima: jfalempe, could even avoid that with rcu, but I think that's a bridge too far and really tricky and will complicated the normal kms code a lot
14:21 bl4ckb0ne: also going to need xtl it seems
14:22 jfalempe: sima, yes, we don't need to go that far, also I prefer to have a minimum working version, and then improve on that. Otherwise it will never get merged.
14:25 sima: jfalempe, definitely
14:27 sima: jfalempe, wrt minimal version I think the absolutely required stuff imo is only a) kerneldoc polish and linking into rst in the few places I've mentioned b) moving the ->get_scanout_buffer to drm_mode_config_funcs c) the plane trylock stuff for the drivers that need it with the current design (i.e. not simpledrm) and I guess d) moving to kmsg_dumper since I think that's the right one ...
14:28 jfalempe: sima, ok I will try to do that for the next version. I may ping you if I need help for those at some point.
14:30 sima: jfalempe, I'm also checking right now with printk folks whether kmsg_dumper really is the future to build on, or whether there's going to be changes there with the printk/console/panic locking redesign
14:30 sima: so maybe wait with that until we have confirmation
14:31 jfalempe: sima, ok, thanks
14:46 bl4ckb0ne: tomeu: a preference between tbb and openmp for xtensor ?
14:46 tomeu: bl4ckb0ne: not really, I just used debian's version and don't even know what those are
14:46 bl4ckb0ne: ill take a look
14:47 bl4ckb0ne: the aur package has nothing enabled
14:47 sima: jfalempe, hm I just looked at mutex_trylock and that might not be panic handler safe enough
14:48 bl4ckb0ne: ill go with just xsimd for now
14:48 sima: jfalempe, so maybe for future-proofing the iterator should directly give you the plane state, so that it'll be easier to change the locking and maybe do the spinlock trick?
14:51 sima: jfalempe, hm yeah we can't use mutex_trylock and friends, so also can't drm_modeset_trylock
14:53 bl4ckb0ne: well, no xsimd
14:54 bl4ckb0ne: packaged version is 12. something, xtensor need 10.0
14:55 jfalempe: sima, for most driver, plane->state is enough, but for ast, I need the plane to get VRAM address.
14:56 jfalempe: but that's probably the exception, so it may use it's own plane iterator.
15:01 bl4ckb0ne: tomeu: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58811
15:05 sima: jfalempe, but ast_plane->vaddr never changes, right? so no locking issues there?
15:05 sima: also to_ast_plane(plane_state->plane) should work
15:06 sima: jfalempe, what I more mean is that it looks like we'll need the raw spinlock for plane->state right away :-/
15:06 tomeu: bl4ckb0ne: that's awesome, thanks a lot!
15:06 sima: you cannot call *mutex_trylock in interrupt context, much less nmi
15:07 sima: and it needs to be a raw spinlock otherwise it goes boom on realtime kernels (since normal spinlocks are just mutexes there)
15:15 HdkR: Spinlocks you say? May I interest you in...efficient spinlocks using waitpkg/monitox/wfe extensions? :)
15:16 jfalempe: sima, yes plane->vaddr shouldn't change, so no problem there. for the different locking API, I didn't look into it yet, but I would assume the mutex_trylock() would be good. We'll need to be careful there.
15:17 sima: jfalempe, mutex_trylock is no good, it's not even allowed in interrupt context
15:17 sima: so definitely not enough for panic :-(
15:17 sima: I only just now realized this ...
15:48 sima: jfalempe, ok first answer I have, kmsg_dumper is the right thing
17:18 sima: jfalempe, for the igt I guess you want to open the drm kms node and allocate some framebuffer of your own before triggering the panic drawing
17:18 sima: so that the corruption doesn't spread to fbcon or whatever is currently running :-)
17:19 sima: jfalempe, also it sounds like from chatting with john ogness that we need raw_spin_trylock
17:20 sima: I'll try to type up a patch next week with the locking code (just a few lines) and the designs and driver rules documented in kerneldoc (probably a few pages)
17:20 sima: to get feedback from rt/printk people
17:26 CazzMatazz: hello
17:34 jfalempe: sima, ok thanks, that sounds good.
17:53 bl4ckb0ne: tomeu: merged in aports, should be available in edge in a few minutes
18:43 daniels: bl4ckb0ne: slick’
18:44 bl4ckb0ne: B)
18:44 bl4ckb0ne: ill keep an eye on the release to actually enable xsimd at some point
21:02 jenatali: Anybody able to recommend a reviewer for !27023?
21:13 zmike: jenatali: I got you
21:13 zmike: if you want to add a piglit test too, that would be great
21:14 jenatali: Yeah, that would be a good idea
21:14 jenatali: What category would I put that in?
21:14 zmike: uhhhhhhhhhhh
21:14 zmike: that sounds suspiciously close to naming
21:14 jenatali: Heh
21:29 CazzMatazz: Is it possible to get opencl working on a Navi14 card in Ubuntu 22.04 LTS?
21:29 karolherbst: probs not
21:29 karolherbst: also, wrong place to ask
21:30 CazzMatazz: Where would I ask?
21:30 karolherbst: ubuntu folks
21:30 karolherbst: there are probably ppa where you get still upstream supported mesas
21:31 karolherbst: but ubuntu shops eol mesa, so it's up to them to deal with all of that
21:31 CazzMatazz: Well I have the mesa package from both Ubuntu, PPAs, and the AMD drivers
21:31 CazzMatazz: but it's missing one file
21:31 karolherbst: yeah.. so it's a ubuntu bug?
21:31 CazzMatazz: clinfo shows that I'm missing 'gfx1012-amdgcn-mesa-mesa3d.bc'
21:31 CazzMatazz: Well, I guess you could say it's an Ubuntu repo bug
21:32 karolherbst: probs need libclc installed
21:32 CazzMatazz: Yes, I can install it, BUT it breaks other things in OpenCL
21:32 karolherbst: what CL driver are you using here anyway?
21:33 CazzMatazz: If I try to install libclc-amdgcn, I have to remove libclc-dev in favor of libclc-15-dev. I don't know what to make of this
21:33 karolherbst: but anyway, can't help with missing files or installing packages breaking things
21:33 karolherbst: really want to either file bugs against ubuntu or the ppa you are using
21:34 CazzMatazz: The mesa package I have is mesa-opencl-icd
21:34 CazzMatazz: And ok, I'm just trying to wrap my head around all this
21:34 CazzMatazz: I tried using Rusticl but I think it's crashing because it's in early development
21:35 karolherbst: well.. what version of mesa do you have installed anyway?
21:35 CazzMatazz: So I tried a bleeding edge ppa for Ubuntu - oibaf. But apparently Rusticl isn't available for Ubuntu 22.04 anymore? As of very recently
21:35 CazzMatazz: mesa 23.3.3
21:35 karolherbst: could be due to rust packaging or something...
21:35 karolherbst: but yeah.. for rusticl to work on AMD you kinda wnat 23.3 or newer
21:36 karolherbst: and stock ubuntu 22.04 is 23.0
21:36 CazzMatazz: What if I used rustup to upgrade to Rust's nightly build?
21:36 CazzMatazz: or does that not matter
21:36 karolherbst: won't have to go so far, but yeah, if you build it yourself you should be able to use it
21:36 karolherbst: but probably easier to just not use ubuntu LTS
21:37 CazzMatazz: It's my first Linux distro, but I have been using it for a while now. I just figured it'd be stable
21:37 karolherbst: yeah, but stable generally means "old software"
21:37 CazzMatazz: and by 'build it myself' you mean mesa? I tried but it looks kinda hard with missing libraries
21:37 karolherbst: yeah...
21:38 karolherbst: that's where the "don't use ubuntu LTS" part comes into play
21:39 karolherbst: sadly I can't check what mesa version ubuntu 23.04 is on because the package website keeps throwing 503s or not replying at all, soo...
21:40 karolherbst: ehh 23.10 I mean
21:40 CazzMatazz: I do like Debian, but maybe it's time for me to move on. Arch has an opencl-amd package in the AUR that's supposed to work nicely with my hardware
21:40 karolherbst: I mean.. moving away from LTS and just do the upgrade every half a year would already help here
21:40 karolherbst: mhhh
21:41 karolherbst: seems like 23.10 is on mesa 23.2...
21:41 karolherbst: still a bit too old
21:41 CazzMatazz: yeah, I think Rusticl requires 24.04
21:41 karolherbst: yeah.. something like that
21:42 karolherbst: if you don't want to move to arch, there is always fedora which updates stuff a bit more aggressively
21:42 CazzMatazz: I mean I have a rusticl instance right now, but I don't know if it's stable. If I try to run benchmarking with hashcat it works for some hash types then crashes after a while
21:42 karolherbst: yeah.. that's a bug which I still need to look into..
21:43 CazzMatazz: and clover is pretty much a thing of the past now?
21:44 karolherbst: pretty much
21:44 karolherbst: though it's still has a few advantages, just I don't know if hashcat works any better there
21:44 karolherbst: if it does, I should really fix those issues...
21:45 CazzMatazz: clover is the platform thats broken for me because of the missing amdgcn
21:45 karolherbst: ahh, right
21:45 CazzMatazz: so it should work in theory, im pretty sure it works otherwise
21:45 CazzMatazz: i also have one called AMD APP, i think that's AMD's proprietary platform? its not even picked up by hashcat
21:46 karolherbst: yeah... I think that's for older GPUs
21:46 karolherbst: it's confusing..
21:46 karolherbst: maybe it runs on your GPU, dunno
21:47 CazzMatazz: i have the rx 5500 which is from 2019. i dont mind how old it is, i just wanted to try and run certain software like hashcat and DaVinci Resolve
21:47 karolherbst: right...
21:47 CazzMatazz: it has been a lot to wrap my head around but im glad i learned in the process, at least
21:47 karolherbst: I've tested davinci resolve on my navi22 and it should run, though users reported that some effects make it crash
21:47 karolherbst: but I'm looking into it
21:48 karolherbst: but it does run and plays RAW video files just fine, and editing also seems to work with the effects I was trying, so not sure if it only crashes on older gpus or something...
21:48 CazzMatazz: do you use rusticl or clover with it?
21:48 karolherbst: rusticl
21:49 karolherbst: I'm sure clover wouldn't be able to run it at all
21:49 karolherbst: due to missing features and all that
21:49 CazzMatazz: well thats cool, i tried installing davinci a long time ago and no matter what i did no video would show up, even though i didnt get the usual error message
21:49 CazzMatazz: i was so confused
21:49 karolherbst: yeah...
21:49 karolherbst: that happens if the CL driver is broken, but not broken enough to make it crash outright
21:50 CazzMatazz: i havent tried davinci since i "discovered" rusticl - adding the variable to my bashrc. i may have to try it again
21:50 karolherbst: though I also had this happening while the runtime deadlocked...
21:50 karolherbst: you'll need mesa-24.0 for it to run proberly
21:51 karolherbst: mhh maybe the fixes got backported to 23.3 though...
21:52 CazzMatazz: i think i read something like that on the gitlab issues page that said it "should" work in 23.3
21:52 karolherbst: ohh seems like it got
21:52 karolherbst: so maybe 23.3 would be fine
21:52 CazzMatazz: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9715
21:52 karolherbst: yeah.. wanted to say that, but didn't find that bug report
21:53 karolherbst: but that's a different issue
21:53 karolherbst: some ciphers producing wrong results should be a different bug, though I haven't tried recently
21:53 CazzMatazz: ah ok, shows how much i know. also just realized that was your comment
21:53 karolherbst: 🙃
21:54 karolherbst: there are still a few rough edges, but kinda getting there slowly
21:55 CazzMatazz: sorry for the dumb question, but how does rocm fit into all this? a lot of software that requires opencl seems to require rocm as well
21:55 karolherbst: it's AMDs official OpenCL stack
21:55 karolherbst: and should work on a subset of AMD hardware
21:55 CazzMatazz: i found another github issue that details rocm not working with my exact hardware, but when i run rocminfo, i see no errors
21:55 CazzMatazz: i see
21:56 karolherbst: yeah.. it's kinda weird...
21:56 karolherbst: might want to install the rocm opencl stuff and see if that works
21:56 karolherbst: but AMD is quick in dropping hardware support it seems
21:56 CazzMatazz: so all of this, opencl and rocm, is kind of like hardware acceleration? only sometimes its mandatory
21:56 CazzMatazz: yeah, ive noticed
21:57 karolherbst: but gfx1012, is that navi12? or what generation is that?
21:57 CazzMatazz: navi14
21:57 karolherbst: I see
21:57 CazzMatazz: or that might be the igpu
21:57 karolherbst: "should" work with rocm, yeah
21:57 CazzMatazz: i have a ryzen 3 5300g CPU with a 'Cezanne' igpu
21:57 karolherbst: but dunno
21:57 karolherbst: can only tell for navi22
21:57 CazzMatazz: i might have mixed those 2 up
21:57 karolherbst: or navi21
21:57 karolherbst: dunno
21:58 karolherbst: I always forget what I have
21:58 CazzMatazz: well i have gfx1012 and gfx 909 - both are affected by that same missing library, for Clover at least
21:58 karolherbst: yeah...
21:58 CazzMatazz: https://github.com/ROCm/ROCm/issues/1735
21:59 karolherbst: you kinda need that libclc stuff installed for it to work on clover
21:59 karolherbst: CazzMatazz: the thing is that rocm doesn't really refuse to work on those GPUs, but it's also not "supported"
21:59 karolherbst: so if it works: great, if not? well.. tough
22:00 CazzMatazz: well the thing i dont understand is i have libclc-15, but then i cant install libclc... i wonder what version the ubuntu "libclc" is
22:00 karolherbst: AMD kinda doesn't get it, so it is what it is. Though they do seem to become better now, but uhhh
22:00 karolherbst: well
22:00 karolherbst: whatever
22:00 CazzMatazz: i think the libclc-amdgcn package wants a much older version of libclc
22:00 karolherbst: prolly the newest llvm version when 22.04 was released or so
22:01 karolherbst: but anyway
22:01 karolherbst: should report a packaging bug against ubuntu there
22:02 CazzMatazz: i will try to find a way to do that. its kind of AMDs fault too though
22:02 karolherbst: yeah.. maybe
22:02 karolherbst: packaging can be hard :D
22:02 CazzMatazz: i used their amdgpu-install package to set up opencl. they advertise it on their website to be compatible with ubuntu 22.04
22:03 karolherbst: heh...
22:03 CazzMatazz: it definitely can be with conflicting libraries
22:03 CazzMatazz: i dont fault them... well maybe just a little
22:03 karolherbst: I wouldn't trust install scripts tbh, they always do weird stuff
22:03 karolherbst: ohh wait
22:03 karolherbst: it's adding a ppa?
22:03 karolherbst: oh well
22:03 CazzMatazz: i think they add some repositories
22:03 CazzMatazz: no its not a ppa
22:04 CazzMatazz: it really just runs commands for you
22:04 karolherbst: I see
22:04 karolherbst: yeah.. anyway, can't help with that 🙃
22:05 CazzMatazz: the 2 main ppas for mesa on ubuntu are kisak and oibaf
22:06 CazzMatazz: i think they just compile and package mesa for people that dont want ubuntus ancient packages
22:06 jenatali: zmike: Was getting ready to write a test, but decided to do some spec lawyering, and I can't find any place where it says that two images with the same internal format and different type *must* produce different "effective internal formats" (i.e. breaking mip completeness)
22:06 zmike: 🤔
22:07 zmike: I guess technically there's no requirement for it?
22:07 jenatali: Yeah, I could write something that'd catch the bug in my driver, or maybe even Mesa all-up, but not sure I can write something that's valid on all drivers
22:08 jenatali: Nothing stopping a driver from taking 16-bit unorm data and storing it as 8-bit unorm if all you asked for is generic RGBA
22:08 zmike: so you're suggesting this may be a case of undefined behavior between different drivers
22:09 jenatali: Yeah
22:10 jenatali: The bug I hit was that we were uploading mip data for a mip-incomplete texture in a broken way, but it didn't actually matter that it was mip complete or incomplete
22:11 jenatali: I just needed us to be consistent and not try to upload data in the wrong format
22:11 zmike: it's unlikely any spec change would happen if this got raised to the wg
22:11 zmike: so potentially this might be a
22:11 zmike: and you know how much I don't want to say this
22:12 zmike: but it might be a case where your driver needs a pipe cap
22:13 jenatali: Nah, the spec says that the driver can figure out the effective internal format however they want, and that the effective internal format is the thing that determines compatibility
22:13 jenatali: I don't see a spec problem... I just don't see a good way to write a test to force different effective internal formats
22:13 jenatali: Since, like I said, they can figure it out however they want
22:14 zmike: ah okay I misinterpreted
22:14 zmike: well
22:14 zmike: hm
22:15 zmike: how about an apitrace from the app?
22:15 zmike: could see about DavidHeidelberg adding that to ci if we can establish consistent behavior
22:16 jenatali: The consistent behavior is "don't blow up." The app has a mipped texture, then redefines it to not-mipped with the same internalFormat but a different type, which (at least for our driver) chooses a different effective internal format. The problem was Mesa still thought it was mip complete and tried to upload mismatched mip data
22:17 jenatali: Sampling would've worked fine, it's still base complete
22:26 zmike: the more I hear about this problem the more I think I'm glad I don't deal with WGL apps
22:26 jenatali: Heh
22:26 jenatali: It's apparently some app written by some guy at Dell forever ago for testing GL behavior on Dell PCs
23:47 tomeu: bl4ckb0ne: that's so cool, thanks a lot
23:48 bl4ckb0ne: np!