01:03 CounterPillow: Does implementing the DRM atomic API require specific hardware support or is the lack of its implementation in the select few older drivers caused by a lack of developer time? mpv recently removed its support for the legacy DRM API, and now they have a nouveau user complaining.
01:04 airlied: CounterPillow: lack of developer time, radeon and nouveau probably being the two main ones
01:05 airlied: nouveau.atomic=1 might work around it, might also explode
01:05 CounterPillow: Alright, thanks!
01:22 alyssa: airlied: so, nouveau :p
01:28 airlied: alyssa: I hear you are rewriting it in rust :)
01:28 airlied: I definitely heard that from zmike :-P
01:29 zmike: I heard it from gfxstrand
01:36 DemiMarie: The less C the better!
01:37 DemiMarie:hopes to see i915/Xe and amdgpu rewritten someday
01:39 DemiMarie: Is there something that can be done about https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113?
01:39 DemiMarie: In Qubes OS, applications started in disposable VMs will always have an empty cache (they start with a completely blank /home) so this case actually matters.
02:25 airlied: dakr: I assume that nouveau fix will land in drm-misc-next-fixes
02:34 airlied: dakr: also is that patch from a base on top of your gpuva reworks?
02:37 ayaka_: karolherbst, you could have a look at topic "[RFC]: shmem fd for non-DMA buffer sharing cross drivers"
02:40 airlied: didn't that idea get shut down?
02:41 airlied: not sure anyone needs to say much after daniels last comment on the thread
04:09 ayaka_: airlied, I just make someone know the answer
06:37 sima: koike, daniels btw are there more acks to add to the ci patches?
06:53 sima: koike, robclark daniels also thoughts on some cover letter draft https://paste.debian.net/hidden/b461fd13/
07:49 javierm: tzimmermann: thanks for your quick feedback. Could you please also take a look to https://lists.freedesktop.org/archives/dri-devel/2023-August/419937.html, in particular patch #5
07:49 javierm: https://lists.freedesktop.org/archives/dri-devel/2023-August/419936.html
07:49 tzimmermann: i can do that later today
07:50 javierm: tzimmermann: thanks! daniels had some concerns about the lack of setting for the modifiers flags but I don't see why that should be related to Geert's patch
08:40 melissawen: sima, koike, will we not include vkms and vgem to this initial ci?
08:41 melissawen: I remember mairacanal already asked it in a previous series, but it seems she was ignored.. or I just didn't find the follow-up
08:46 melissawen: Also, vkms already has a mustpass list on IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/tree/master/tests/vkms_ci
08:48 sima: melissawen, sounds like solid follow up
08:48 sima: melissawen, mairacanal also maybe drop an ack on koike's patch as a "yeah we can build up more on this"?
08:52 melissawen: sima, the idea is to introduce this v11 first and only after applying it, we send a patch for VKMS (?)
08:53 sima: yeah
08:53 sima: step 1. drag this onto dri-devel
08:53 sima: step 2. more collaboration
08:53 sima: or something like that
08:56 sima: so acks that you're on board with step 2 essentially very much appreciated
09:08 mairacanal: melissawen, i talked to koike this weekend and she's working on a follow-up patch to enable vkms on the ci
09:11 melissawen: sima, mairacanal, sounds reasonable, thanks
10:29 pendingchaos: eric_engestrom: is 23.1.7 going to be the last 23.1 release?
10:29 pendingchaos: since 23.2 doesn't seem to be happening
10:38 MrCooper: on Intel GPUs, does Vulkan Video expose a separate command queue, or is it the same queue as for GFX/compute?
10:48 dj-death: MrCooper: separate
10:50 MrCooper: cool, thanks
10:51 kode54: wondering when stable igt-graphics-tools will call the compute queue "Compute" and not leave it labeled "Unknown" in intel_gpu_top
10:52 austriancoder: robclark: you wanted images and you get svg images :) It is not perfect but it should better than before - https://austriancoder.pages.freedesktop.org/-/mesa/-/jobs/48226296/artifacts/public/drivers/freedreno/ir3-notes.html#instruction-reference
11:43 cwabbott: zmike: it's a bit sad that we're not using GPL on zink+turnip, I think we can enable smooth lines on turnip but I don't think we can ever enable stippled lines
11:44 cwabbott: it's not in GLES or D3D so it's not there in the HW
11:44 cwabbott: the only thing there is something to help with the GS emulation
11:45 zmike: I've been considering workarounds for it
11:45 cwabbott: and we have 0 infrastructure for doing that type of emulation in turnip, because we support it would be only for this one stupid case
11:46 zmike: ultimately it comes down to either having some ctx info to pass through an API type and only check stipple for desktop GL or tell people to set the env var
11:47 cwabbott: there isn't enough room in the optimal key for this 1 bit?
11:47 zmike: i think it's more than one bit? but also there's CPU implications to adding it there
11:48 zmike: it pulls in the entire GS infra
11:48 zmike: so the better solution is to just set the env
11:52 zmike: once it's all working a bit better I'm planning to add that to ci since optimal keys coverage on turnip is more important than stipple
12:37 koike: melissawen sima I met mairacanal in person this weekend and we talked about vkms, I already have a draft patch for vkms. mairacanal could you please check this https://gitlab.freedesktop.org/helen.fornazier/linux/-/jobs/48195449 ? If you browse the artifacts on the right there is a results folder that you can find failures.csv and results.csv, it
12:37 koike: seems only 5 tests got run and only one passed, could you check if this was the expected behavior ?
12:39 koike: mairacanal only kms_sysfs_edid_timing and kms_prime* got run
12:41 koike: hmm, I guess vkms is not up, I'll check that
12:43 daniels: koike: you need to run in a VM - you can look at weston and mesa for examples of how to do this
12:47 cwabbott: zmike: yeah, just that no one will know to actually set the env variable and get better performance
12:54 melissawen: koike, thanks for working on it! and yes, it seems VKMS is not loaded... BTW, what I do to get vkms + igt running without a VM is forcing IGT to select vkms for tests: https://dri.freedesktop.org/docs/drm/gpu/vkms.html#testing-with-igt
13:00 zmike: cwabbott: you're not wrong
13:02 zmike: I don't have a good solution for it
13:02 zmike: qcom has no stipplewaivers
13:06 alyssa: can bindless textures be imported from other processes in any of GL/CL/VK?
13:06 alyssa: that is, for a driver doing explicit sync, is there any upper bound on the number of in_syncs required by a single draw?
13:08 alyssa: if each imported GL/CL texture requires an in_sync to wait on the writer in the other process, then if we can have bindless textures, we need in_syncs for every resident imported texture. Which would be slow (and probably not hit in practice) but I don't see any reason it wouldn't be allowed.
13:08 alyssa: alternatively, can buffers be imported from other processes in CL and passed indirectly (not as kernel args) so we can have arbitrarily many of them? that would give the same issue
13:08 alyssa: karolherbst: ^ you might know that one
13:10 karolherbst: the CL WG is working on cl_khr_external_memory which kinda allows you to important dma_bufs
13:10 karolherbst: _but_
13:10 karolherbst: you can't pass them indirectly and you have to use `cl_mem` objects to bind them
13:11 alyssa: is there a limit to number of such bound buffers at once?
13:11 karolherbst: only for images
13:11 alyssa: but not for other buffers which can still be external?
13:11 karolherbst: correct
13:11 karolherbst: however
13:11 alyssa: the root question here is "is there an upper bound on the # of imported dma_bufs that can be used in a single draw/dispatch"
13:11 alyssa: (across every APIs)
13:11 karolherbst: kernels have an limit on how many args you can pass into them
13:11 alyssa: s/imported dma_bufs/in_sync/
13:12 alyssa: right, I see that sleight of hand in the definition then
13:12 karolherbst: so you could say, "max 4k of input arguments" which translates to 512 pointers :)
13:12 karolherbst: or something
13:13 karolherbst: so practically you can limit it inside CL
13:14 karolherbst: seems like the absolute minimum in CL would be 1k of input data for a FULL_PROFILE device
13:14 karolherbst: so 128 pointers
13:16 karolherbst: alyssa: keep in mind that for that CL interop stuff the general approach is to do a hard explicit sync between the APIs
13:17 karolherbst: so if you use them in GL/VK and want to use them in CL, you have to aquire ownership first, which translates to "wait until GL/VK are done", then you can start enqueuing your kernels using them
13:17 karolherbst: no implicit waits
13:18 alyssa: OK
13:29 koike: daniels melissawen right, thanks
13:34 serjosna: https://www.nxp.com/docs/en/application-note/AN4522.pdf it is done slightly better than i designed, pages 17-19 describe what the underlying method of PIC32 https://people.ece.cornell.edu/land/courses/ece4760/PIC32/index_DMA_weird_machine.html is! appears that nxp semiconductors docs apply to pic32 too, the cyclic mode dma blocks program the cell size aka nbytes in nxp, and the source size get's subtracted from it to have 0 afterwards, cause it
13:34 serjosna: times the programming of that to the same value, so it never really moves much bytes, where i was wrong, cause i never before saw those docs, xdc i have not participated in, i would participate but it's very hard to find estonians who are not corrupted fraudulent and are not horribly bad people, otherwise i would participate, after gotten injured, linux is my hobby and yeah it comes with fully hackable X and other stuff, which keeps me interested
13:34 serjosna: and alive so to speak. So sure i would participate in XDC. I leave that one more time here https://book.rada.re/analysis/syscalls.html.
13:44 robclark: austriancoder: nice.. although that makes me realize how out of date the existing docs are.. but the generated svg looks good
13:51 koike: sima thanks for putting together the ci cover letter, lgtm.
14:12 austriancoder: robclark: great .. I will try to improve the svg's a little bit as there are some corner cases which look wired.
15:12 karolherbst: how does the preamble stuff actually works. Is it something ran once per shader to cache some computation or once per "draw"/"launch_grid"?
15:16 cwabbott: karolherbst: once per draw
15:16 karolherbst: okay...
15:16 karolherbst: I have reason to believe that load_workgroup_size can't be used in a preamble
15:17 karolherbst: or maybe not on all hardware
15:50 MrCooper: pq: my feeling is that if user space doesn't understand anything in a color pipeline description, it should ignore that pipeline; then the kernel doesn't need to hide any pipelines from user space
15:51 emersion: need to define exactly what "everything" means
15:52 emersion: imho a new prop is fine to ignore without filtering out, for instance
15:52 emersion: IOW, if a pipeline element has a prop I don't understand, I can still use it
15:57 dakr: airlied: the fix should go into v6.6. Since you've sent the pull request for -rc1 already it'd be more like drm-misc-fixes I guess.
15:58 MrCooper: emersion: assuming that prop doesn't have any effect for the operation of the element then, sure
15:59 emersion: well, userspace can't know that
16:00 swick[m]: we should standardize that for sure
16:00 MrCooper: then it could be problematic, if user space doesn't know how to make the prop a no-op
16:00 emersion: same with other KMS props really
16:00 swick[m]: but if it has a bypass prop then it should be no-op
16:01 MrCooper: emersion: exactly :) that is an unsolved issue with KMS props
16:02 emersion: i really want to fix this, but imho color pipelines dont need to try to workarounf that issue
16:03 MrCooper: don't think we can allow this ambiguity in color pipelines
16:04 MrCooper: well, I guess if some user space doesn't actually care about the result, it can ignore whatever it wants :)
16:04 swick[m]: I don't really get what the problem is
16:05 swick[m]: you can get all elements in the pipeline, even if you don't know the type
16:05 swick[m]: if it has a bypass property you can set it to true, problem solved
16:05 dakr: airlied: and yes, it is on top of some scheduler changes as well, there is no real conflict though. but I would guess the patch does not apply..
16:05 swick[m]: if it's just an informational element, it should have a prop which says so, and can this be ignored as well
16:06 MrCooper: swick[m]: maybe re-phrase to "if user space doesn't understand anything that can't be bypassed" then?
16:06 swick[m]: and isn't just purely informational, yes
16:07 swick[m]: but if you add such new ops, you could just create an additional pipeline
16:09 MrCooper: yep, and what I wrote was in response to pq's question (in the patch series thread) whether the kernel should hide such pipelines which user space might not understand (e.g. based on some handshake mechanism)
16:12 swick[m]: sigh I'm still looking at harrys patches, not yet the Intel stuff
16:17 dcbaker: kisak, mattst88, eric_engestrom: I'm back on it. Sorry for the long delay.
16:18 mattst88: cool, thanks dcbaker!
16:20 kisak: it's all good, as usual, thanks for being a release maintainer.
16:20 zmike: we believe in you dcbaker
16:21 dcbaker: thanks :)
17:40 mareko: how to enable wayland-protocols as a subproject?
17:40 mareko: in mesa
18:33 dcbaker: mareko: I had a patch, but it's super out of date `meson warp install wayland-protocols` might be enough, though the wrapdb version seems super out of date...
18:33 dcbaker: you might need to do meson setup builddir --force-fallback-for=wayland-protocols if you really need to use a subproject but the pkg-config finds something it things works
18:43 airlied: dakr: I think we use drm-misc-next-fixes until after rc1
18:44 airlied: since I don't think drm-misc-fixes gets a fast forward until rc1 releases
18:47 sima: dakr, airlied https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
18:51 dakr: sima, airlied: yeah, that's why I thought drm-misc-fixes, but as Dave said I also noted that drm-misc-fixes is not yet updated.
18:51 airlied:was just going to find that link :-)
19:11 mareko: dcbaker: I just cloned wayland-protocols into subprojects directly, and now I'm getting "src/egl/wayland/wayland-drm/meson.build:68:2: ERROR: Sandbox violation: Tried to grab file linux-dmabuf-unstable-v1.xml from a nested subproject."
19:15 mareko: I guess I can also not build the wayland platform
19:48 dcbaker: sigh, that issue.
19:48 dcbaker: let me see what the resolution on that was....
19:48 dcbaker: mareko: ^
19:53 dcbaker: mareko: .... I am absolutely astounded by the overlook on the meson side on this one. I have a trivial patch
19:59 dcbaker: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24960
22:33 mareko: dcbaker: sadly, that doesn't make the error go away (meson 0.61.2)
22:34 dcbaker: Sigh. I have 1.2.0 now. Let me see when that was fixed
22:52 dcbaker: mareko: that was fixed in 0.63.0, according to my gitfoo
22:54 dcbaker: and apparently join_paths() is supposed to work, sigh
23:15 mareko: dcbaker: thanks, newer meson and your patch fixed that, but now meson 1.2.1 seems to ignore --native-file for LLVM and picks whatever version it finds, it's bizarre
23:16 dcbaker: you can use LLVM_CONFIG=... with newer Meson I think
23:16 dcbaker: someone snuck that in when all of the objectors weren't looking
23:16 dcbaker: I'll have to look at the native file thing
23:36 mareko: dcbaker: LLVM_CONFIG doesn't do anything, it seems to use llvm-config that's not even in the PATH
23:36 mareko: this is bizarre
23:40 mareko: Native files : ../llvm_config_x86_64-linux-gnu.cfg
23:40 mareko: which has: llvm-config = '/usr/local/llvm/bin/llvm-config'
23:40 airlied: yeah meson moved to make and broke it
23:40 airlied: cmake
23:40 airlied: I had to hack that recently
23:40 mareko: but if I print the LLVM library path that it found, I get:
23:40 mareko: LLVM
23:40 mareko: Enabled : YES
23:40 mareko: Version : 16.0.4
23:40 mareko: Library dir : /usr/local/llvm-i386/lib
23:41 mareko: llvm-i
23:41 mareko: llvm-i386 is in ld.so.conf.d, but its llvm-config is not in any path
23:43 mareko: the version should be 18.0.0git
23:48 mareko: wow, I had to remove /usr/local/llvm-i386, renaming the directory didn't prevent meson from finding it, meson must really be searching /usr and picking random llvm-config it finds
23:48 mareko: that's quite something
23:49 mareko: dcbaker: ^^
23:58 dcbaker: airlied: please don’t tell me they defaulted to cmake instead of config while I was gone…