07:44ivyl: lfiedoro: do you plan to work on igt_attachemnts?
07:54danvet_: tzimmermann, [PATCH] drm/vc4: Handing the return value of drm_universal_plane_init <- I think not from a committer?
07:54danvet_: i.e. plan to push or poke mripard ?
07:55danvet_: airlied, thellstrom on the ttm mmap discussion, in i915 we also have wb mappings of incoherent buffers
07:55danvet_: and expect userspace to do the right clflush stuff
07:55tzimmermann: danvet_, i think he meanwhile got commit rights to drm-misc
07:55danvet_: tzimmermann, ah right
07:55lfiedoro: ivyl: yes, but later
07:56danvet_: might need some encouragement
07:56tzimmermann: ah, makes sense
07:56danvet_: airlied, thellstrom I think both anv and iris use that, among others
07:57thellstrom: danvet_: Why are those not wc?
07:58danvet_: thellstrom, explicit clflush is a ton faster for reading
08:07ivyl: lfiedoro: okay, I was considering snatching that from you, but if you are still willing to implement it then that's even better :D
08:14thellstrom: danvet_: So if userspace is supposed to handle that, that would only become a "problem" on unmap_mapping_range() right?
08:29danvet_: thellstrom, it's explicit in the type of mapping
08:29danvet_: so we don't change the type underneath
08:29danvet_: only really makes sense for buffers which are only ever in system memory
08:30danvet_: the fallback is to blt into a coherent system memory buffer first
08:32danvet_: so really only interesting for integrated when you don't have compressed buffers or something like that
08:32danvet_: since in all other cases you'll do the copy anyway
08:55airlied: danvet_: yeah for discrete im not sure of how useful it is
08:55airlied: but i am aware of the gotta mmap them all uapi
08:56airlied: i never checked it handles illegal aliases correct
09:15danvet_: seanpaul, your drm tracept debug still stuck, or am I just blind?
09:16danvet_: siqueira 's amdgpu tracing series looks a bit like it would want your stuff, plus drm_state_dump()
09:16danvet_: hwentlan, ^^
09:20danvet_: pinchartl, exynos bridge conversion also kept the component stuff, I asked whether that can be dropped too and instead using the of_ functions
09:20danvet_: forgot to cc you & sravn
09:27danvet_: thellstrom, [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory <- might be good to have your take on this
09:27danvet_: I think ideally we'd roll this out everywhere, and ttm is about the only library that currently even handles this
09:27danvet_: *only library in drm
09:30thellstrom: danvet_ I had a brief look the other day and it looked good to me. I liked the idea of two separate pointers enabling full __iomem annotation which TTM doesn't have. I'll take a closer look today.
10:05pinchartl: danvet_: I've seen that. thanks for pushing :-)
10:52lfiedoro: ivyl: feel free, it will take some time for me to get to it
11:46danvet_: robclark, been pondering the sched_fifo kms stuff a bit more
11:46danvet_: I think switching to highprio queue by default for the commit work would make sense
11:46danvet_: and leave vblank worker at fifo
11:46danvet_: for the android case add a SET_RT_KMS_MODE ioctl or so
11:47danvet_: and ask the rt/sched folks how that should look like
11:47danvet_: maybe their take is that we should sched_deadline for this
11:47danvet_: or maybe they have a way already for this, since I'm sure we're not the only subsystem with worker threads and stuff
11:48danvet_: and maybe we'd use the SCHED_FIFO/DEADLINE/whatever only for pure flips
12:09danvet_: melissawen, [PATCH v2 16/21] drm/vgem: Introduce GEM object functions <- do you want to review this one and the vkms patch in the same series?
12:17melissawen: danvet_, I'll check it at the end of the day... I was not very responsive these days because of my xdc presentation, sorry... but after that I'm back.
12:17danvet_: melissawen, sure, that's more important :-)
12:36tjaalton: hum, how to get mesa 20.2 find llvm-config-11?
12:37tjaalton: seems to be meson to blame
12:37tjaalton: it stops at 10
12:41tjaalton: dcbaker[m]: ^ there should be a way to override this from mesa, and not rely on meson to DTRT
12:47kherbst: tjaalton: you can specify the llvm-config path with meson already
12:54MrCooper: tjaalton: ^ using a native file (similar to a cross file, --native-file=)
12:57pq: btw. if you don't run a udev daemon (like in a container or VM), can you still get DRM hotplug events? Do you need to do anything different in the KMS client compared to what you do on a normal system?
12:57pq: IOW, does libudev paper over the lack of the daemon?
12:59siqueira: seanpaul, danvet_ are you talking about this patch: https://patchwork.freedesktop.org/patch/348622/?series=72013&rev=1 ?
13:00anholt: itoral: sorry for missing the talk this morning. missed that the schedule was utc+2, not utc.
13:00seanpaul: danvet_: yeah, still stuck, no action on reviews
13:00seanpaul: siqueira: https://patchwork.freedesktop.org/series/78133/
13:01siqueira: Thanks, I'm going to take a look on that and try to review it.
13:04kisak: hmm ... for whatever reason the youtube addon for Kodi on the RPi made it hard to bring the XDC livestream up. no reasonable searches found the live stream, but found day 2 and 3. Ended up looking up the xorg foundation page and getting to it from the playlist section.
13:21tjaalton: kherbst, MrCooper: okay, good to know!
13:52dcbaker[m]: tjaalton: yeah, native and cross files. I'll add llvm-config-11 to meson today
13:53tjaalton: turns out setting PATH is easier
14:14robclark: danvet_: on one hand, getting 60fps (or whatever the refresh rate is) is arguably a realtime task, so display (and gpu) have a right to use FIFO.. but I suppose it also does come down to what userspace does, so maybe opt-in is a reasonable thing.. and switching to kthread_work makes it easy to switch..
15:06Lyude: kt/j ##xdc2020-QA
15:27mripard: in the event where there's two CRTC currently enabled, and one wants to modify the configuration of a single one, is the drm_atomic_state supposed to contain both the old state of the untouched CRTC and the new state of the modified CRTC, or only the new state of the modified CRTC ?
15:28agrisis: I'm using drmModeSetCrtc and it apparently blocks until vsync, should I be looking to use drmModePageFlip instead?
15:28agrisis: or is there a way to entice drmModeSetCrtc to not wait for vsync?
15:31MrCooper: agrisis: drmModeSetCrtc doesn't wait for vblank with all drivers, there's no way to control it
15:32MrCooper: agrisis: drmModePageFlip does sync-to-vblank by default; can be disabled by DRM_MODE_PAGE_FLIP_ASYNC, but not all drivers support that (check DRM_CAP_ASYNC_PAGE_FLIP)
15:33agrisis: MrCooper: I'm getting an invalid argument when calling drmModePageFlip. If I wanted to check for async capability (or non-vsync in general), I assume I need to look at the kernel driver for my drm device?
15:34MrCooper: check the cap
15:36MrCooper: with drmGetCap
15:36pinchartl: mripard: drm_atomic_state is really a drm_atomic_commit. it doesn't need to contain the full state of the device
15:36pinchartl: just the parts that are touched by the commit, and their dependencies
15:37agrisis: MrCooper: it returned 1 =)
15:37agrisis: MrCooper: I'll try to rework my code to use it, thank you!
15:38mripard: pinchartl: that's what I was afraid of :)
15:39MrCooper: agrisis: the flip ioctl can fail with EINVAL for various reasons, the rabbit hole starts at drivers/gpu/drm/drm_plane.c:drm_mode_page_flip_ioctl
15:39agrisis: MrCooper: one other question, on my desktop for example, if I disable vsync, an fps of 200 still shows reasonably well, is it in fact drawing each frame or is it skipping frames if I don't see much tearing?
15:40pinchartl: mripard: your .atomic_commit() can add additional dependencies if needed by your platform
15:40pinchartl: sorry, .atomic_check()
15:40agrisis: MrCooper: I understand my question probably has a lot to do with the actual implementation, but just curious if you could posit
15:40mripard: my issue is that on the RPi4, there's two controllers involved as CRTCs, one to do the composition, and 5 (I think?) to actually generate the timings
15:41MrCooper: agrisis: Xorg or Wayland? Which kernel driver?
15:41mripard: the composition one (the HVS) has 3 fifos, that can be routed to the timings one (the pixel valve)
15:41agrisis: MrCooper: let's say i915 in Xorg
15:41mripard: and that route is controlled through a mux
15:41mripard: I used to have the FIFO (and mux) assigned in atomic_check and enforced in atomic_commit
15:42mripard: but then, I'm not sure how in atomic_check I can find the list of FIFOs already assigned to other CRTCs
15:42MrCooper: agrisis: with compositing or without? Fullscreen or windowed app?
15:42agrisis: MrCooper: without compositing, fullscreen
15:43agrisis: MrCooper: the reason I ask is because I'm working on an embedded device that uses Rockchip DRM/KMS in kernel 4.4, and curious what might happen if I'm able to bypass this apparent vsync
15:44MrCooper: then the answer (ignoring something like TearFree) is: each frame is drawn to an offscreen back buffer, then copied to the buffer being scanned out by the GPU
15:44agrisis: so if there are 3 back buffers, then presumably they could just get overwritten by the producing side faster than the gpu can display them?
15:45agrisis: and if the monitor is 60hz
15:45daniels: agrisis: I think you're measuring the wrong thing - are you sure the cap actually comes back as 1? because Rockchip doesn't support async ttbomk
15:46agrisis: ret = drmGetCap(vid->fd, DRM_CAP_ASYNC_PAGE_FLIP, &val); // ret == 1
15:46daniels: you need to look at val, not cap
15:46agrisis: sorry, val
15:46daniels: *not ret
15:47agrisis: ASYNC capable ret 0 val 1
15:47daniels: hmm, not sure why the cap is exposed then, but Rockchip only supports async updates on the cursor plane, not on the primary plane
15:48MrCooper: agrisis: AFAIK GPU drawing is always serialized with Intel HW
15:48agrisis: in the kernel: rockchip_drm_mode_config_init() has dev->mode_config.async_page_flip = true;
15:49daniels: agrisis: look at vop_plane_atomic_async_check()
15:49daniels: (also that line isn't there in the upstream kernel, so I guess you have some fun downstream derivative)
15:50agrisis: daniels: interesting. Yeah, I'm using rockchip's linux tree which is 4.4
15:50agrisis: so I presume I won't be able to push frames faster than 60fps?
16:13pinchartl: mripard: you can pull the current state of other crtcs in atomic_check
16:14mripard: yeah, that's a good idea
16:15mripard: thanks :)
16:15pinchartl: mripard: with drm_atomic_get_crtc_state()
16:15pinchartl: it will result in commits for the two CRTCs being serialized though
16:15pinchartl: so you should only do so when there's a modeset
16:15pinchartl: otherwise page flips will suffer
16:16pinchartl: (if I remember how it works, someone may want to confirm this)
16:20MrCooper: agrisis: if you don't care about artifacts like tearing, you can always keep drawing to the buffer being scanned out :) (that's Xorg's default mode of operation)
16:21agrisis: MrCooper: yeah I don't mind. But I'm still struggling with drmModeSetCrtc blocking on vsync
16:22agrisis: drmModePageFlip isn't working for me either
16:22mripard: pinchartl: if it's only a page flip, then the muxing shouldn't change so that should be ok
16:32mripard: pinchartl: awesome, just adding the call to drm_atomic_get_crtc_state made everything working :)
17:20thaytan: Lyude, I'm watching the OUI/backlight thread, but haven't had time to recompile a kernel and test yet
17:20Lyude: thaytan: np-hopefully everything should just work, as I've actually got my hands on both intel backlight variants locally
17:21Lyude: feel free to test if you get a chance, we've got plenty of people looking at this and testing so it isn't a big deal either way
18:30jekstrand: karolherbst: I now have a shader which reproduces a structurizer bug with three blocks. :D
18:31jekstrand: karolherbst: block_0 ends with "goto block_0 if ssa_351 else block_1"
18:31jekstrand: That breaks it
18:31jenatali: jekstrand: Now we just need a fix :)
18:32jekstrand: jenatali: :P
18:33jekstrand: I don't know that it's the same bug that I faced before but it's still fun
19:07jekstrand: cwabbott: If A block is its own predecessor is it in its own dominance frontier?
19:07cwabbott: jekstrand: yeah, that's right
19:07jekstrand: Ok, nir_dominance is busted then
19:07cwabbott: I highly doubt that
19:08jekstrand: cwabbott: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6750
19:08jekstrand: cwabbott: dEQP-VK.graphicsfuzz.struct-and-unreachable-infinite-loop
19:09cwabbott: I've totally forgotten how that stuff works, but it was lifted pretty directly from the paper
19:09airlied: jekstrand: I assume the shader is actually reducible
19:13jekstrand: cwabbott: Found the bug. It's because we check predecessors > 1 but the loop is happening on block0
19:13jekstrand: So it doesn't have any predecessors
19:14jekstrand: Really, I think we want a fake start block or something likethat
19:14cwabbott: yeah, I think branching to block0 should be forbidden
19:14jekstrand: I mean, there's no reason why you can't loop to the start block
19:14cwabbott: but it means the start block suddenly has predecessors
19:15cwabbott: and you get weird stuff like that
19:15cwabbott: when it's pretty trivial to avoid, I think
19:16jekstrand: Especially because we currently treat block0 as the place where you can always put undefs etc.
19:42jekstrand: cwabbott: Worse. It had two blocks labeled block 0
19:56ajax: hah, marge finally has a user icon
20:02anholt: blame robclark
20:20cwabbott: flto: my subgroups MR has a commit adding that threadsize bit
20:27Plagman: jekstrand: btw, https://github.com/Plagman/gamescope/issues/49
20:27Plagman: is there some sort of env var backdoor we could use to tell the intel driver to avoid this CCS thing while the real ext is still undergoing completion?
20:27Plagman: like we do for R600_DEBUG=nodcc for example
20:28jekstrand: Plagman: Ugh
20:28jekstrand: Plagman: INTEL_DEBUG=norbc will disable it
20:30Plagman: i don't have a repro setup handy but can ask the user to try it out
20:41jenatali: jekstrand: Are you waiting for anything in-particular for your memcpy MR? Not trying to push, just curius
21:12anholt: krh: I'll just keep deleting code until the problems are easy, I guess.
23:47jekstrand: jenatali: I was kind-of hoping karolherbst would try it out.
23:48jenatali: jekstrand: Mmkay, sounds good
23:48jekstrand: jenatali: But if you want to get it in before your rebase of doom, I'm happy to land it.
23:48jekstrand: I doubt there's anything controvertial in there.
23:48jenatali: I think we're still a little ways away from that rebase of doom
23:48jenatali: at least for the CL side of things
23:48karolherbst: jekstrand: to try out what?
23:49jenatali: karolherbst: memcpy
23:49karolherbst: I guess I can do that
23:50karolherbst: just tell me what MR, what CTS test and I'll take a look tomorrow :p
23:52jekstrand: karolherbst: I was testing with tests/cl/program/execute/calls-large-struct.cl in piglit
23:52jekstrand: karolherbst: Lots of struct copy cases trigger it
23:52jekstrand: karolherbst: I don't know of a specific CTS test which does
23:53karolherbst: I guess that works as well
23:58jenatali: jekstrand: How opposed would you be to nir/vtn compiler/meson defines to strip down code size?
23:58jenatali: Things like removing nir_print_shader or opcode names from SPIR-V parsing errors