01:13 DavidHeidelberg: karolherbst: Adreno has only rotate-left (ROT inst., enough for CL).. would be ok just enable the flags?
01:13 karolherbst: DavidHeidelberg: in a separate commit as the one in my MR needs to be backported
01:13 karolherbst: or uhm.. applied to stable branches anwyay
01:13 karolherbst: DavidHeidelberg: btw, what bit sizes?
01:14 karolherbst: mhhh
01:14 karolherbst: actually
01:14 karolherbst: nir does optimize towards uror if enabled
01:14 karolherbst: though.. I assume it's still relatively cheap implementing uror on top of urol?
01:15 DavidHeidelberg: tbh, not much idea, just looked into your MR and found "unused" ROT inst. and while proprietary Adreno has CL support..
01:16 karolherbst: I wonder if you can do a negative roll to get the other direction...
01:16 DavidHeidelberg: I think it look like 16+32 support
01:16 karolherbst: but if it needs to be split (uror/urol support), I'd rather do it in a new MR anyway
01:17 karolherbst: would be good to first figure out what the hw can actually do
01:21 DavidHeidelberg: karolherbst: sure the MR look good as is :)
01:22 alyssa: alu is cheap o:)
01:26 karolherbst: DavidHeidelberg: does adreno have a funnel shift?
01:30 DavidHeidelberg: I don't think so, at least from docs/code
01:30 karolherbst: mhhh
01:31 karolherbst: it's kinda weird to add a rotate-left but not a rotate-right...
01:31 DavidHeidelberg: maybe no-one needed it yet (no OpenCL until lumag started writing it), so it's undocumented..
01:32 karolherbst: I actually wonder...
01:33 alyssa: alu is cheap o:)
01:33 karolherbst: if you left rotate by -1, you right rotate by 1, no?
01:34 alyssa: with sm5 semantics (and 2's complement), yes i think so
01:34 karolherbst: I wonder if that's true for any rotation
01:35 karolherbst: worst case the backend puts a neg into the mix, if we are nice, we do that in opt algebraic...
01:35 karolherbst: but it's kinda pain
01:35 karolherbst: aren't we at the point where we need a better solution instead of doing `struct nir_shader_compiler_options`? :D
01:36 alyssa: iirc, the original plan was that drivers would bring their own nir algebraic pases
01:37 alyssa: maybe have common rules to choose from to paste together as desired?
01:37 alyssa: obviously that's not the path we took though
01:37 alyssa:shrug
01:37 alyssa: there are worse things
01:37 karolherbst: I mean.. that's what we kinda have right now, no? :D
01:37 karolherbst: just different
01:38 karolherbst: with nir_shader_compiler_options you select the rules you want to have (opt_algebraic)
01:39 karolherbst: I just wonder if drivers filling a table with supported bit sizes of nir_op's would be the more sane way of dealing with all of this here...
01:39 karolherbst: oh well...
01:39 karolherbst: not that it matters much
01:45 DavidHeidelberg: hmm, only SHFL, not SHFR. So something like negative value is probably the way to go
01:46 DavidHeidelberg: and it should support 16 and 32 bit
01:52 DavidHeidelberg: hmm, hold a sec, it's not like on nvidia it can be adjusted by subop.. so not sure how it's called in adreno driver :(
09:09 vsyrjala: demarchi: "dim: line 187: [: -eq: unary operator expected"
09:22 jani: meh, I've missed the pull request with that change :(
10:34 karolherbst: anybody with some knowledge about linker/compiler flags (-fPIC specifically) mind giving this a thought? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25568
10:34 karolherbst: I'd rather have some explicit review on that part before forcing `-fPIC` generally
10:40 karolherbst: jenatali: one thing I was thinking about is to add a `clc_init()` with potentially returning a `struct clc_context` object to cache some calculation made clc_compile_to_llvm_module, but also elsewhere. I don't think it's really worth it from a compilation overhead perspective, though we do a couple of syscalls in there so it might actually matter for smaller kernels... ever played around with that?
10:47 rgallaispou: Hi
10:47 rgallaispou: I've a dependency in my serie [1] which is merged in linux-next. I am based on drm-misc-next which does not include it yet, and cherry-pick the dependency manually. When generating the patches I cannot specify the base commit for the dependency (git format-patch --base='...') because it is on another tree. So I get striked by the kernel test robot.
10:47 rgallaispou: How should I handle it ?
10:47 rgallaispou: Should I base it and test directly on linux-next to get the dependency right, or was it correct the way I did previously ?
10:47 rgallaispou: [1] https://lore.kernel.org/lkml/170532917312.565061.10381473169126019945.robh@kernel.org
13:03 jenatali: karolherbst: nah, I haven't seen that overhead be a problem I think
13:03 karolherbst: yeah.. on windows it's fine, but now that I want to use `dladdr` and `realpath` on Linux it might be significant enough to shave off a few seconds of CL CTS runtime...
13:03 karolherbst: but haven't checked yet
13:04 karolherbst: realpath is quite expensive as it resolves all symlinks in the path, so it has to do quite a few syscalls like `stats` on each part of the path and the likes... but compared to the full compilation I'm sure it's still entirely irrelevant
13:05 karolherbst: but who knows
14:08 demarchi: vsyrjala: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/29
14:34 HdkR: realpath can get /real/ spicy over an NFS share if the metadata isn't cached yet on the host
14:37 HdkR: Although after first run of something, that's usually less of an issue
15:17 karolherbst: HdkR: yeah.. though I hope nobody runs cl on a system where clang lives on NFS storage
15:19 karolherbst: or rather libclang
15:19 karolherbst: HdkR: though I guess if you do it 1 time or 1000 times doesn't really matter much here then, right? :D
15:20 daniels: karolherbst: CI
15:21 karolherbst: mhhhh
15:21 karolherbst: but I guess the same thing applies, once it's cached it's fine
15:21 karolherbst: but if you have weirdo symlinks inside your /usr/ hierachy, it's also kinda your fault
15:23 tomeu: bl4ckb0ne: looks like at least one header is missing from the xtensor package:
15:23 tomeu: /usr/include/xtensor/xrandom.hpp:23:10: fatal error: xtl/xspan.hpp: No such file or directory
15:23 tomeu: (from https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/54042894)
15:23 bl4ckb0ne: ill have a look later today, I noticed some issues regarding their release and the dependencies
15:36 tomeu: thanks!
15:42 bl4ckb0ne: https://pkgs.alpinelinux.org/contents?branch=edge&name=xtl&arch=x86_64&repo=testing xspan should be there
15:42 bl4ckb0ne: the file is in xtl since 2018
15:43 bl4ckb0ne: maybe an issue in the include path folders or something wrong in the pkgconfig? those are header only libs
15:43 tomeu:scratches head
15:43 tomeu: yeah
15:55 daniels: can someone with an opinion on cmake version requirements in piglit please comment on https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/796
15:57 daniels: it's present in debian oldstable and the old ubuntu LTS so should be fine, but last time I tried to increase a dependency version the policy seemed to be that it was completely unacceptable to require anything released in the last 5 years, other than libdrm
15:58 karolherbst: daniels: I think for piglit that's fine...
15:58 karolherbst: I think if your use case is to run piglit main on 5 year old software, you might want to either pin your piglit version or reconsider your life choices
15:59 karolherbst: however
15:59 daniels: shrug, that's the policy for mesa
15:59 karolherbst: you don't need custom cmake modules for finding pkg-config based deps
16:00 daniels: kinda-sorta
16:00 daniels: Wayland relies on wayland-scanner to parse XML for extension definitions and generate C, so for cross-compiling you want to discover wayland-scanner and wayland-protocols from the host
16:00 karolherbst: ohh, you want to use helper stuff for wayland codegen things...
16:00 karolherbst: mhh
16:01 karolherbst: maybe we should pull those into wayland git repos...
16:01 karolherbst: and not make everybody write their own wrappers
16:01 emersion: meh
16:01 emersion: i'd rather not add helpers for each and every build system
16:02 daniels: for Meson it's pretty trivial, for autoconf we do install wrappers into aclocal to use, but the state of the art for cmake seems to be to find a module somewhere and vendor it into your tree
16:02 daniels: I also, specifically, don't want to spend any more time on CMake than is strictly necessary
16:02 karolherbst: yeah...
16:02 emersion: ^
16:03 daniels: doing the libclc spirv stuff was at least 20x my lifetime quota
16:03 karolherbst: :D
16:03 karolherbst: fair enough
16:09 bl4ckb0ne: are dmabufs available in android? I'm looking at a way to import a buffer into vk without using AHardwareBuffer
16:33 alyssa:doesn't understand why anyone wants anything older than debian stable
16:34 karolherbst: *unstable :P
16:34 karolherbst: but yeah.. 5 years is kinda sketchy
16:35 karolherbst: I mean... nvk needs rust 1.73 🙃
16:35 karolherbst: so that's going to be fun if anybody comes around and claims "but 5 years"
16:57 mupuf: daniels: my policy is that if it is in Debian stable, the thing is already too old
17:01 mupuf: End users shouldn't use them, and especially not devs
17:01 daniels: mupuf: this is not a universally-shared opinion
17:01 mupuf: Haha, indeed!
17:01 karolherbst: well.. luckily it's about piglit, not mesa here
17:02 mupuf: But people in the know know that stable distros sell false promises unless they pay for it
17:03 karolherbst: I wished more would know that
17:04 mupuf: And even for paid ones, what you pay for is developer time to provide guidance and emergency fuxes
17:04 karolherbst: well.. and you pay for testing of updates
17:04 mupuf: But that only covers known issues
17:04 karolherbst: and regressions
17:04 karolherbst: but yeah
17:04 mupuf: Yep
17:05 karolherbst: better than what LTS distros do :P
17:05 mupuf: +9000
17:05 mupuf: Worse, Debian doesn't even update packages to their current LTS before releasing a new stable
17:05 karolherbst: I think the issue is that they don't care about upstream LTS anyway
17:06 karolherbst: I wished they would, but...
17:06 mupuf: It's all a show ;)
17:06 karolherbst: anyway, nothing wrong with debian for fire&forget use cases
17:07 karolherbst: or if you don't necessarily care about either
17:07 mupuf: Look, we have 70k packages!! Oh, they aren't outdated, they are just "stable"
17:07 karolherbst: or if stuff not moving is your use case
17:07 mupuf: And even unstable has years old packages :D
17:07 mupuf: Yeah, Debian should focus on server use cases
17:07 karolherbst: I think it's fine, we just all have a different opinion on what "unstable" means
17:07 mupuf: Drop the rest
17:07 karolherbst: or uhm..
17:07 karolherbst: "stable"
17:10 mupuf: </rant>
17:11 mupuf: I wouldn't get so upset if users did not come expect developers to support their insanity
17:11 karolherbst: well.. most users seem to be fairly understanding
17:11 karolherbst: I think last year I only had one "but what I'm supposed to do" case
17:11 mupuf: But hey, it is 2024, if your distros doesn't provide packages: fire up podman
17:12 mupuf: Or distrobox and develop there
17:13 karolherbst: I mean.. that's kinda an option that docker/podman/flatpak make distributions pointless overhead (like having 1000, not just let's say 10), because of their inability to change
17:13 daniels: mupuf: it's not about users - iirc it was mareko and mattst88 saying that we couldn't require newer wayland-protocols until it was in LTS
17:13 emersion: well, depends which distro
17:13 karolherbst: yeah... but that's why I said "10", not "1" :P
17:14 emersion: i'm working on a libva patch which fixes an issue, which will take a while to ship in a release, and i think a very long while to ship in flatpak
17:14 emersion: if at all
17:14 karolherbst: but yeah....
17:14 mupuf: Ubuntu LTS or Debian stable?
17:14 emersion: like, all flatpak packages will need to bump their SDK
17:14 daniels: mupuf: iirc AMD mostly runs Ubuntu LTS-1
17:15 karolherbst: yeah.. that SDK thing is I think what needs to be sorted out
17:15 emersion: so flatpak is more of a hurdle in my case
17:15 karolherbst: or at least give a stability guarantee, that you can always update the SDK
17:15 karolherbst: or update within declared constraints
17:15 karolherbst: but anyway
17:15 karolherbst: things we'll figure out
17:20 mattst88: daniels: FWIW I have no memory of being on that side of any similar discussion -- seems like I've usually been on the other side in fact
17:20 daniels: mattst88: sorry for the slander then :)
17:21 mattst88: heh :)
17:24 mattst88: emersion: I suspect you've been busy with sourcehut stuff lately -- are you planning to retag pixman as 0.44.0?
17:24 AnuthaDev: Hello! Does the DRM subsystem still take part in Xorg endless vacation of code?
17:25 AnuthaDev: I was looking here: https://www.x.org/wiki/SummerOfCodeIdeas/
17:25 AnuthaDev: I couldn't find much discussion about Xorg EVoC online so asking here. I am interested in some ideas listed in the DRM TODO
17:25 karolherbst: AnuthaDev: we can't take any students atm
17:25 karolherbst: (should probably update the wiki)
17:25 AnuthaDev: Ah, I see
17:26 AnuthaDev: tbh I was suspecting it given the lack of online activity about it
17:26 AnuthaDev: unfortunate nonetheless
17:27 karolherbst: yeah... maybe it will be all sorted out this year
17:27 AnuthaDev: Hope so :)
17:28 mattst88: karolherbst: remind me why we can't take students now?
17:29 karolherbst: SFC stuff
17:29 mattst88: ahh, right. switching from SPI to SFC
17:29 karolherbst: yes
17:29 karolherbst: kinda have to make real and proper contracts with students about work like that
17:29 karolherbst: so yeah...
17:30 mattst88: AnuthaDev: FWIW, I haven't seen many students do EVoC -- I think it's mostly been useful for cases where a student is already involved in the project
17:31 karolherbst: I had an EVoC student being new working on rusticl tho
17:32 AnuthaDev: Well I would've participated via GSoC but have already exhausted my limit of 2
17:32 karolherbst: and they were more or less new to the project, well.. kinda
17:32 karolherbst: mhh yeah...
17:33 karolherbst: maybe sima is able to give an ETA on when we'll be able to take EVoC students again?
17:34 AnuthaDev: I actually tried emailing evoc@foundation.x.org like 4 weeks ago, but never received a response...
17:34 karolherbst: huh
17:34 karolherbst: you got two replies, no?
17:35 karolherbst: wait..
17:35 karolherbst: alyssa messed up replying and sima didn't fix it :D
17:35 AnuthaDev: Yeah, I just checked, no replies
17:35 sima: ugh
17:35 karolherbst: I'll forward :D
17:35 karolherbst: done
17:36 sima: ugh we haven't updated the evoc page yet I think :-/
17:36 karolherbst: sima: anyway, we can still do EVoC via SPI now?
17:37 sima: karolherbst, yeah I think we should be set up now
17:37 sima: just need to make it clear that spi requires a signed contract, and the thing internship cannot start before that's sorted out
17:37 karolherbst: okay, and here I thought we have to wait until the SFC stuff is done :D
17:37 AnuthaDev: Oh damn I got a reply from alyssa? They're my inspiration 🙏
17:39 AnuthaDev: Also, if I didn't mess up the email address I emailed sima too 😅️
17:39 sima: my email situation is a disaster unfortunately
17:40 karolherbst: stop doing email then, it solves all problems :P
17:40 sima: but yeah I got it I think, somewhere, but I failed to realize that the reply I typed on the other thread went nowhere :-/
17:40 sima: karolherbst, currently at the "stop doing" part :-P
17:40 AnuthaDev: Because of the timing being during holidays I didn't send followup messages....
17:41 sima: AnuthaDev, so you got what alyssa & me wrote through karolherbst now?
17:41 AnuthaDev: Yep
17:41 sima: also sorry for this mess :-(
17:41 karolherbst: email is hard
17:42 AnuthaDev: Ah its alright :)
17:42 sima: ok need to prep dinner now, kinda wanted to get that started an hour ago ...
17:42 karolherbst: mood
17:42 karolherbst: just with everything today
17:43 sima: I did manage to pull out the salad bowl but then got distracted ...
17:43 karolherbst: I decided I'm not able to cook today
17:44 karolherbst: welll
17:44 karolherbst: s/decided/accepted/
17:46 sima: yeah there's days where accepting stuff aint happening is too much ...
17:46 karolherbst: oof
17:46 karolherbst: I got pretty good at it
17:49 emersion: mattst88: hm, still not sure whether that's what we should go for
17:51 mattst88: emersion: I don't see a ton of value in the even-odd stable-unstable split for pixman anymore; but also switching away from it seems like more work
17:55 alyssa: AnuthaDev: :-)
17:57 AnuthaDev: 🙏🙏
17:58 alyssa:isn't good at email
17:58 AnuthaDev: How to send these sort of "narrator" messages? I am very new to IRC
17:58 karolherbst: /me
17:59 karolherbst:wonders if AnuthaDev meant that
17:59 AnuthaDev:check test
17:59 AnuthaDev: Oh it works, cool!
18:00 AnuthaDev:feels blessed he gets to eat mom's cooking
18:00 alyssa:recommends against saying everything in 3rd person, though
18:00 AnuthaDev:thinks its common in anime probably
18:01 AnuthaDev: ok i'll stop lol
18:04 AnuthaDev: OK, so from what I understand I can apply for EVoC , but I'll need a project plan and a mentor. Correct?
18:06 AnuthaDev: And the contract will need to be sorted beforehand...
18:07 karolherbst: yeah
18:08 karolherbst: well
18:08 karolherbst: the contract needs to be sorted before you start the work
18:08 karolherbst: it's basically to protect you from doing unpaid work
18:08 karolherbst: but you can work on small tasks to get familiar with the projects/code base you want to do the EVoC with
18:09 karolherbst: and mentors are generally more open for the program if they see the student being capable beforehand
18:09 AnuthaDev: Yep, I'll need to do a lot of "unpaid work" to even get started 😄️
18:09 karolherbst: well...
18:09 karolherbst: "a lot" :P
18:11 AnuthaDev: No experience below userspace 😅️
18:11 karolherbst: well.. you don't have to work on the kernel
18:11 karolherbst: it can also be mesa
18:11 karolherbst: or anything in xorg/freedesktop
18:11 AnuthaDev: But you see, I want to work on the kernel :)
18:11 karolherbst: fair :)
18:11 karolherbst: do you have a second machine?
18:12 AnuthaDev: Not at the moment, had an old laptop which is currently broken
18:12 karolherbst: mhhh
18:12 AnuthaDev: Am thinking of getting a pi 5
18:12 karolherbst: ohh, that might be good
18:12 karolherbst: if you want to get one anyway
18:12 karolherbst: kernel development without a serial console can be pain
18:13 AnuthaDev: From what I see on mesamatrix.net I can even work on the pi's GPU drivers?
18:13 karolherbst: sure
18:13 karolherbst: might want to speak with the devs there and figure out what would be a goo beginners task
18:14 AnuthaDev: I should've messaged the IRC earlier. So many cool people around.
18:15 karolherbst: apinheiro: ^^ tldr: EvoC student might be interested working on the v3d driver, though not sure if you are the best person to ping for the kernel side of things
18:19 AnuthaDev: As opposed to email... I spent my New Years wondering whether I had spelled sima's email correctly :P
18:19 sima: AnuthaDev, for kernel rpi gpu driver ping melissawen and mairacanal
18:20 AnuthaDev: Understood.
18:24 AnuthaDev: Oh I had a question btw, how do you develop for devices that you don't have physcially for testing?
18:24 AnuthaDev: Like : https://dri.freedesktop.org/docs/drm/gpu/todo.html#convert-logging-to-drm-functions-with-drm-device-parameter
18:25 AnuthaDev: > Maintainer of the driver you plan to convert
18:25 AnuthaDev: Do i just send patches hoping that they are correct and the maintainer would test them?
18:40 alyssa: Ideally you'd get the hardware
18:40 alyssa: AnuthaDev: ^
18:41 AnuthaDev: Hmm, that sounds expensive
18:41 alyssa: yeah..
18:41 alyssa: in mesa we have drm-shim to mock devices which helps here
18:41 alyssa: don't think kernel has an equivalent /
18:41 alyssa: :/
18:44 AnuthaDev: I should probably stick to focusing on one driver then
18:45 AnuthaDev: Either the one in my laptop or a pi 5
18:47 AnuthaDev: "AMD RX Vega 7"
18:48 Company: I vote pi 5
18:49 Company: my pi 4 that I use for testing needs lots of love
22:01 apinheiro: karolherbst, sorry, has just seen your ping now (just when I'm about to disconnect)
22:02 apinheiro: for the kernel side of things, perhaps maira (or even melissa) are more suited
22:02 apinheiro: not sure if she will have time for an Evoc though
22:03 apinheiro: karolherbst, maira is mairacanal at #videocore
22:03 apinheiro: oh, she is here too
22:03 apinheiro: mairacanal, ^
22:03 apinheiro: just in case you were not connected then:
22:03 apinheiro: "<karolherbst> apinheiro: ^^ tldr: EvoC student might be interested working on the v3d driver, though not sure if you are the best person to ping for the kernel side of things"
22:05 apinheiro: and now going to sleep
22:55 JoshuaAshton: sima: Bump on bubbling fence errors to userspace :)
23:04 gfxstrand: Ooh, spicy!
23:07 JoshuaAshton: gfxstrand: You want in? :p This could also allow us to do away with check_status in Mesa VK Common Code (which also isn't used by RADV anyway as it doesn't function with soft recovery)
23:07 gfxstrand: I'd love it if we can somehow verify that the only errors returned are ones generated by our context somehow.
23:07 gfxstrand: But I've not looked at any of the proposals.
23:08 gfxstrand: The problem with general error propagataion is that dma_fences get passed around so if you're not careful you can end up with errors from other contexts in your context.
23:09 gfxstrand: We had bugs for a while where a GPU hang on Intel in an app would kill Xorg.
23:09 JoshuaAshton: Yeah, eg if you imported a drm syncobj and it resulted in Mesa saying VK_ERROR_DEVICE_LOST and marking the decide as lost because it had an error
23:09 JoshuaAshton: That would be a problem
23:10 gfxstrand: Oh, it's worse than just imports
23:10 JoshuaAshton: VK_SUCCESS works but doesn't give enough info for eg. a compositor to discard a frame because it's fence actually had an error and was garbage. (Unless there was some way to query it explicitly)
23:10 gfxstrand: You could have some shared buffer somewhere that causes implicit fence imports due to memory management stuff.
23:10 JoshuaAshton: gfxstrand: Oh?
23:10 JoshuaAshton: Yeah...
23:10 gfxstrand: Even if you're using explicit sync
23:10 gfxstrand: :D
23:11 gfxstrand: You have to assume any dma_fence from any context can arbitrarly land in any other context even if the two don't know about each other according to userspace.
23:11 JoshuaAshton: Perhaps we don't actually surface it through any client API eg GL/VK, and instead return VK_SUCCESS (like AMD does now for signalled fences with errors), and allow the application to check its imported fences/syncobj explicitly?
23:12 JoshuaAshton: I'd propose VK_TIMEOUT but that's forbidden if timeout is UINT64_MAX :(
23:13 gfxstrand: Taking a step back... I think the idea of being able to VK_ERROR_DEVICE_LOST on vkWaitEvents or vkWaitSemaphore is a good one.
23:13 gfxstrand: The question is how we go about making it safe inside the kernel.
23:14 gfxstrand: We need some way of specifying that you only care about errors from your own VkDevice, whatever that is.
23:14 JoshuaAshton: I think that should only be done if the error was signalled by the current context
23:14 JoshuaAshton: yeah
23:14 gfxstrand: Which, annoyingly, may not be just the DRM fd. At least not on RADV.
23:15 JoshuaAshton: Indeed, that's on physical device level
23:15 JoshuaAshton: (As much as I disagree with that...)
23:15 gfxstrand: Restricting to your DRM FD wouldn't be too hard, I don't think. We'd need some extra tracking but it's probably tractable.
23:15 gfxstrand: Doing it per-context would probably mean driver-specific syncobj wait ioctls which would suck.
23:19 gfxstrand: That or some sort of per-engine cookie that gets passed around that lets us identify which queue generated an error.
23:20 gfxstrand: That sounds problematic for security, though.
23:20 gfxstrand: Passing global things to clients seems bad
23:20 gfxstrand: I guess we could have a drm-fd-local thing that gets passed around
23:20 gfxstrand: Feels annoyingly complicated but probably doable.
23:35 JoshuaAshton: Yeah, makes sense
23:38 daniels: basically just dmabuf/fence again, but this time for identifying contexts