01:05 anholt: spending 4 cores on python to run piglit on the workstation, I really need to do that extension of deqp-runner to piglit. :/
01:11 dcbaker[m]: anholt: have your tried my swineherd runner?
01:12 dcbaker[m]: https://gitlab.freedesktop.org/dbaker/swineherd
01:14 anholt: hmm. have to parse json to figure out your regressions?
01:15 dcbaker[m]: I have a branch for junit of that's easier
01:16 anholt: mostly I want what I have with deqp-runner, where you get reports as you go of your regressions by passing in a baseline results set.
01:16 anholt: but junit would be nice for CI (assuming you can clamp to a maximum number of fails)
01:17 dcbaker[m]: Ah, i could probably add such a feature. Mostly so far swineherd is just piglit with less features and less memory/cpu consumption
01:18 dcbaker[m]: The only thing that doesn't work yet is the multiple shader runner year at a time mode
01:19 anholt: oh, and flake detection.
01:26 jenatali: \o/ I got GLX in WSL to create a D3D device, hooray
02:50 ajax: what the actual shit
02:52 ajax: out of an abundance of masochism i try to look at the roundeven test xfail on ppc64le
02:52 ajax: 3 float: expected 1.000000 (0x1p+0) from _mesa_roundevenf(0.000000 (0x1.000000008p-148)) but got 0.000000 (0x0p+0)
02:54 ajax: that's trying to do _mesa_roundevenf(nextafterf(0.5, 1.0)) but it's somehow 0.0+FLT_MIN...
02:55 ajax: nextafterf() can't be that broken
03:04 zmike: sounds like a job for choose_pdev()
06:54 hakzsam: dcbaker[m]: yes, the backport looks good to me
07:00 endrift: Quick question: is there an env var I can pass to make an app using Mesa for GLX to make GL context allocation fail outright? I know the ones that cap version or disable extensions or the like, but what about one that makes it just not work?
07:03 endrift: I tried setting MESA_LOADER_DRIVER_OVERRIDE to something invalid but it just falls back to swrast
07:04 ajax: endrift: set that and also set like LIBGL_DRIVERS_PATH=/tmp so it won't find any drivers?
07:05 ajax: (what are you even doing that you want this)
07:05 endrift: oh, LIBGL_DRIVERS_PATH="" works
07:05 endrift: testing error handling and fallback paths in my software
07:05 endrift: people have complained that it crashes if it can't get an OpenGL context, so I need a way to simulate that :P
07:06 ajax: heh, fair enough
10:18 pH5: danvet, pinchartl: I had promised to rework/squash the imx driver changes on top of the drmm patches, but haven't gotten around to finish that yet. the drmm patches themselves have not changed from v3.
10:33 pinchartl: pH5: thanks for the replies
10:34 pinchartl: danvet: would you be OK with allowing NULL drm_encoder_funcs ?
11:38 sumera: #join sumera-kernel-outreachy
11:39 sumera: oops, please ignore that. wrong window * facepalm *
12:47 Bertl: greetings! I'm old fashioned and using compiz for years now and every now and then it locks up and I have to restart it ... recently I found a way to trigger the issue relatively easily and some investigation showed that it seems to hang in dri3_fence_await()
12:49 Bertl: this is called from dri3_get_buffer() and looking at the mesa 20.2.3 codebase (the version my distribution currently uses) made me wonder how the dri3_fence mechanism actually works?
12:51 Bertl: could somebody here give me a short overview and maybe some pointers what to investigate next?
13:43 danvet: pinchartl, sure
13:43 danvet: I think helpers in general support that already
13:55 ajax: Bertl: dri3 fences are wrappers around futexes. the libxshmfence source code (sadly underdocumented but also quite straightforward) is at https://gitlab.freedesktop.org/xorg/lib/libxshmfence/
13:55 ajax: Bertl: the dri3 protocl generally is documented at https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/dri3proto.txt
13:56 ajax: Bertl: if you're hanging awaiting a fence from the client's perspective it more likely means that the X server is stuck trying to accomplish something
14:01 Bertl: I see, thanks for the explanation!
14:03 tzimmermann: danvet, hi! about the vmap discussion: can we leave pin aside and focus on the reservation lock?
14:04 Bertl: ajax: the reason why I suspect mesa/compiz code is that the way I can now 'trigger' it is basically during a specific window open/close action where both seem to (almost) overlap
14:05 danvet: tzimmermann, the rule we want is that you can all vmap if you're either pinned (somehow) or hold dma_resv_lock
14:05 danvet: not sure how you can leave the pinning side out here
14:06 danvet: also I think i915 grabs dma_resv_lock in its callbacks
14:06 danvet: or will, once the locking rework has landed
14:06 danvet: so just dma_resv_lock is tricky
14:06 danvet: i915 doesn't pin at attach time, so we have to pin in vmap
14:10 tzimmermann: danvet, let me explain: my original goal was to get radeon to work with generic fbdev. i cannot pin the BO in vmap for the reasons explained in the discussion. but just holding the resv lock during damage blitting would be sufficient. i looked through all exporters; ATM only vram helpers acquire the lock in vmap. those are fixed by my patchset. my proposol would be to not have exporters acquire resv in their vmap code.
14:10 tzimmermann: that's all i'd really need
14:12 danvet: yeah the i915 patches to move over to dma_resv haven't landed yet
14:12 danvet: so essentially we're just blocking those patches on your work
14:13 danvet: so I guess intel team then gets to add the entire dma_buf_vmap_local scaffolding and clean it all up
14:13 tzimmermann: davnet, one could rather say generic fbdev benefits the whole drm ecosystem. i915 only benefits i915
14:13 tzimmermann: danvet ^
14:14 tzimmermann: but i915 doesn't use generic fbdev, so they'd still be good for now
14:15 danvet: this isn't just a hack for fbdev generic helpers
14:15 danvet: this is the dma_buf interface
14:15 danvet: yolo locking design is really not so great imo
14:16 tzimmermann: how do you want the dma_buf_vmap_local to look like?
14:16 danvet: and I really don't see why we can't do this cleanly, with a new dma_buf_vmap_local
14:16 tzimmermann: how do you want the dma_buf_vmap_local to look like?
14:17 danvet: dma_resv_assert_held + kerneldoc says you can use the pointer beyond that locking section
14:17 danvet: plus also ofc the rule that exporters can't take that lock
14:17 danvet: also would mean it's optional
14:18 danvet: at that point maybe just do it for gem only
14:19 tzimmermann: users of dma_buf_vmap_local would acquire resv before calling into drm_buf_vmap_local() ?
14:19 danvet: the trouble with dma-buf is, at least with the dynamic attachment stuff that was the case, that it's kinda broken already
14:19 danvet: and adding dma_resv anywhere in existing stuff exposes that
14:19 danvet: so solution for the dynamic attach stuff was to not change anything at all, and make the dynamic stuff follow entirely new opt-in interfaces for both sides
14:19 danvet: tzimmermann, yup
14:20 danvet: essentially if you want to make dma_resv_lock mandatory in some form
14:20 danvet: it needs to be pulled out all the way to top most caller
14:20 danvet: so with the dynamic dma-buf stuff the caller is always taking the lock for the exporter
14:21 tzimmermann: and exporters would provide new dma_buf_op callbacks vmap_local and vunmap_local ?
14:21 danvet: for vmap we could probably kludge around something, but it's kinda inconsistent
14:21 danvet: tzimmermann, that, or some kind of flag or something
14:22 danvet: unfortunately we can't do the check in dma-buf.c because it's not aware of all the pinning that's going on
14:22 danvet: since some pin at attach, others only when needed
14:23 danvet: that's why I think caller has to give us the hint which case it is
14:25 tzimmermann: danvet, so far, vmap_local seems easy. but why is attach relevant for vmap_local? espscially if there's a separate callback with different semantics?
14:25 danvet: because for the drivers that don't pin in vmap, attach pins instead
14:25 danvet: and atm all importers attach, even if they don't need to
14:29 tzimmermann: my understanding was that vmap_local does not pin at all. i would even require its users to hold resv around vmap_local/vunmap_local, because it's only for short periods of time
14:29 tzimmermann: that should avoid the need for pinning (?)
14:40 danvet: tzimmermann, yes, vmap_local would completely avoid any pinning
14:41 danvet: the attach only comes in for the current vmap, because it provides the pinning in some cases
14:41 danvet: if we'd want a single ->vmap callback for exporters (and gem_bo_funcs) then we'd need to somehow untangle that I think
14:41 danvet: but just entirely parallel ->vmap_local is quicker to roll out I think
14:42 danvet: and it shouldn't put up roadblocks for eventually unifying this in the future
14:43 danvet: where we'd only have a single ->vmap callback in ops structs
14:43 danvet: and dma_buf_vmap would call ->pin + ->vmap, while dma_buf_vmap_local would only call ->vmap
14:43 danvet: and dma_buf_vmap would take dma_resv_lock for current callers, since they don't
14:46 Vanfanel: Hi! Until recently, I was building mesa from latest git sources with this configuration: "meson -Dglx=disabled -Dplatforms= -Dllvm=disabled -Dvulkan-drivers=broadcom -Ddri-drivers='' -Dgallium-drivers=v3d,vc4,kmsro -Dbuildtype=release"
14:46 Vanfanel: That would give me working v3dv on the Pi4
14:47 Vanfanel: But witj 2.3.0 release, vulkaninfo fails with: "vulkaninfo.c:3845: failed with VK_ERROR_INITIALIZATION_FAILED"
14:47 Vanfanel: Has something changed regarding the buildsystem with 2.3.0?
14:55 Vanfanel: Has working v3dv made into 2.3.0 release? Maybe I am wrong on assuming it has
15:10 Vanfanel: Oh... it seems v3dv Vulkan does not work on without X11 on 2.3.0, but it does on current git :(
15:10 Vanfanel: I hoped 2.3.0 would be the first version with X-less vulkan on the Pi
15:11 Vanfanel: I will have to wait I guess :P
15:27 MrCooper: Bertl_oO: when that happens, can you kill compiz and Xorg recovers?
15:31 Sumera_: danvet: I am trying to run igt tests with `sudo IGT_FORCE_DRIVER=vkms build/tests/kms_cursor_crc` but get this 'can't become DRM master' error. However when I run `sudo ./scripts/run-tests.sh -t kms_cursor_crc`, it seems to work. I am unable to figure out how run-tests.sh is able to set master device. How should I go about it?
15:38 danvet: huh
15:38 danvet: Sumera_, nothing in run-tests.sh about the magic that's going on?
15:40 danvet: Sumera_, also does it fail without forcing vkms?
15:41 danvet: and I think you can use the IGT_FORCE_DRIVER for run-tests.sh too, since it's just an environment variable, it should get passed along
15:48 dcbaker[m]: hakzsam: thanks!
15:50 Sumera: danvet: yep, fails without force vkms also, although the clients list is slightly longer for without force. let me try both together and get back to you.
15:59 danvet: mripard, are you sure your patches create proper hyperlinks on latest upstream?
16:03 mripard: danvet: I checked with make htmldocs, but maybe I missed something?
16:03 danvet: maybe it's just a difference between kerneldoc and normal sphinx
16:03 danvet: but I just spotted one &foo use that didn't hyperlink
16:03 danvet: and struct foo does
16:03 danvet: I think
16:03 danvet: testing right now
16:07 danvet: Sumera, for the run-test.sh stuff might also ask ivyl, he's the igt maintainer and iirc wrote that tool
16:07 danvet: or perhaps it was Adrinael
16:14 Adrinael: Sumera, what's in the clients list with force active? Are they really using vkms?
16:14 Adrinael: It's entirely possible that the device filters have broken IGT_FORCE_DRIVER
16:18 danvet: Adrinael, yeah on that I guess --dev name:vkms is on my wishlist
16:18 danvet: and maybe deprecating IGT_FORCE_DRIVER
16:20 ivyl: danvet: sys:/sys/devices/platform/vkms ?
16:20 danvet: oh nice
16:20 ivyl: that should work IIRC
16:20 Adrinael: danvet, wish granted
16:20 danvet: Sumera, ^^ this trick should be in docs
16:20 danvet: if it works
16:22 danvet: it seems to work
16:22 ivyl: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-gpu-tools-Device-selection.html#id-
16:22 danvet: Adrinael, well deprecating IGT_FORCE_DRIVER included?
16:23 Adrinael: That one not yet :P
16:23 Adrinael: Soon(tm)
16:23 ivyl: if anything is missing or broken patches/issues are welcome
16:35 Sumera_: Adrinael: system-logind and kms_flip- yeah I guess they are using vkms...
16:38 danvet: seanpaul, [RFC PATCH 0/2] drm: use dynamic_debug <- jump in
16:39 danvet: if this isn't outright from you guys
16:39 Sumera_: danvet: works with/without IGT_FORCE_DRIVER and run-tests.sh
16:41 seanpaul: danvet: doesn't really help us, would still overrun syslog with drm spam
16:41 danvet: seanpaul, oh I'm just throwing everything drm dbg related at you on principle :-)
16:42 seanpaul: danvet: that's fair :-)
16:55 Sumera_: ivyl : tried `sudo IGT_FORCE_DRIVER=sys:/sys/devices/platform/vkms build/tests/kms_cursor_crc
16:55 ivyl: Sumera_: this is not how this exactly works, give me a sec
16:56 Sumera_: oops, sorry. mo wonder I got a different error.
16:56 ivyl: you have to use --device switch on the test: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-test-programs-common-features.html
16:56 ivyl: there's also environemnt variable available if you prefer that instead
16:57 ivyl: and there's a tool called lsgpu (builds with IGT) that allows you to test the filters out
16:57 ivyl: lsgpu --help
16:58 ivyl: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tools/lsgpu.c - I don't think that the docs from tools are included in the HTML docs, I remember there was an issue for that
17:02 ivyl: It may be the time to get that fixed + mention the device selection in the README + deprecate IGT_FORCE_DRIVER
17:03 Sumera_: ivyl: oh right, so I pass the location to --device instead?
17:04 ivyl: Sumera_: yep, the lsgpu.c has a bit more details in the comments on how this works
17:08 MrCooper: danvet: I honestly think all that messing with Linux headers for Windows builds is just delaying the inevitable
17:27 Adrinael: Sumera, if you prefer env variables, IGT_DEVICE is the var that takes filter strings
17:50 Vanfanel: Hi. I have a Vulkan backend in SDL2 which is failing because vkQueuePresentKHR() is returning VK_ERROR_SURFACE_LOST_KHR. I have gone deeper and it seems that MESA is returning exactly here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/vulkan/wsi/wsi_common_display.c#L1742
17:52 Vanfanel: Any idea on why could be MESA falling there? I mean, what does ENOSPC being returned by drmModeSetCrtc()????
17:53 Vanfanel: The physical device is accessed from two different places: could that be the cause of the ENOSPC?
17:55 vsyrjala: drm.debug=0x1e and see what the kernel says
17:56 vsyrjala: should show somehting at least if it's coming from kms side
17:57 vsyrjala: and i think it shoud say the fb is too small
17:59 Vanfanel: vsyrjala: thanks, let's see :)
17:59 MrCooper: kind of ironic for ENOSPC :) "not enough space for this framebuffer, it's too small"
18:00 vsyrjala: it's rather 'the fb doens't have enough space for your src viewport'
18:00 MrCooper: makes sense
18:02 vsyrjala: one of those rare cases where there is a semi-reasonable errno value we can use
18:03 vsyrjala: though it still has the problem that something else might also return -ENOSPC, so can't really know what it's saying until you check the logs
18:04 Vanfanel: vsyrjala: This could be the hint, right? -> [11353.733278] [drm:drm_framebuffer_check_src_coords [drm]] Invalid source coordinates 1920.000000x1080.000000+0.000000+0.000000 (fb 640x480)
18:05 vsyrjala: yes. you can't scan out a 1902x1080 region from a 640x480 fb
18:06 Vanfanel: vsyrjala: Ok, now I need to find where have told Vulkan to scan a 1080p image... thanks!
18:07 vsyrjala: since it's using legacy kms uapi that would be the current_drm_mode
18:08 Vanfanel: vsyrjala: do you mean the current_drm_mode is supposed to be 1920x1080?
18:09 vsyrjala: if your fb is 640x480 your need your mode to be <=640x480
18:09 vsyrjala: atm it must be using a 1920x1080 mode, which is why it fials
18:12 Vanfanel: vsyrjala: there's something I am missing here. According to what you wrote, mode must be <= fb size. Shouldn't be the opposite?
18:13 vsyrjala: no. mode determines how large a chunk of the fb you scan out. fb needs to be at least the same size, or bigger
18:15 Vanfanel: vsyrjala: yes, makes sense now. Thanks!
18:27 Sumera__: ivyl: I tried sudo build/tests/kms_cursor_crc --device "/sys/devices/platform/vkms" and also with IGT_DEVICE. They both don't give expected results, although what is interesting is both give different results. Also I tried lsgpu but the command is not being recognised-maybe I have not installed igt-tools correctly?
18:31 anholt: jasuarez: congrats on getting vc4 ci enabled!
18:50 Bertl_oO: MrCooper: yes, X recovers when I kill -9 compiz and restarting compiz works fine as well
18:57 melissawen: Sumera__, IGT_FORCE_DRIVER still works for me... I guess are you trying to run tests on graphical level, in this case you should switch to text mode (without GUI stuffs)
19:06 daniels: jasuarez: ++ awesome
19:19 danvet: MrCooper, yeah for amdgpu_drm.h stuff real work needs to be done
19:19 danvet: but stand-alone drm_fourcc.h seems reasonable, and other people seem to care too
19:22 emersion: yeah, i think stand-alone drm_fourcc.h would be nice too
19:23 emersion: however i don't like the suggested solutions
19:23 emersion: (rely on users to include the right header before drm_fourcc.h)
20:54 anholt: trying to run mesa's unit tests with asan enabled is so sad.
20:56 dj-death: anholt: it's just an opportunity to increase your commit count