01:05karolherbst: airlied: uff.. clover is just busted with images
01:05karolherbst: like completly
01:06karolherbst: I don't see how that would work anywhere
01:06karolherbst: it tries to copy a 262144x1 into a 512x512 resource via transfer_map
01:07karolherbst: and radeonsi has this handy assert: assert(box->x + box->width <= resource->width0);
01:08karolherbst: r600 has the same...
01:09karolherbst: mhh, maybe a r600 texture would be able to handle that alright
01:15airlied: karolherbst: sounds like a vulkan linear->tiled transfer
01:16karolherbst: I am just wondering if drivers should be able to handle it or not
01:16airlied: or rather buffer->image one
01:16karolherbst: I know that our hardware messes up
01:16karolherbst: maybe missconfigured.. dunno
01:16airlied: but yeah I doubt any drivers handle it
01:16karolherbst: anyway.. clover does something differently than the application expects it to do
01:16airlied: except maybe r600
01:16karolherbst: so the application requests a 512x512 copy
01:16karolherbst: but clover flattens it
01:17karolherbst: but.. it does copy it row by row
01:17karolherbst: just the mapping is odd
01:29karolherbst: or maybe I read the code wrong and for textures all of that is actually okay...
01:30imirkin: usually no.
01:31karolherbst: mhh r600 and radeonsi have two implementations of u_resource_vtbl.transfer_map and transfer_unmap
01:31imirkin: one for buffer, one for texture
01:31karolherbst: and only the buffer one asserts on the box
01:31karolherbst: the texture one doesn't seem to care
01:33karolherbst: airlied: mind running the basic readimage OpenCL CTS test on radeonsi and see if anything bad happens?
01:34karolherbst: you might need to throw in a clFinish after clEnqueueWriteImage
01:35karolherbst: but I also don't know why clover flattens the mapping
01:36airlied: don't really have any of the pieces to do that easily
01:36karolherbst: I see
01:36airlied: try it in on llvmpipe maybe :-)
01:36airlied: I've never gotten CTS to build
01:36karolherbst: do I need anything to try it on llvmpipe_
01:37airlied: top of tree llvmpipe should be as useful as any other CL driver
01:44karolherbst: airlied: llvmpipe misses the handling for nir_tex_src_texture_offset
01:44karolherbst: well and sampler_offset
01:44karolherbst: but it does seem happy about the copy
01:45karolherbst: but I wanted to turn the texture stuff to use derefs anyway... oh well
01:45airlied: karolherbst: oh I might have those on my vulkan branch
01:45airlied: I should pull them over at some point
01:46karolherbst: doubtful as vulkan shouldn't end up with those
01:46karolherbst: I think
01:46karolherbst: but glsl should...
01:47karolherbst: but llvmpipe seems to just accept derefs anyway.. so maybe not
01:47airlied: oh ARB_gpu_shader5 support isn't done yet
01:47airlied: which seems like what would hit it
01:48karolherbst: yeah, sounds like it
04:22yayiguess: So I was looking through GSoC/EVoC ideas and the Vulkan GPU preference tools looks like it's be an interesting task to take on
04:23yayiguess: Is that still something that there is a need for?
06:05mupuf: emersion, mdnavare: good to see traction on implementing that on the kernel side.
06:06mupuf: One thing that seems to have been misunderstood from my comment: I was not suggesting to be able to extend the min/max values, just restrict them further than what the EDID wants.
06:07mupuf: And good to see that the HW has a slew rate register :)
06:07mupuf: it's not necessary, but it is a nice bonus :)
09:02pq: vsyrjala, FWIW, I think I tried to argue on dri-devel@ in the past that the kernel driver must prevent VRR monitors from flickering, and it was said it is impossible: there is no way to know what slew rates are "ok".
09:07emersion: it's not "more possible" for user-space
09:08emersion: "less impossible" rather?
09:08pq: sure, but that's one of the justifications I was told IIRC
09:09emersion: if there was a hw db, i'd rather have it in the kernel
09:09pq: with the implicit assumption that games do not vary their rates abruptly anyway (which I don't believe myself at all)
09:09pq: emersion, I totally agree with you, FWIW.
09:10emersion: well, let's see how this thread goes :)
09:10pq: I wonder how that stuff works at all anywhere like Windows without angry gamers complaining about their eyes hurting
09:11pq: are VRR-enabled games really that good? Do games need to the explicitly VRR-enable? Whitelisted by vendor gfx drivers?
09:11pq: *to be
09:18mupuf: pq: "no slew rates are OK" sound like a stupid argument to me for the exact reasons you mentioned: what are games doing anyway?
09:18mupuf: the way I read this, the EDID is just incomplete and VRR cannot be enabled reliably
09:19mupuf: which is yet another argument for putting this in the kernel and allowing the userspace to overwrite the decision
09:19mupuf: the userspace cannot be expected to throttle itself, that is just insane
09:19mupuf: even for the kernel it is close to impossible
09:19mupuf: (without busy waiting)
09:32jadahl: emersion: having hw related dbs in the kernel isn't really good. it's much harder to update. look e.g. at libinputs hw db (hwdb in udev/systemd)
09:32jadahl: (sorry if I missed something obvious, didn't read that much backlog)
10:07emersion: i don't know
10:07emersion: if user-space has a knob to override it, maybe it doesn't matter that much
10:28pq: emersion, if userspace *needs* a knob to override it, then you have two databases: one in kernel and one in userspace. So I get jadahl's points.
10:29pq: though EDID has a quirk database in the kernel, I believe
10:29Venemo: a bunch of stuff has quirk databases in the kernel
10:29emersion: i'm fine with leaving it up to user-space to decide which slew rate to use
10:30pq: maybe it's a difference between what kernel driver needs to know how to operate correctly, and what userspace needs to know to operate correctly (the libinput case)
10:31pq: kernel carrying a database for the sole purpose of letting userspace know probably won't fly
10:52MrCooper: jekstrand: I suspect waiting for all fences might end up worse than implicit sync in some cases; amdgpu internally keeps track of which rings need to sync to which fences
11:00tjaalton: has anyone succesfully built mesa with llvm/clang 10.0.0-rc3?
11:02MrCooper: LLVM yes, clang not yet
11:05MrCooper: tjaalton: what's the problem you've presumably run into? :)
11:05tjaalton: undefined reference to `getPollyPluginInfo()'
11:05tjaalton: I was told it's a regression in rc3
11:05tjaalton: but not sure
11:32MrCooper: tjaalton: sounds like an LLVM issue, Mesa doesn't explicitly do anything with Polly
11:45ivyl: paulk-leonov: hey, I am wondering whether you are still involved with chamelium and use kms_chamelium@hdmi-planes-random - it has an issue with more complex modifiers causing illegal framebuffers to be created and somtiems geneating invalid config resulting in atomic commit returning -EINVAL (e.g. exceeding the number of available scalers)
11:46ivyl: tryting to fix it for all the edgecases feels like commiting to bolting more complexity to it over time, so I am considering either blacklisting it for our HW or removing it from IGT if it's not used by anyone
11:49emersion: this one is quite complex
11:50emersion: i wonder if igt should just use an atomic test-only commit
11:50emersion: (and skip if that fails with EINVAL)
11:52emersion: libdrm question: there's drmOpenControl, drmOpenRender, but no drmOpenPrimary
11:52ivyl: that's one option, but also having a test that randomly flips between skip and pass is a bit annoying in any kind of reporting
11:52emersion: is this an oversight?
11:52emersion: ivyl: a test-only commit should always return the same result on a given piece of hw
11:53ivyl: but you get random configuration each run, so sometimes its EINVAL, somtimes it's a-ok
11:53emersion: ah, i see
11:54emersion: each run doesn't use the exact same hw
12:33mupuf: pq: defaulting to slew rate = +INF in the kernel is not a bad idea. And then it is up to DEs to set something if the user wants to avoid the flickering
12:34mupuf: AMOLED should not have this issue, so it makes sense not to encode too much logic on the kernel side, but it should be the kernel's job to enforce the slew rate (since userspace really can't do a good job)
12:38emersion: ah, AMOLED is a good point
12:40pq: mupuf, I thought the luminance issues was caused by strobing to reduce motion blur. Is AMOLED incapable of being strobed?
12:41pq: anyway, sure
12:50mupuf: pq: strobing means you have a backlight, AMOLED has no backlight
12:51pq: why does it need a backlight?
12:52emersion: what do you mean, pq?
12:52emersion: AMOLED doesn't need a backlight, thus VRR shouldn't cause flickering
12:52mupuf: If I understood the process correctly, the point was to turn off the backlight while the pixels were changing then turning it back on again
12:52pq: one can strobe an individual LED, so why not a whole AMOLED display even if it doesn't have a backlight?
12:53pq: mupuf, no.
12:54emersion: ivyl: btw is the hdmi-planes-random test succeeding on some intel hw of a given gen, but failing on other intel hw of the same gen?
12:54pq: The point of blur reduction is to show the image for only a short time. When your eyes track motion on screen, your eyes turn at a constant speed, but the screen updates at intervals. Keeping the screen black for most of the time, your eyes do not "integrate" the light "off-pixel", reducing apparent blur.
12:55pq: it's hard to explain in irc
12:57mupuf: pq: https://www.youtube.com/watch?v=hD5gjAs1A2s does a pretty good job at explaining your point
13:00pq: yeah... I think
13:00pq: disclaimer: I don't actually know why luminance flicker can happen with VRR. If you just have your backlight on, it shouldn't happen, so something else must be going on.
13:01pq: either strobing for whatever reason, or something about driving the panel
13:02mupuf: well... if the problem really was strobbing, then it would be easily (mostly) fixable on the screen side
13:03mupuf: rather than having one strobe per refresh... strobe every $n ms
13:03pq: but that won't reduce blur anymore
13:03mupuf: you can synchronize it to the first strobe, to reduce perceived latency
13:04mupuf: well, surely, you can't strobe once when running the display at 5 Hz
13:04pq: they don't go that low, either
13:05pq: 48 Hz minimum or so?
13:05emersion: 35Hz minimum
13:05emersion: from a quick survey
13:05pq: also, maybe the monitors that go lowest don't even strobe?
13:05mupuf: yeah, they possibly disable strobbing in some cases
13:06mupuf: looks like a job for the screen to figure out though, not the source
13:06pq: AFAIU, the blur comes from the same reason why a panning camera captures a blurred image: integrating the light over time on a single photosensitive receptor samples more than just one point.
13:07mupuf: yeah, this makes sense
13:07mupuf: but the eye is also weird in the sense that when moving, the brain only sees the "last image" before moving
13:07mupuf: same when blinking
13:07pq: so blinking the same image twice would defeat the point
13:08pq: must be assuming refresh rates where you don't see the motion as jerky to begin with
13:09mupuf: yeah, that part is for sure
13:12hakzsam: MrCooper: are you fine with the new fossilize MR that adds more fossils and more jobs for RADV?
14:08jekstrand: MrCooper: If all the dma_fences involved come from amdgpu, then amdgpu should be able to still unpack the arrays/chains and do it's per-queue isolation stuff.
14:54ivyl: emersion: nope, it's only fails when you try to commit a state that a particular GPU model doesn't like - e.g. you rolled that we should scale 4 overlay planes but you have only 3 scalers available in the HW
14:54emersion: okay, so the number of scalers really depends on the GPU model, not just the gen
15:47bnieuwenhuizen: I'm getting consistent build issues in CI in meson-ppc64el and meson-s390x complaining about /usr/bin/llvm-config-8 not being executable (https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/jobs/1916419). Anyone have a clue what is up with those?
15:48hakzsam: we did some changes recently about cross build does a retry help?
15:48hakzsam: Runner: homeserver.basnieuwenhuizen.nl (#428)
15:48hakzsam: bnieuwenhuizen: ^
15:48hakzsam: x86-64 runner? :P
15:49bnieuwenhuizen: yeah, likely has no qemu set up :P
15:53MrCooper: bnieuwenhuizen: you need to set up qemu in your host's /proc/sys/fs/binfmt_misc
15:54bnieuwenhuizen: yeah, I just disabled it. Might be the best course anyway with the entire bandwidth discusison
15:54MrCooper: installing the qemu-user-binfmt package on the host should do the trick
15:55MrCooper: not necessarily, your personal runner should be less likely to lose docker images and have to re-download them
15:55bnieuwenhuizen: I thought since the upstream runners (at least the build ones) are in GCP bandwidth is not an issue for them?
15:56daniels: jekstrand: there's also a patchset for sync_file into X11 fences, but that degenerated into 'should we just plumb them through as-is, or should we rewrite scheduling in the server first' with no clear answer
15:57ajax: rewrite scheduling, eh
15:57MrCooper: bnieuwenhuizen: the shared runners aren't in GCP, that's the problem
15:57MrCooper: well, most of them aren't anyway
15:57bnieuwenhuizen: oh ...
15:58daniels: ajax: the opposing positions were keithp and ickle; I can't remember which was which
15:58daniels: ajax: searching from lfrb should get you the thread
15:58MrCooper: jekstrand: I'm fine with leaving X as the implicit sync bastard child :)
15:58daniels: bnieuwenhuizen: even if they are inside GCP, you still get charged for every time you download from cloud storage, even if it's on an internal network
15:59bnieuwenhuizen: daniels: I thought that was only for different regions?
15:59daniels: bnieuwenhuizen: i don't think so, but I could be wrong!
15:59bnieuwenhuizen: (clearly, I've been making too many assumptions ...)
16:00bnieuwenhuizen: what cloud storage product do we use here?
16:00jekstrand: daniels: Oh, sure. MrCooper So am I. :-)
16:01jekstrand: As I said in my e-mail, if someone wants to plumb it all through X11, I'm happy for them to do so.
16:01jekstrand: But I don't want to count on it
16:01daniels: bnieuwenhuizen: google cloud storage, regional bucket in us-east1
16:01jekstrand: And I don't want to be painted into our current corner where implicit sync runs through every corner of the driver.
16:01jekstrand: I want to put 100% of our implicit sync interactions into dma_buf_import/export_sync_file and never think about it again. :-)
16:02bnieuwenhuizen: daniels: should be free with same location: https://cloud.google.com/storage/pricing#network-pricing (besides some per operation pricing)
16:05daniels: heh, good old Australia having its own exception to pricing structures
16:06daniels: thanks for the link :) that helps, but yeah, unfortunately all our CI execution is now outside of GCP ...
16:06daniels: FWIW, we're expecting to see the rate drop significantly once we have actual proper caching on our runners. that's blocked on getting RAID set up on them so we can use the full storage available on the physical machines, which will hopefully be done this wekeend or so. GStreamer have also been looking into some inefficiencies on their side. once that's done we should have far far higher cache hit rates
16:07daniels: (that and concentrating our runners from a fleet of smaller machines on to a lower number of more powerful machines, again increasing the hit rate)
16:13MrCooper: jekstrand: there was no need to Cc me, I already get each post from at least 4 lists
16:24jekstrand: MrCooper: Fair enough. Some people have extra stuff when they specifically get CC'd though.
16:24jekstrand: I do, at any rate.
16:25MrCooper: I get an extra copy in my inbox, and notifications
16:27ajax: daniels: happen to remember which list that thread was on? xorg-devel has like one thread between lfrb and keithp (none with and ickle), and it doesn't seem especially scheduley
16:28daniels: ajax: i have a horrible feeling that the scheduley bit was over IRC
16:30ajax: jekstrand: re x11, xserver's been made to conform to just about every rendering pipeline ever invented. you tell me what it needs to conform to and i can probably tell you how to get there, if not just write it.
16:30jekstrand: ajax: Fair enough. :-)
16:30jekstrand: ajax: Like I said, if we replace xshmfence with syncobj, I think we're basically there.
16:31jekstrand: ajax: Most of my concern is around what that's going to do to the internals of X
16:31jekstrand: Which, to be clear, I don't consider to be my problem. :-)
16:32jekstrand: From a GL/Vulkan driver POV, if we have an X SYNCOBJ extension that lets us xcb_syncobj_fence_from_fd, it's pretty quick to wire it up.
16:32jekstrand: We've already got all the APIs to pull a sync_file out of one syncobj and stuff it in another.
16:52yayiguess: So for the EVoC, is a vulkan preference tool still a need?
17:13lynxeye: robher: could I bother you to take a look at "[PATCH v4 3/4] dt-bindings: display: imx: add bindings for DCSS"?
17:16robher: lynxeye: would help if dt list was Cc'ed as it is not showing up in PW.
17:20keithp: jekstrand: sounds pretty straighforward then; just use syncobj for fencing instead of xshmfence and pass those by fd
17:21keithp: (from my very brief skim of this channel)
17:21lynxeye: robher: Uh, right. Not my submission, but I just bounced it to the DT list.
17:21jekstrand: keithp: On the surface, yes, that should do it.
17:21jekstrand: keithp: I don't know what dragons live in those caves though. :-)
17:21keithp: daniels: I don't recall any arguments about implicit sync; the only benefit it's ever had is that nVidia can't
17:22daniels: keithp: right, it was about plumbing explicit sync through the server - whether or not present should pipeline and pass the fence through to EGL/KMS, or synchronise itself against fence readiness before submitting anything
17:22robher: lynxeye: That doesn't help because PW will not pick it up and automated checks won't run. I'm replying to it now though.
17:22keithp: jekstrand: not many; we should have the hooks necessary for explicit sync already working as nVidia uses them in DIX
17:22imirkin_: nouveau doesn't really support explicit sync, but that's just a software fail, not any deeper hw reason afaik
17:23keithp: daniels: yeah, without underlying support for mailbox, it's hard to pass things along
17:23keithp: (aka replace existing queued present with another)
17:23keithp: *that* means a pile of kernel support though
17:23daniels: right, the patches that were on the list were simply adding explicit-sync plumbing to replicate the same semantics as implicit-sync through the X server
17:24daniels: and the counter-argument to merging those is that we should have full mailbox support through the stack before we move the sync model away from implicit to explicit
17:24jekstrand: keithp: I think I'm going to take a swing at wiring up sync_file with the Wayland extension today and maybe VK_KHR_display. That should get the plumbing we need.
17:24keithp: jekstrand: cool
17:24jekstrand: keithp: The VK_KHR_display stuff does use atomic, right?
17:24keithp: daniels: the counter argument to plumbing explicit sync is that it makes nVidia's life easier
17:25keithp: jekstrand: uh...
17:25keithp: I think so?
17:25jekstrand: We'll, I'll flail around for a while and see. :-)
17:25daniels: no, it doesn't use atomic
17:26jekstrand: So much for that, then.
17:26daniels: written by someone called Keith Packard and reviewed by someone called Jason Ekstrand :P
17:27jekstrand: daniels: Yeah, well. I think Keith kind-of knows what he's doing but you can't trust that Jason guy. He's clueless.
17:27MrCooper: FWIW, I think Present should wait for client fences to signal before determining the target for the present operation, for similar reasons as discussed on #wayland
17:28daniels: jekstrand: so glad he doesn't work on winsys stuff anymore!
17:28daniels: MrCooper: i totally agree on the end point there - but I think plumbing through and exposing explicit sync as an interim step is not harmful to achieving that goal
17:28jekstrand: daniels: Yeah, me too
17:29daniels: that sort of has to be the starting point regardless
17:29keithp: MrCooper: yeah, it means we might miss, but also means we don't queue something not ready
17:30keithp: jekstrand: shouldn't be hard to switch to atomic; it's not like it doesn't have all of the info sitting there
17:30MrCooper: keithp: if we miss in that case, we most likely would have missed anyway :)
17:30keithp: MrCooper: likely
17:30jekstrand: keithp: Yeah, should be mostly typing for someone who actually understands KMS
17:31keithp: MrCooper: probably want to use a separate thread monitoring fences and queueing
17:31bnieuwenhuizen: keithp: MrCooper: What is the problem with enqueueing if it misses? The fact we cannot enqueue a newer frame for e.g. triple buffering?
17:31jekstrand:wonders if he can con pzanoni into doing it.
17:31keithp: bnieuwenhuizen: yeah, we can't actually match the semantics if we queue un-finished rendering
17:32MrCooper: bnieuwenhuizen: that, and generally the visible output being prone to delays caused by client GPU work
17:32jekstrand: bnieuwenhuizen: Can radv handle exporting a sync_fd from any semaphore?
17:32jekstrand: bnieuwenhuizen: Or do you have to know at create time?
17:32bnieuwenhuizen: jekstrand: I think so
17:32jekstrand: bnieuwenhuizen: Cool
17:32bnieuwenhuizen: we certainly enabled that on Android
17:32jekstrand: Right, Android would need it.
17:33jekstrand: Trying to figure out how many feature bits I need in the WSI code
17:33bnieuwenhuizen: jekstrand: depends on a kernel new enough to support syncobj though
17:33jekstrand: So we need one from driver to WSI as well
17:33jekstrand: I can do that easily enough.
17:34MrCooper: bnieuwenhuizen: if the kernel allowed replacing pending flips, there could even be an extreme corner case where userspace would keep replacing flips before any of them could complete
17:34keithp: jekstrand: shall I try to hack the display back end to make it atomic?
17:34jekstrand: keithp: Feel free. Seems like that should be an over-all positive change.
17:35keithp: MrCooper: the kernel could keep a longer queue and pick the most recent completed one to display
17:35bnieuwenhuizen: keithp: MrCooper: Any idea what typical latency of queueing a commit is? I'm kinda wondering what the impact is on e.g. a SteamVR compositor that tries to get some last minute fallback in if the app misses. (And 1+ ms is pretty common for cmdbuffer submissions)
17:35keithp: jekstrand: 'positive' is subjective :-)
17:35jekstrand:thought atomic was "the future".
17:35keithp: bnieuwenhuizen: depends how busy the GPU is?
17:36keithp: jekstrand: a much more complicated future
17:36bnieuwenhuizen: keithp: what is the GPU business dependence here? submission with a finished fence should be mostly independent from render work right?
17:36keithp: jekstrand: in this case, it might look a bit cleaner as I won't need separate paths for 'first frame' and 'subsequent frames', I think
17:37pzanoni: jekstrand: I can try to help you, yes. I was reading the emails about this exactly when you pinged me
17:38jekstrand: pzanoni: It sounds like keithp already voulenteered to do atomic but he'd probably let you take it from him. :)
17:38keithp: bnieuwenhuizen: configuring the next frame to display *should* just be setting registers in the hardware, but I bet most hardware makes it more complicated than that; I remember the intel driver used to stick the operation in the GPU queue (ick!).
17:39keithp: jekstrand: a chance to learn an new API :-)
17:39keithp: how about I write the code and get pzanoni to review?
17:39keithp: (takes two to tango anyways)
17:39jekstrand:just got out of reviewing WSI code \o/
17:40pzanoni: feel free to cc me, while I try to udnerstand what exactly I'm signing up for
17:40keithp: pzanoni: it's the simplest possible mode setting code -- one crtc, one output, one mode
17:40keithp: (one plane)
17:44jekstrand: daniels: What will a Wayland compositor do if I give it a sync FD of -1?
17:49MrCooper: jekstrand: show you the finger? ;)
17:50jekstrand: One annoying issue with sync_file is that there's no good way to get a trivial one.
17:50jekstrand: There's no system call for "give me an already signaled dummy sync file"
17:50MrCooper: keithp: it does boil down to register writes with AMD hardware (and can even work if vertical blank has already started), but the atomic/DC code might burn significant CPU cycles to get there
17:51jekstrand: So you kind-of have to use -1 for that. :(
17:51daniels: jekstrand: you can't - FDs in the protocol are not a Maybe type
17:51jekstrand: daniels: Well, that's going to be annoying....
17:52krh: quite doable
17:52krh: could be done similar to the dma-buf builder pattern
17:53jekstrand: I could just hang on to a signaled sync file
17:54jekstrand: And just re-use the same one every time some dumb app (thanks, vkcube) doesn't give me any semaphores.
17:54bnieuwenhuizen: jekstrand: or bootstrap one with a syncobj
17:54jekstrand: bnieuwenhuizen: Yeah
17:54jekstrand: bnieuwenhuizen: That's probably the easiest way to get said dummy semaphore
17:55jekstrand: Sounds like I need to add a quick driver hook for this.
17:55bnieuwenhuizen: jekstrand: from a shareable fence that is initalized as signaled?
17:55jekstrand: bnieuwenhuizen: Ooh, good point!
17:55jekstrand: No driver hook needed!
17:57daniels: jekstrand: yeah, it's either that or we add explicit don't-sync-to-anything request or verbiage to the protocol. would need to check if that's already the case
18:20tlwoerner: ajax: thanks for updating the gsoc ideas list!
18:23jekstrand: Anyone mind of we bump mesa's required wayland-protocols version?
18:23jekstrand: It's build-time only
18:25ajax: tlwoerner: more where than came from. i'm digging through a bunch of old branches / todo lists.
18:26tlwoerner: ajax: wonderful :-)
18:30keithp: jekstrand: the atomic API involves a lot of typing, not a little
18:34jekstrand: keithp: :(
18:35keithp: properties have names, and you only get the IDs by querying properties. You'd think there'd be a call to get a bunch of ids for names...
18:36emersion: maybe libdrm could be improved for this
18:36keithp: you'd need a kernel change to make this work; discovering the name -> id mapping requires walking all resources and properties right now
18:37emersion: drmModeProperty *drmModeGetAllProperties(int fd, uint32_t *propIds)
18:39emersion: another hurdle is dealing with enums…
18:41krh: yeah, it's pretty round-trippy interface...
18:41keithp: emersion: more like drmModeGetPropertyIds(int fd, char **names, int num_names, uint32_t *ids);
18:42emersion: while at it, you could retrieve full drmModeProperty structs
18:42krh: or even better, return a big blog with all the configration info (crtc, connectors, props etc) up front
18:43emersion: anyway, doesn't really require kernel changes, can just be syntactic sugar
18:44emersion: no, syntactic
18:48jekstrand: daniels: I like this protocol. Most objects have no events!
18:48jekstrand: I don't like how long the function names are. :(
18:50daniels: yeah ...
18:53jekstrand: daniels: The protocol isn't very clear on what happens if I don't set_acquire_fence
18:53jekstrand: It's clear that I can't set it twice
18:54jekstrand: I guess it just tries to implicit sync in that case?
18:54jekstrand:reads weston code
19:06jekstrand: daniels: Looks like the Wayland proto has a no-fd release. Why can't I do a no-fd submit? :-P
19:06jekstrand: The compositor can be a jerk and not provide a fd and I can't? Doesn't seem fair. :-P
19:26anholt_: would appreciate anyone else weighing in on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4099
19:31anarsoul|2: anholt_: LGTM. What about failed jobs?
19:33anholt_: anarsoul: first two were unrelated system failures, I've got a MR up for one of them
19:37daniels: jekstrand: no-fd is not having an fd-type arg
19:37daniels: rather than a fd arg which you sometimes pass nothing to
19:37daniels: we can make a no-fd version for the in-fence
19:37jekstrand: daniels: Yeah
19:37jekstrand: daniels: Meh. Doesn't help at this point
19:38daniels: or clarify that if you attach without providing an in-fence you get no sync, but that's too surprising for my liking
19:43jekstrand: daniels: I've already done the typing to pass around dummy FDs
19:46daniels: nice :)
20:31jekstrand: daniels: It seems to have worked on the first try. I'm skeptical.....
20:47jekstrand: daniels, keithp: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4169
20:47jekstrand: keithp: I don't expect you to review Wayland bits, but all the plumbing is now there if you want to wire up sync_file for KMS.
20:47emersion: that was quick :)
20:48jekstrand: emersion: I'd already written most of the interesting code for my dma-buf explicit sync stuff
20:48jekstrand: Just a matter of re-factoring things a bit
20:48jekstrand: Wiring up the Wayland protocol bits is trivial. Just a read the protocol XML and type the things.
20:49jekstrand: emersion: Gonna go hook it up in sway now? :)
20:49emersion: ahah, i'm tempted to have a look
20:51emersion: i'll have a look tomorrow, it's getting late here
20:51jekstrand: If the end result of my e-mail is that we just fix all the window systems, I'm totally cool with that. :-)
20:52jekstrand: I suspect some implicit sync will stay around for a while though. :-(
21:03emersion: tlwoerner: btw if you need a wayland GSoC mentor again feel free to ping me
21:11tlwoerner: emersion: thank you, I appreciate that very much! can I add you to the list at the bottom of https://www.x.org/wiki/SummerOfCodeIdeas/ ?
21:13tlwoerner: emersion: @gmail or @emersion?
21:14jekstrand: anholt_, eric_engestrom: What has to be done to update the CI build containers? I want to bump the wayland-protocols requirement to 1.18
21:14emersion: ah, maybe i used the @gmail because google wanted a google account
21:14jekstrand: 1.17 rather
21:16anholt_: jekstrand: you bump the DEBIAN_TAG in the container build job in the commit where you change the container's build script.
21:17jekstrand: anholt_: I don't know what that means. :(
21:17anholt_: jekstrand: as you're doing development of your change, you can either keep bumping the tag, or carefully manage your tags in https://gitlab.freedesktop.org/jekstrand/mesa/container_registry
21:17anholt_: jekstrand: 40dd418e14e8b4ef945c5cb1d9d2e295b5948706 is the simplest example.
21:19anholt_: container builds work by looking at your repo's registry, seeing if a container image with that DEBIAN_TAG exists, and using it. if not exist, check upstream repo, and if so copy it in. if either of those exist, exit with success early. if not, run the build script, and upload the resulting container to your repo under the tag.
21:20anholt_: (I'm not *exactly* sure when the upstream repo's tags show up, would have to go read the scripts)
21:21anholt_: make sense?
21:21jekstrand: Not yet
21:21jekstrand: I don't really do any of this stuff. :(
21:21jekstrand: I think I did a docker thing once
21:22jekstrand: let me read a while
21:25jstultz: dcbaker: wanted to see if you could check out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4151 when you have a chance. Don't mean to pester you, just not sure if tagging you in the merge req is the best way.
22:09dcbaker: jstultz: Sorry, usually I try to get stable stuff done first thing in the morning, fell free to ping me here or mention/assign me the MR
22:10jstultz: dcbaker: no worries, there's no urgent rush but I just wanted to make sure it didn't get buried way down under all the other changes
22:21jekstrand: anholt_: I'm very confused. Running 'cat /usr/share/pkgconfig/wayland-protocols.pc' in the x86_build container on my machine, it says we have 1.17 in the container but the meson build failure I'm seeing claims 1.12.
22:23ccr: perhaps PKG_CONFIG_PATH has some unusual order
22:24keithp: jekstrand: 300 lines of typing so far ...
22:24jekstrand: keithp: Mine's already done. :P
22:24keithp: I noticed :-)
22:24keithp: this API is not exactly convenient
22:24jekstrand: keithp: Now I get to learn docker so I can figure out why the CI can't build it. :-/
22:25keithp: I'm so sorry. I have minions in my projects to figure that out
22:25jekstrand: Yeah, I could probably ask a minion
22:25jekstrand: But I feel like I should know some of these things
22:26keithp:found a spare X1 to test with
22:27jekstrand: ccr: cat on the .pc file says 1.17; running pkg-config says 1.12. :/
22:30jekstrand: aha! /usr/local
22:32keithp: jekstrand: where software goes to die
22:33jekstrand: I think I found the line I need to change
22:33jekstrand: Now the question is whether or not GitLab is smart enough to re-build the container and update it.
22:34Sachiel: as long as you pay the $10000 to cover the bandwidth, it does
22:35jekstrand: dcbaker: Can we just use wraps in CI to build wayland-protocols?
22:35dcbaker: As long as it's been ported to meson, yeah
22:36dcbaker: we'll want to cache the meson wrap directory to avoid downloading it presumably?
22:36jekstrand: That was mostly a joke
22:36jekstrand: If someone can tell me how to update this stupid image, I'll be happy with that.
22:42jekstrand:gives up and hopes eric_engestrom just solves it for him while he sleeps
22:42dcbaker: well, I used to know how but it's all changed so much and gotten so complicated I don't even understand what's going on anymore
22:43ccr: hooray for progress.
22:43jekstrand: All that needs to be done is to make the build_x86 container have wayland-protocols-1.12
22:43jekstrand: 1.17 rather
22:44jekstrand: ooh, there's a README!
22:46jekstrand:thinks he may have found the secret thing to change
22:47anholt_: jekstrand: can I see your branch?
22:48jekstrand: Looks like bumping the TAG causes a re-build
22:48anholt_:may have mentioned that :)
22:48jekstrand: anholt_: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4169
22:48jekstrand: anholt_: Yeah, you did. Still learning the automagic
22:48jekstrand: It's all really simple once you know how. :P
22:48anholt_: that change does look right
23:02jekstrand: anholt_: Cool. I suppose I should plan on changing the TAG right before pushing once I get review?
23:02anholt_: jekstrand: the thing I'm doing in my branches now is having the tag be a date and topic name, so that I can't conflict with some other developer bumping the tag.
23:02jekstrand: anholt_: Yeah, that's probably a good idea
23:03anholt_: (if someone merges a change with a tag you were using, and you rebase, your next pipeline will use your WIP image in a build that expects their changes, and it sucks)
23:03anholt_: you can recover from this using the container_registry link I gave
23:03anholt_: but it sucks.
23:06airlied: not insane to just send a separate PR to just bump wayland-protocols outside your PR
23:12airlied: Lyude: did that branch get worked out?
23:13Lyude: airlied: doing it now :)
23:13Lyude: airlied: sorry for the delay, should have started this earlier yesterday
23:13Lyude: (just doing one compile check before I send the pull request)