06:34 lumag: pinchartl, mripard: I'd really appreciate your review of https://lore.kernel.org/dri-devel/20250307-dp-hdmi-audio-v5-1-f3be215fdb78@linaro.org/. We probably can not merge it before rc1 (see the cover letter), but I appreciate getting your opinion to be able to repost the CEC series
07:01 glehmann: alyssa: rdna4 supports 64K images (but not as render targets)
07:04 HdkR: oooo, mega textures
07:04 HdkR: RAGE is coming back
08:23 pinchartl: lumag: -ENOTIME for the next two weeks I'm afraid. I'll travel on Sunday and will be back on the 22nd
08:24 lumag: pinchartl, I see, thanks
08:27 tzimmermann: sima, do you have comments on the fbdev-backlight series?
08:27 sima: tzimmermann, looked reasonable
08:27 sima: or do you want some r-b?
08:28 tzimmermann: sima, maybe give it ack at least. IDK if helge is active. i haven't seen him recently
08:29 sima: tzimmermann, for core stuff we still have full maintainership in drm-misc
08:29 sima: I carved that out when helge took over
08:29 sima: backlight itself is more fun, since nominally that's still in the separate tree and the backlight maintainer occasionally gets annoyed when we just merge stuff
08:30 sima: tzimmermann, and I'd treat helge like any other drm stakeholder, if he's not around just merge after a reasonable time to drm-misc
08:30 tzimmermann: i expect this to go through lee jones' tree (unless i hear differently)
08:33 tzimmermann: sima, and if you have a bit, maybe could you look at the dumb-buffer series i posted. it slightly concerns UAPI. please let me know if you have comments. (there's also been some controversy, which apparently has been resolved)
08:33 tzimmermann: sima, i mostly want you to be aware that this is happening
08:36 sima: oh dear how did mesa get to bpp of 64
08:36 sima: that's defo abuse of dumb buffers I think but oh welp
08:37 tzimmermann: exactly :)
08:39 tzimmermann: people doing funny things with this
08:39 sima: tzimmermann, so one thing we can't do is warn on userspace input
08:39 sima: defo not warn and allow it, but warn and fail also not cool
08:40 tzimmermann: maybe drm_warn_once() ?
08:40 sima: still a bit ugh
08:42 sima: tzimmermann, dropped a reply with some thoughts
08:42 tzimmermann: i can surely drop it. but that warning only comes on bpp == 3,5,6,7 and other crazy stuff. that switch already filters out the "known crazy stuff" (10, 12)
08:42 tzimmermann: ok, thanks
08:43 sima: yeah I do see the case for warn_once since it helps to debug regressions
08:43 sima: so not opposed in this very specific case here
08:43 sima: especially if we also lock down ->depth validation, which I'd do while we're digging through this mess
08:43 sima: tzimmermann, also thanks for doing this, I looked into this years ago and gave up because too much a mess
08:48 tzimmermann: sima, thats for the mail. tomi has been very vocal about not rejecting any bpp values. but warn_once seems good to me. about depth values: for all legitimate bpp values, we handle them in the _color_mode() lookup function. it doesn't handle the awkward cases, so things should be fine
08:49 sima: tzimmermann, I'm more thinking whether we should be strict and reject any funny depth values
08:49 sima: so anything that's not depth == 0 || depth == bpp
08:50 sima: and wrt tomba 's ask, I think what we could do is just document that you should use the bpp=64 trick from mesa as escape hatch
08:50 tzimmermann: that will break depth==15 and depth==24, which have bpp==16 and bpp==32
08:50 sima: or encourage people to do a dumb_create2 with fourcc and modifiers
08:51 sima: tzimmermann, yeah but those should be filtered out as real formats and handled with the fourcc path?
08:51 sima: I'm only talking about the hacky fallback handling for the non-fourcc case
08:52 tzimmermann: but what do you mean by 'depth' then?
08:52 tzimmermann: there's only bpp, which we take as a raw value
08:52 sima: hm
08:52 sima: I'm mixing stuff up
08:53 tzimmermann: ok, no worries
08:53 sima: tzimmermann, yeah mixed it up with legacy addfb, which also has depth
08:54 sima: and there we fully validate
08:54 sima: somehow I thought dumb_create thas this too
08:54 sima: so yeah pls ignore my comments about depth, apologies for the noise
08:54 lumag: sima, stupid question, did we ever propose to Lee to move backlight to drm-misc? Or do you think that it might counterproductive?
08:55 tzimmermann: BTW, everyone seems supportive of a dumb_create2 with fourcc. maybe we should attempt to do this or put it on the TODO list
08:55 tzimmermann: lumag, i wouldn't want even more stuff in drm-misc TBH
08:55 sima: might be lack of need with stuff like rounding ...
08:56 sima: lumag, we did, he doesn't want to
08:56 lumag: ack :-)
08:56 sima: tzimmermann, I think it's annoying that backlight is the one thing kms drivers generally need that isn't in drm
08:56 sima: for pci drivers we just merge backlight stuff into drivers directly, which imo makes much more sense from a coordination pov
08:57 tzimmermann: is there so much churn?
08:57 sima: there isn't, which is why I don't care, just find it silly
08:57 tzimmermann: ok, lol
08:57 sima: it's a bit like helge maintaining fbdev
08:57 sima: if it makes people happy, go for it, as long as it's not blocking us
08:58 austriancoder: valentine: is there a reason you removed marge from !33759?
08:58 sima: tzimmermann, if we ever get around to properly integrating backlight into kms consistently and ditch that fbdev special case, then there might be some churn
08:59 sima: but 95% probably within drm and fbdev/core, so not a concern for lee
08:59 valentine: austriancoder: Yes, writing a comment right now, TLDR is that the recent LAVA changes broke other farms
08:59 sima: I think your rework really is the only part of backlight architecture dusting that impact's lee's stuff directly
08:59 austriancoder: valentine: ah okay
08:59 tzimmermann: sima, it's not really high on my todo list, but i'll keep it in mind
09:00 pjakobsson: pushing drm-tip is taking way looooong
09:00 tzimmermann: btw, we really mess up kconfig dependencies wrt backlight. DRM drivers often select it, when they should depend on it
09:00 sima: tzimmermann, I was hoping that hans de geode would dig in, it's really messy with uapi impact
09:01 sima: tzimmermann, jani has really dug into this and despaired :-/
09:01 sima: this = backlight kconfig
09:01 tzimmermann: ouch
09:01 sima: iirc at least, so chat with jani before you get going
09:01 tzimmermann: i gave it a quick lock (and then quickly looked elsewhere)
09:01 jani: that's a good strategy
09:02 jani: :p
09:02 sima: yeah that's a bit the kconfig expeirence :-/
09:02 tzimmermann: i see i'm in good company :D
09:02 jani: if kconfig was a separate upstream open source project, there might be incentive, but the whole thing is so fringe
09:03 sima: imo people adding tiny kconfig symbols for very small things also doesn't help
09:03 sima: which is why I'm trying to curb that as much as possible in drm, gpu drivers tend to be huge already anyway
09:03 sima: still hoping that lto could sort some of this out instead for really tiny setups with everything built-in
09:03 jani: yeah, I'm not sure I buy the whole "people might want to disable this and enable that"
09:04 tzimmermann: sima, i try to avoid these tiny symbols, but sometimes it's the only way without messing uo someone's .config file
09:04 jani: anyway, re backlight. IMO the correct thing to do is to depend on BACKLIGHT, or depend on BACKLIGHT || BACKLIGHT=n
09:04 sima: tzimmermann, yeah, there's unfortunately a huge pressure to add more and make the situation worse
09:05 jani: which one to use, uh, depends on the case
09:05 jani: IMO selecting it is always broken
09:05 tzimmermann: jani, this. backlight is user-selectable. so we shouldn't autoselect it
09:06 jani: way back when I tried to switch all of them to depends, I got negative feedback because it's an inconvenience. select is so "simple"
09:06 lumag: tzimmermann, it was logical to be autoselected, when we had seprate fbdev, LCD and backlight drivers. Might it make sense to make it non-user-selectable now?
09:07 lumag: Ugh. ... 'it was logical to have BACKLIGHT to be user-selectable...'
09:07 jani: you see, if say i915 depends on backlight, and backlight is disabled, you won't even see i915 in menuconfig. and that's what's so hard about this. the whole kconfig UX is so bad
09:08 lumag:thinks that the best kconfig UI is ed and 'make oldconfig'.
09:08 jani: you'd want to see something like, "so you want to enable i915, please enable these too: <list of config items>" and maybe recursively
09:08 jani: lumag: *sigh* that's what I do. well s/ed/emacs/
09:08 jani: 'make oldconfig', then go see what the end result in .config was
09:09 lumag: jani, but for which symbols do we need to show such help string?
09:09 jani: I mean for *anything* that depends on something that's not enabled
09:10 lumag: Would you like to see tons of ARM options on x86?
09:10 lumag: Most likely you mean 'depends on something user-selectable'
09:10 jani: A depends on B. you won't see A in menuconfig unless B is enabled.
09:10 jani: maybe you don't need to *see* it, but you should be able to search for it, and then recursively enable stuff to be able to enable A
09:11 lumag: So, still 'depends on user-selectable'. You can't enable ARM64 or ARCH_QCOM on x86
09:11 jani: but this whole discussion is moot, because I find it highly unlike that anyone would be crazy enough to dig into kconfig guts to actually do this
09:11 lumag: :D
09:11 lumag: Sounds like GSoC project.
09:11 jani: and I've actually been crazy enough to *look*, and ran away
09:12 jani: I think that would just lead to *another* UI. we already have plenty :p
09:12 jani: all of them depend on an arcane C library
09:13 jani: like, I think you should be able to get warnings for selecting symbols that a) have dependencies, or b) have user prompts
09:13 jani: that's what the kconfig documentation tells you to avoid. I can't remember the number of times I've copy-pasted that documentation snippet in reply to kconfig changes
09:14 jani: we have a system that does not automatically discourage bad habits
09:14 jani: actually somewhat encourages bad habits, because select is more convenient at first
09:14 jani: /rant
09:15 jani: tzimmermann: anyway, if you switch all select backlight to depends on backlight, I'm on board
09:16 tzimmermann: jani, ok. i'll do so if i find some time
09:16 jani: \o/
09:19 sima: yeah happy to weight in with some acks too if that helps push this
09:20 jani: I think hans sorted out some of the ACPI parts, should look if we could reduce the selects there too
09:24 sima: yeah acpi selects are nasty, because they're multiple levels
09:25 sima: maybe we should have a kconfig sanitizer in checkpatch
09:25 sima: and complain if someone adds a new select BACKLIGHT (once the cleanup has landed)
09:25 sima: otherwise these pop back up forever
09:26 jani: another tool I refuse to touch because it's a) kernel niche, and b) written in perl :p
09:28 jani: say what you may about sphinx and restructuredtext, but the custom xml docbook pipeline we had in kernel was ridiculously bad
09:28 jani: as a whole we seem to be amazingly incapable of reusing existing tools and always err on the side of reinventing the wheels
09:29 jani: sure, there are some valid reasons, like reducing external build dependencies
09:35 sima: I think most is because of 3 decades of inertia :-/
09:39 jani: sure, but the attitude remains
09:50 colinmarc: weird question. if I have two identical GPUs and a game running in a VM, is it technically possible to pause the VM, move everything it owns to the second GPU, and unpause it? without the game being implemented in a special way?
09:50 colinmarc: slash is there a name for this?
09:51 javierm: jani: I don't think there's any other FOSS project I'm involved where *new* tools are written in perl
09:54 K900: colinmarc: Theoretically maybe, practically no driver provides you the tools to do this
09:54 javierm: jani, lumag: the least bad kconfig UX I know is when you search a symbol in menuconfig (with `/`), that actually shows you the depds that a symbol has and IIRC even the dep graph
09:55 K900: Actually Nvidia has some sort of live migration for GPUs I think
09:55 K900: But it's only for Quadro class stuff
09:56 colinmarc: could a really sophisticated vulkan layer do it?
09:56 austriancoder: valentine: as you are working lot with CI, I have a question: where can I see the stats of the daily ci run for my manual boardfarm jobs?
09:57 K900: colinmarc: You'd have to serialize all the GPU state somewhere
09:57 K900: That would be weird
09:59 HdkR: Look up criu-amdgpu
09:59 HdkR: It's basically what you're thinking about
10:07 valentine: austriancoder: do you mean the nightly pipelines? You can find those at https://gitlab.freedesktop.org/mesa/mesa/-/pipelines?source=schedule
10:08 austriancoder: valentine: yes exactly - thanks
10:08 colinmarc: <HdkR> "Look up criu-amdgpu" <- thank you, this looks interesting :)
10:30 tomba: Anyone know if raspberry pi 5 supports compute shaders with opengl?
10:40 Hazematman: tomba: according to mesa matrix https://mesamatrix.net/ yes `GL_ARB_compute_shader` is supported on v3d (the opengl driver for the pi5 gpu)
10:42 tomba: Hazematman: thanks, I need to debug this more. I didn't see the compute shader extension advertised from mesa, and a simple compute shader example just gave kernel errors.
10:44 tomba: Hazematman: also thanks for pointing to mesamatrix, looks very useful =)
10:44 Hazematman: yeah if you just want to quickly check hardware support, its nice :)
11:55 dj-death: someone knows if there is a equivalent of the screenshot layer for opengl ?
13:08 tzimmermann: PSA: With -rc6 around the corner drm-misc-next-fixes is now open. Features still go into drm-misc-next. Fixes for stable still go into drm-misc-fixes. Fixes for v6.15 go into drm-misc-next-fixes. Patches in -fixes branches should be small and have a Fixes tag.
13:26 sima: jfalempe, I'm a bit confused by your reply, I was talking about why we need vmap, you replied with that we have support for tiling?
13:26 sima: that's a bit separate issues I think, or maybe I'm just confused
13:26 sima: since if we need to set up a vmap for every framebuffer just for panic, that's a bit awkward
13:27 sima: jfalempe, wrt compression, one trick is to clear the compression metadata to "everything uncompressed", that works I think with all intel compressed scanout formats still
13:27 sima: it's not an option with some of the lossy compressed formats like afbc has
13:39 alyssa: sima: afbc is lossless, afrc is the lossy one
13:39 alyssa: that trick should work with afbc
13:46 sima: oh I guess I just smashed them all into one arm-compression-thingy :-P
13:46 sima: but yeah for lossless ones with explicit compression control bits it tends to be the simplest trick for panic logging
13:46 sima: or at least the least risky, since you don't need to mess with hw state and might hang the memory controller on some invalid watermark config
13:56 zmike: mareko: also can you ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33813
13:58 K900: zmike can you ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890 :P
14:00 zmike: it looks okay to me but I think you probably want dcbaker / daniels to signoff for something more meaningful
14:01 K900: I just want to make sure it doesn't blow up dril
14:02 K900: It seems to not have, so far at least
14:02 K900: But I didn't test it on really weird configs
14:02 K900: (because I don't have any)
14:02 zmike: I don't have any either
14:03 zmike: hence why the initial dril rollout had so many issues
14:04 K900: We (NixOS) had people exhume xf86-video-intel's rotting corpse
14:04 K900: And then get mad because it doesn't work with dril
14:04 K900: And I didn't nack it in time so now we have xf86-video-intel in the repos again
14:05 zmike: sounds great
14:07 jfalempe: sima: you mentionned non-linear buffer, so tiling is a kind of non-linear buffer. (but the whole framebuffer is still contiguous in virtual memory).
14:12 jfalempe: sima: regarding vmap, it's the only way to write the pixels, so either we do it in the panic handler, but if that is not possible, we can make sure the primary framebuffer is always vmapped before we send it for display.
14:13 alyssa: gfxstrand: think it's a CTS bug, the opaque buffer thing
14:15 alyssa: not sure how nvk passes tho
14:20 alyssa: I'm like 98% sure this is a CTS bug. I'm just still confused how nvk would pass the test.
14:21 alyssa: Oh. Because CTS version
14:21 alyssa: 046343f46 ("Stop querying device address from unbound buffers")
14:22 alyssa: the fix is in main but not tagged into any vulkan CTS release yet
14:22 alyssa: clown.gif
14:22 alyssa: well, that solves that.
14:29 forthebesteffort: I enhanced the method a bit, 256-57-57-57=59 128-59=69 256+72=328-69-57-57=145 cause intermediate result 69 did not divide by two, we subtract 1. similarly 256-60-60-60=76-16=60 128-60=68 now 68 divides by two we need to add 2, so 326-68-60-60=138+2=140 so with third member 256+68=232 so 256-62-62-62=70-8=62 128-62=66 cause 66 divides by two we add 2 again. so 324-66-62-62=134+2=136
14:29 forthebesteffort: , so the bottom line is when we remove 256 you get 72 70 or 68 but when we do the thing before to any of them we get twice of that, so obviously after removing single result of all from such selection other elements become 0, selection elements get filtered to the single value searched. to get rid of the conditional only for odd format even indexes should be used or smth. Needs a bit
14:29 forthebesteffort: more testing but i assume that is the final so called slimmest and hence much preferred method. so values of the members were mentioned 72 70 and 68 for high indexes 115 120 124 where as we calculate in half the indexes as it was demonstrated on this statement of the problem.
14:48 mareko: zmike: the surface idea seems reasonable
14:49 forthebesteffort: so 26 comes from 256-115-115 so does 16 come from 256-120-120 so does 8 come from 256-124-124
14:50 zmike: cool
14:51 forthebesteffort: now you would hear a lot of me, such as interferring with politics defending my favorites, throwing big parties and even visiting XDC and alike, but ever since i became slightly injured, i have had to make selections , cause the efficiency in my life is lower, so i sacrificed my time to programming to start progressing towards rehabilitation plan later.
14:56 dcbaker: K900: re Benjamin’s concerns about changing the option type. Is the long term plan for this to be like longline where we’re going to have to support both a gbm loader and a non loader version, or more like OpenCL where the standalone support will be removed?
14:57 dcbaker: Sorry, not logged into gitlab on my phone
14:59 K900: My long term goal is to just move the libgbm loader out of Mesa
14:59 K900: And have it be just another dependency like, say, vulkan-loader is now
15:12 dcbaker: I think then having two options might be easier to deal with (rather than changing the type) one that turns on gbm support, and one that toggles standalone vs loaders
15:13 dcbaker: Have you started on a standalone loader for gbm yet?
15:15 K900: I think the existing one is fine, mostly
15:15 K900: It can just be moved out to a separate repo
15:16 K900: But yeah it basically ends up being two options internally anyway
15:17 K900: We can expose that as API, but it gets a little weird because not every combination of those options actually makes sense
15:17 K900: Like gbm=disabled external_gbm=enabled
15:17 K900: What should that do?
15:19 psykose: if they don't make sense just throw an error
15:37 alyssa: anyone see KHR-GL46.es_31_compatibility.shader_storage_buffer_object.basic-binding fail?
15:37 alyssa: new since CTS uprev for me
15:37 alyssa: passes on its own fail, fails reliably if run after KHR-GL46.limits.max_varying_vectors
15:37 alyssa: looks like a mesa/st issue or a CTS bug
15:37 linkmauve: Hmm, I’m trying to build latest master, but I get this error: https://linkmauve.fr/files/mesa-build.txt
15:38 linkmauve: I’m on an up-to-date ArchLinux, and disabled rusticl in order to avoid the current bindgen issue.
15:40 alyssa: i'm not convinced the CTS test is valid
15:41 alyssa: It's checking the 'default' state is 0 but is that necessarily true if running stuff back to back?
15:43 alyssa: linkmauve: hmm looks like the with_c11_threads logic is busted.
15:45 linkmauve: Would it help if I bisected it?
15:46 alyssa: linkmauve: I'm not sure if it's a regression on the Mesa side, versus your glibc updating
15:46 alyssa: I don't recall any relevant Mesa patches lately
16:00 alyssa: filed https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/5632
16:06 zmike: alyssa: pls cc me and assign to kamil
16:07 alyssa: done
16:08 alyssa: as a bit of good news, uprevving vulkan cts lets me drop one of my "HACK: DO NOT UPSTREAM" patches so that's nice
16:08 alyssa: and drop a bunch of backports
16:08 alyssa: so my cts branch is now 5 patches away from upstream, and all 5 are for GLCTS issues :melt:
16:08 dcbaker: K900: I would have gbm-loader=bool along with the existing use gbm option
16:09 alyssa: (ok 3/5 are reverts of something that blows up and IDK if it's my bug or not. But I'd think someone else would hit it too if it wasn't my bug.)
16:09 K900: dcbaker: Do you mean, like, separate options for gbm-loader and gbm-backend?
16:10 K900: That still ends up in a weird state where we can't build gbm-backend=true gbm-loader=false with no ambient libgbm
16:10 K900: Which I guess is maybe fine?
16:10 K900: I just want to be clear here that I hate all the options
16:10 K900: I think the one I have right now is the one I hate the leasat
16:10 K900: But I do not _like_ any of them
16:11 dcbaker: Like a “gbm=feature” (no change) and gbm-backed=loader|standalone (new option), with the long term plan to deprecate the latter. And if you select a configuration that doesn’t work you get an error
16:12 dcbaker: I don’t like any of them either, but trying to come up with a good way to keep bisects working
16:13 K900: Hmm
16:13 dcbaker: You can paint the second option however you like your bikesheds, string options, bool, whatever
16:13 K900: Yeah I was not thinking about bisects
16:13 K900: I was more thinking about making illegal states unrepresentable
16:14 dcbaker: Changing option types and bisects sucks, but this suggestion still doesn’t create an illegal state situation, if you turn gbm off the loader va standalone question is moot
16:15 K900: I guess
16:15 K900: If you think about it that way
16:15 K900: Hmm
16:15 K900: Need to think
16:15 K900: Currently pretty out of think juice
16:15 dcbaker: I’ve been meaning to do some work there in meson, but I only have so much meson time and there’s so much to do… :/
16:21 alyssa: dcbaker: relatable
16:39 K900: Same but nixos tbh
17:21 K900: dcbaker I have something but gitlab is shitting itself
17:22 K900: https://github.com/NixOS/nixpkgs/blob/142675a00ed1f6442a06f7d5301e50943f639dd5/pkgs/development/libraries/mesa/system-gbm.patch
17:23 K900: And just as I did it it went through
17:27 danylo: alyssa "meson: make CL args common" commit requires "fs.relative_to" from meson 1.3, while currently we require meson 1.1.0
17:27 alyssa: danylo: oof
17:28 alyssa: danylo: Can we bump the meson req?
17:28 alyssa: bookworm-backports has 1.5.1
17:28 alyssa: (and bookworm is 1.0.1 which is already below the 1.1 req)
17:28 alyssa: fedora 40 has 1.4.1
17:28 danylo: I found it since the nix build we use for mesa cross-compilation has 1.2.3, we likely could just bump it
17:29 alyssa: ye im checking distros to figure out if there's anyone who would complain about a bump
17:29 K900: danylo: You WHAT
17:30 K900: I'm sorry what nixos version is that
17:30 K900: Like, 23.05?
17:30 alyssa: ubuntu seems to be either be 0.9 or 1.3 (noble?)
17:30 danylo: K900 I think it is pinned to "https://github.com/nixos/nixpkgs/archive/e381fef2a845672af40d8028b94c3163dba3e26e.tar.gz" - whatever version that is
17:30 alyssa:can only keep track of so many sets of code naemes
17:31 alyssa: but yeah, bumping to 1.3 seems reasonable I think
17:31 K900: That's uh
17:31 K900: I think that's unstable from January 2024
17:32 danylo: I guess it's time for a bump =)
17:32 K900: Yeah
17:32 K900: Definitely
17:32 dcbaker: K900: it’ll be a few hours before I can give it a good look.
17:33 K900: No rush
17:33 dcbaker: Anyone building rust stuff needs a relatively recent version of meson too. That’s going to be 1.7.1 or 1.8 soon because of bindgen changes :/
17:35 alyssa: dcbaker: tbf, a lot depends on mesa_clc than rust rn
17:35 alyssa: notably, iris
17:35 zmike: uhhh
17:35 zmike: this is a really dumb question
17:35 zmike: but is it actually legal to create a pipe_surface from a buffer???
17:36 zmike: oh it's a fucking clover thing
17:36 zmike: fuck this
17:36 alyssa: zmike: also rusticl no?
17:36 alyssa: or is that a different fucking thing
17:36 zmike: I can't imagine it's a rusticl thing because zink definitely does not do that
17:40 zmike: deleting pipe_surface::width/height 🤕
17:41 dcbaker: zmike: we still have clover?
17:41 zmike: somehow 🤕
17:41 dcbaker: I thought we’d deleted that
17:41 zmike: I tried like 4 years ago
17:41 zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19385
17:41 zmike: somehow r600+clover blocks deleting clover
17:41 zmike: so we all have to suffer
17:56 HdkR: Yay suffering
17:59 anholt: I think we could poll core developers and decide to retire clover even if we're not at parity for that hw.
18:01 alyssa: anholt: acked-by
18:07 redisorporgand: but that was kind of the start of it, but this latest method is also sophisticated, as the intrinsics for sequences to filter out a focal subset values are slightly moer work. So but the elaboration of the second half goes so, those procedures go into as reference values as told, now since 256+73 is out of reference by 5 it's that 329-324=5 right, hence 8+66-62=12, hence 12-5=7 where
18:07 redisorporgand: other elements cancel out, so what would we do with 7? As we got 66 as reference, so obviously 66+7 is single 73 , that needs more testing but appears to be the third working fs method.
19:34 zmike: TIL gallium-i915 is not built with -Dgallium-drivers=all
20:00 alyssa: zmike: it doesn't build on arm :(
20:01 alyssa: and well i (runs arm) added it for the convenience of our release manager (also runs arm)
20:03 zmike: 🤔
20:03 zmike: but that's not what "all" means
20:06 HdkR: Maybe all needs an additional pass afterwards to remove drivers from the list if they're known broken :D
20:06 zmike: or maybe it should just be fixed to build ?
20:06 HdkR: "Oops, you're on AArch64, I'm just gonna remove i915"
20:06 zmike: how hard could it be
20:08 HdkR: :thonk:
20:25 HdkR: zmike: You're right
20:25 HdkR: If I remove the meson check, it just builds
20:26 HdkR: Four line change deleting the check
20:28 HdkR: `Build-test everything except for i915, which depends on libdrm-intel which is not available on non-Intel distros.`
20:28 HdkR: Probably the comment that matters more
20:29 HdkR: But really if libdrm-intel isn't shipping on other architectures, that's a new problem and distros should fix their packages.
20:30 HdkR: crocus and iris don't depend on libdrm-intel?
20:31 jannau: I have libdrm_intel.so.1.124.0 on aarch64 f41
20:32 HdkR: Looks like it's just a debian/ubuntu problem from what I can see
20:33 HdkR: Actually, Debian bookworm problem. Trixie and Sid has intel as well
20:34 anarsoul: alyssa: why it doesn't build on arm though?
20:34 HdkR: bookworm-backports has it even actually
20:35 HdkR: anarsoul: That's what I just found. It does build once the architecture check is removed from the meson file :)
20:36 anarsoul: I mean I can build lima on x86 (and I do so, I use it with drm-shim for debugging compiler issues), so I don't see why e.g. alyssa couldn't use i915 with drm-shim on her arm machine :)
20:37 alyssa: jannau: iris/anv build on aarch64 fine
20:37 alyssa: it's i915 that's problematic (ancient gpus)
20:38 jannau: i915 builds on f41/aarch64
20:38 HdkR: https://gitlab.freedesktop.org/sonicadvance1/mesa/-/commit/b3c6ee3282506cf6ee05ee6d7cec4b44a0474ca1 EZ patch. Someone else can open an MR :D
20:39 alyssa: huh nice
20:40 jannau: question is if it builds on all CI machine and might have been broken 1.5 years ago when alst tested
20:44 HdkR: I'm not brave enough to attempt Mesa CI
21:46 anarsoul: marge complains that something is wrong with its local repo: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33385#note_2814348 how do I check what's going wrong?
21:51 eric_engestrom: anarsoul: I think it's just that the gitlab api is so slow right now that marge's internal queries time out; I would just re-assign to marge and let it try again
21:52 anarsoul: let me try
21:52 eric_engestrom: oh, I see that it didn't unassign itself, so it's still assigned, but marge it not doing anything with it
21:53 eric_engestrom: I have the ability to restart marge (but that's the only thing I can do, I can't look at its logs); doing that now
21:53 anarsoul: I unassigned and assigned it back
21:53 eric_engestrom: done
21:53 eric_engestrom: ak
21:53 eric_engestrom: *ack
21:54 K900: dcbaker going to sleep now but I built all my systems with the latest iteration of the patch and it seems good
22:04 sima: jfalempe, yeah the requirement to have the primary buffer vmap is the thing I'm not super sure about, since it also means display buffers must be visible to the cpu to begin with
22:04 sima: which isn't always the case
22:05 sima: so maybe we need another indirection for a write_byte function, which then looks at the right address to write to, even if the buffer isn't contiguously mapped
22:05 sima: or if all you have are peek/poke registers to get at invisible vram