00:05 airlied: karolherbst: btw your structureizer needs rebasing I think
00:05 karolherbst: airlied: I know, but jekstrand changes mess it up :D
00:05 karolherbst: it's not a trivial rebase
00:05 karolherbst: will look into it tomorrow (I hope)
00:09 airlied: karolherbst: cool I'll await that to rebsae the clc stuff
02:47 airlied: jekstrand, bnieuwenhuizen : what would be the easist (read non-xml way) to add experimental exts to mesa vulkan
02:47 airlied: I remember we had some once, but not sure if any examples survived
02:57 bnieuwenhuizen: Not sure. I'd recommend very much allocation an extension number in Khronos even if you don't end up publishing the ext, just so you know your enums don't conflict.
02:57 bnieuwenhuizen: After that we should probably figure out a way to splice in some extra xml?
02:58 bnieuwenhuizen: We had an intel "extension" that was just a hardcoded extra function in the generator script
02:58 bnieuwenhuizen: airlied: the intel stuff is still in src/intel/vulkan/anv_entrypoints_gen.py . search for vkCreateDmaBufImageINTEL
02:59 bnieuwenhuizen: (I very much recommend you don't do it that way)
03:02 airlied: patching the xml just seems like a rebase nighmare :-P
03:03 bnieuwenhuizen: airlied: I mean having a separate XML file and have a way for the generation scripts to be reading multiple files and making sense of merging them
03:04 bnieuwenhuizen: well, not really merging the xml, but dealing with the interactions
03:06 airlied: yeah that might work nicer
04:19 airlied: jekstrand: VK_EXT_external_memory_host was what I was looking for earlier :-P
04:38 jekstrand: airlied: Yeah, that's a thing. :)
06:15 airlied:drops the needle on llvmpipe msaa support
07:10 MrCooper: airlied: nice, congrats
07:11 MrCooper: anholt: yeah, test jobs need to depend on the container jobs as well; GitLab doesn't handle dependencies transitively
08:03 pq: Vanfanel, see https://gitlab.freedesktop.org/mesa/drm/-/blob/master/xf86drmMode.c#L883-949 - that's all there is to the mechanics.
08:05 pq: Vanfanel, as you can see, if the event is not a pageflip event, then drmHandleEvent does not call page flip event callback but something else.
09:29 Vanfanel: pq: thanks! that was the last piece I needed to undestand it all :)
09:47 dj-death: MrCooper: I was thinking about this kcmp thing for GEM handle export
09:48 dj-death: MrCooper: if we refer to the DRM implementation, we should get the same handle as the one we already have when create a new handle for a dmabuf
09:48 MrCooper: right
09:48 dj-death: MrCooper: that way we could just use that to tell whether that's something we need to close
09:49 MrCooper: no, the handles could be from different namespaces but have the same value by coincidence
09:49 dj-death: ahaha :)
09:50 dj-death: you're right dammit
09:50 MrCooper: sorry :)
10:05 hakzsam: MrCooper: mind to review (or ACK) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4873 ?
10:06 MrCooper: dj-death: no Gallium/DRI plumbing was needed for radeonsi, see amdgpu_screen_winsys vs amdgpu_winsys
10:06 MrCooper: dj-death: i.e. only de-duplicate screens when they're using the same DRM file description
11:14 dj-death: MrCooper: for that you need to create one screen per fd no?
11:43 dormito: I've tried plugging a Displayport hub into an amdgpu(kernel driver) card, and the dmesgs spit out messages about the hubs ports/connectors, however xrandr seems totally obivious to the connector (and seems to think that port is disconnected), does some/all of the x stack need support for DP MST (and doesn't have it atm)?
12:05 imirkin: dormito: all drivers that are in any danger of having MST ports attached should support them.
12:06 vsyrjala: did you actually plug in a display as well or just a lone hub?
12:06 dormito: the kernel drive appears to support it, as I said, because I see dmesgs regarding the plug event (and yes, I plugged in two displays)
12:07 dormito: however the output of xrandr doesn't match what the dmesgs seem to say
12:07 imirkin: the connectors will be named differently in X
12:07 imirkin: at the DRM level they're just DP-1,2,3,4,
12:07 imirkin: in X, it'll show the DP path as part of the name
12:07 imirkin: e.g. DP-1-8-1 or whatever
12:08 dormito: yeah that's what I am say, xrandr doesn't show any new ports, and shows all displayport ports as disconnected
12:09 imirkin: dormito: grep . /sys/class/drm/card*-*/status
12:12 dormito: (give me a few moments, was rebooting to test something)
12:15 dormito: while it's booting, interesting use of grep patterns, is that significantly different from a cat of the same file-pattern?
12:16 sravn: danvet: For dw-mipi-dsi we could make a todo.rst patch based on what you already wrote. And then seek acks on that. Would that be a sensible way forward and are you up to do it?
12:16 pq: dormito, I guess it prints the name of the file, while cat leaves you wondering what file each line is from.
12:16 sravn: danvet: Same patch should ofc also cover dw-hdmi
12:17 danvet: sravn, I think so ...
12:18 danvet: but not sure my ideas verbatim are the good ones
12:18 dormito: hmm yeah that is pretty nifty, wish I'd thought of that before :)
12:20 dormito: interesting, on reboot I started getting spammed with "[drm] amdgpu_dm_irq_schedule_work FAILED src 10" ... I don't think I'd booted with the hub plugged in prevously
12:27 MrCooper: dj-death: one per file description (not descriptor!), yes
12:28 cwabbott: vulkan spec question: if you want to render to the same attachment in two different subpasses of the same renderpass (i.e., have it as a color attachment in two different subpasses) then is it necessary to add a dependency between those subpasses? i think so...
12:33 dormito: http://dpaste.com/17P6G2D also getting some... kernel traces :(
12:36 imirkin: something seems off...
12:37 dormito: do I have something configured wrong?
12:41 imirkin: dormito: no, sounds like you're hitting a bug
12:42 dormito: ah fun
12:42 imirkin: any time you're seeing WARN's in dmesg, it's not you, it's the code.
12:42 imirkin: (almost any time)
12:45 dormito: ah. I'd look into debuging it, but it's my ${DAYJOB} machine and I kind of need if for that, so I'll have to leave the MST/gpu debugging for when I have time+a suitable machine
12:53 kusma: so yeah, this is bad: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2911
12:53 kusma: TLDR; Mesa debug-builds are completely broken on Windows.
13:05 kusma: eric_engestrom: You might care about this, as 20.1.0-rc2 seems to be due today... ^
13:30 sravn: danvet: the part using a bridge as a bridge souns right
13:31 sravn: And keeping it away from display drivers too
13:31 sravn: Details of file location can be sorted out later
14:17 sravn: seanpaul, pinchartl: any feed back on https://lore.kernel.org/dri-devel/20200427081850.17512-1-sam@ravnborg.org/
14:17 sravn: "drm/bridge: support drm bridge connector helper + panel updates"
14:31 bbrezillon: pendingchaos: I don't see the access visibility bits defined in the SPIRV spec (https://www.khronos.org/registry/spir-v/specs/1.2/SPIRV.html#Memory_Access)
14:31 bbrezillon: is it part of an extension?
14:31 karolherbst: bbrezillon: this is an old version of the spec
14:32 pendingchaos: bbrezillon: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#Memory_Operands
14:32 pendingchaos: yeah, that version is too old
14:32 karolherbst: yeah.. just wanted to link to the unified1 one :)
14:34 bbrezillon: duh, that's the one I was looking at from the beginning
14:35 eric_engestrom: kusma: yeah, that looks really bad :/
14:36 eric_engestrom: as for 20.1.0 this "only" needs to be fixed before the final release, so I'll go ahead with -rc2 as planned today
14:36 kusma: eric_engestrom: fair enough.
14:37 eric_engestrom: but it definitely prevents windows from being tested to make sure 20.1.0 is working properly, so if only for that reason it should be fixed ASAP
14:37 kusma: I mean, it seems like nobody noticed for a while :P
14:37 eric_engestrom: yup, indeed...
15:10 pa: what was the way to run glxgears in soft ?
15:10 pa: envvar, but i forgot which one
15:11 pa: found i think
15:12 pa: ok that works
15:13 pa: so i have a problem with a headless app, after upgrading my system to shmubuntu 20.04. Now it crashes with X Error of failed request: BadValue (integer parameter out of range for operation)
16:05 pa: probably some issue with new mesa-glx packages
16:05 pa: unsure how to solve
19:04 pcercuei: some questions about fbdev emulation
19:05 pcercuei: looking at the code, drm_fb_helper_check_var() seems to succeed if the userspace requests a modeset to a smaller resolution, with the same pixel format
19:07 pcercuei: However, I don't see where it actually does the modeset
19:07 pcercuei: drm_fb_helper_set_par() only calls drm_fb_helper_restore_fbdev_mode_unlocked()
19:08 pcercuei: with a parameter that's never modified in check_var()
19:28 robclark: hmm, we don't have a nir pass that splits wrmask anywhere.. ie. split a store_ssbo w/ wrmask=x_zw into two instructions w/ x and xy?
19:29 Kayden: don't think so, we have the opposite
19:29 Kayden: I didn't think that writemasks were used for anything other than TCS outputs...
19:29 robclark: hmm, doesn't intel end up having to split discontiguous wrmask?
19:29 Kayden: guess those have them too, interesting
19:30 Kayden: hmm yeah we assert that store_ssbo has a contiguous writemask
19:31 robclark: hmm, ok.. I think the case I'm seeing is contiguous.. but just not starting at .x
19:31 robclark:was assuming that .x_yz type thing could also happen.. but maybe not..
19:32 anholt: v3d has some gross stuff for this in its backend, would love to back that out.
19:32 anholt: we did find that discontiguous writemasks were a thing in tests.
19:40 robclark: anholt: don't suppose you happen to remember where you saw discontig wrmasks? I tracked down the mh31 shader where we hit this:
19:40 robclark: intrinsic store_ssbo_ir3 (ssa_58, ssa_12, ssa_0, ssa_0) (2, 0, 4, 0) /* wrmask=y */ /* access=0 */ /* align_mul=4 */ /* align_offset=0 */
19:42 robclark: the annoying thing is that we don't have a constant offset in store_ssbo, to turn that into wrmask=x in a sort of generic way (without throwing alu instructions at it)
19:50 Venemo: is there a NIR helper for finding the usages of an SSA def?
19:51 pendingchaos: nir_foreach_use and nir_foreach_if_use?
19:52 Venemo: thx pendingchaos I think I need nir_foreach_use
19:53 Venemo: tho I'm not exactly sure if I should use that or the _safe variant
19:53 Venemo: what is the difference between those?
19:53 karolherbst: _safe is for when you modify the list as well, no?
19:56 Venemo: ah, ok
19:57 karolherbst: apparently it's safe to modify the list as long as the next entry stays the same.. this is what list.h asserts on at least
19:57 Venemo: okay
19:57 karolherbst: but if the next entry can change while looping you need to use _safe :)
19:58 Venemo: hmm, nir_foreach_use is for nir_src, not nir_dest
19:58 Venemo: I guess I can use nir_src_for_ssa with the dest's ssa def
19:59 karolherbst: Venemo: yeah, you just need to check if the dest is an ssa value
20:00 karolherbst: Venemo: huh, but &dest.ssa should be enough, no?
20:00 karolherbst: why nir_src_for_ssa?
20:00 Venemo: I misunderstood
20:00 karolherbst: okay :)
20:00 Venemo: the first arg of the marco is the variable you foreach over
20:00 Venemo: not the src whose uses you examine
20:01 karolherbst: yeah
20:05 Venemo: can you get the nir_shader from a nir_instr?
20:14 karolherbst: yes
20:15 karolherbst: Venemo: it's not easy though.. you would have to follow the node back to the outer parent
20:15 karolherbst: and then you get the function
20:15 karolherbst: which points to the shader
20:15 karolherbst: using the shortcut through the nir_block doesn't really make it easier
20:16 karolherbst: just store the pointer to the shader ;)
20:18 Venemo: ok
20:21 Venemo: how do I replace just one src of an instruction? all the examples I found replace all uses of an ssa_def, but I just want to replace one particular use
20:26 pendingchaos: nir_instr_rewrite_src
20:38 Venemo: cool
20:40 Venemo: hm, I just realized that may not be what I need to do actally
21:18 austriancoder: should it be possible to use xvfb to test a renderonly gpu? I do not have any kms device atm (driver not upstream yet) but I want to use the gpu to run some tests
21:19 anholt: austriancoder: vkms *should* be the solution to this, I used that with some hacks and renderonly and then a vnc-type screen scraper (lightpipe) when I was doing v3d.
21:19 imirkin: austriancoder: fwiw i definitely used xvfb + x11vnc to test adreno stuff
21:20 imirkin: er, maybe not xvfb ... hm.
21:20 imirkin: no. i used X proper. nevermind.
21:21 anholt: looks like maybe xvfb should now be usable for it? (b2a0d6065d86b8bf409ffae41180662560c42ce7)
21:21 anholt: but I would still recommend vkms since you're going to want renderonly to work, anyway.
21:22 austriancoder: anholt: ahhh
21:24 anholt: watch out: vkms needs to be set to write combining. really, need to be switched over to shmem helpers.