01:05anholt: spending 4 cores on python to run piglit on the workstation, I really need to do that extension of deqp-runner to piglit. :/
01:11dcbaker[m]: anholt: have your tried my swineherd runner?
01:14anholt: hmm. have to parse json to figure out your regressions?
01:15dcbaker[m]: I have a branch for junit of that's easier
01:16anholt: 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:16anholt: but junit would be nice for CI (assuming you can clamp to a maximum number of fails)
01:17dcbaker[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:18dcbaker[m]: The only thing that doesn't work yet is the multiple shader runner year at a time mode
01:19anholt: oh, and flake detection.
01:26jenatali: \o/ I got GLX in WSL to create a D3D device, hooray
02:50ajax: what the actual shit
02:52ajax: out of an abundance of masochism i try to look at the roundeven test xfail on ppc64le
02:52ajax: 3 float: expected 1.000000 (0x1p+0) from _mesa_roundevenf(0.000000 (0x1.000000008p-148)) but got 0.000000 (0x0p+0)
02:54ajax: that's trying to do _mesa_roundevenf(nextafterf(0.5, 1.0)) but it's somehow 0.0+FLT_MIN...
02:55ajax: nextafterf() can't be that broken
03:04zmike: sounds like a job for choose_pdev()
06:54hakzsam: dcbaker[m]: yes, the backport looks good to me
07:00endrift: 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:03endrift: I tried setting MESA_LOADER_DRIVER_OVERRIDE to something invalid but it just falls back to swrast
07:04ajax: endrift: set that and also set like LIBGL_DRIVERS_PATH=/tmp so it won't find any drivers?
07:05ajax: (what are you even doing that you want this)
07:05endrift: oh, LIBGL_DRIVERS_PATH="" works
07:05endrift: testing error handling and fallback paths in my software
07:05endrift: people have complained that it crashes if it can't get an OpenGL context, so I need a way to simulate that :P
07:06ajax: heh, fair enough
10:18pH5: 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:33pinchartl: pH5: thanks for the replies
10:34pinchartl: danvet: would you be OK with allowing NULL drm_encoder_funcs ?
11:38sumera: #join sumera-kernel-outreachy
11:39sumera: oops, please ignore that. wrong window * facepalm *
12:47Bertl: 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:49Bertl: 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:51Bertl: could somebody here give me a short overview and maybe some pointers what to investigate next?
13:43danvet: pinchartl, sure
13:43danvet: I think helpers in general support that already
13:55ajax: 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:55ajax: Bertl: the dri3 protocl generally is documented at https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/dri3proto.txt
13:56ajax: 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:01Bertl: I see, thanks for the explanation!
14:03tzimmermann: danvet, hi! about the vmap discussion: can we leave pin aside and focus on the reservation lock?
14:04Bertl: 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:05danvet: tzimmermann, the rule we want is that you can all vmap if you're either pinned (somehow) or hold dma_resv_lock
14:05danvet: not sure how you can leave the pinning side out here
14:06danvet: also I think i915 grabs dma_resv_lock in its callbacks
14:06danvet: or will, once the locking rework has landed
14:06danvet: so just dma_resv_lock is tricky
14:06danvet: i915 doesn't pin at attach time, so we have to pin in vmap
14:10tzimmermann: 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:10tzimmermann: that's all i'd really need
14:12danvet: yeah the i915 patches to move over to dma_resv haven't landed yet
14:12danvet: so essentially we're just blocking those patches on your work
14:13danvet: so I guess intel team then gets to add the entire dma_buf_vmap_local scaffolding and clean it all up
14:13tzimmermann: davnet, one could rather say generic fbdev benefits the whole drm ecosystem. i915 only benefits i915
14:13tzimmermann: danvet ^
14:14tzimmermann: but i915 doesn't use generic fbdev, so they'd still be good for now
14:15danvet: this isn't just a hack for fbdev generic helpers
14:15danvet: this is the dma_buf interface
14:15danvet: yolo locking design is really not so great imo
14:16tzimmermann: how do you want the dma_buf_vmap_local to look like?
14:16danvet: and I really don't see why we can't do this cleanly, with a new dma_buf_vmap_local
14:16tzimmermann: how do you want the dma_buf_vmap_local to look like?
14:17danvet: dma_resv_assert_held + kerneldoc says you can use the pointer beyond that locking section
14:17danvet: plus also ofc the rule that exporters can't take that lock
14:17danvet: also would mean it's optional
14:18danvet: at that point maybe just do it for gem only
14:19tzimmermann: users of dma_buf_vmap_local would acquire resv before calling into drm_buf_vmap_local() ?
14:19danvet: the trouble with dma-buf is, at least with the dynamic attachment stuff that was the case, that it's kinda broken already
14:19danvet: and adding dma_resv anywhere in existing stuff exposes that
14:19danvet: 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:19danvet: tzimmermann, yup
14:20danvet: essentially if you want to make dma_resv_lock mandatory in some form
14:20danvet: it needs to be pulled out all the way to top most caller
14:20danvet: so with the dynamic dma-buf stuff the caller is always taking the lock for the exporter
14:21tzimmermann: and exporters would provide new dma_buf_op callbacks vmap_local and vunmap_local ?
14:21danvet: for vmap we could probably kludge around something, but it's kinda inconsistent
14:21danvet: tzimmermann, that, or some kind of flag or something
14:22danvet: 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:22danvet: since some pin at attach, others only when needed
14:23danvet: that's why I think caller has to give us the hint which case it is
14:25tzimmermann: 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:25danvet: because for the drivers that don't pin in vmap, attach pins instead
14:25danvet: and atm all importers attach, even if they don't need to
14:29tzimmermann: 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:29tzimmermann: that should avoid the need for pinning (?)
14:40danvet: tzimmermann, yes, vmap_local would completely avoid any pinning
14:41danvet: the attach only comes in for the current vmap, because it provides the pinning in some cases
14:41danvet: 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:41danvet: but just entirely parallel ->vmap_local is quicker to roll out I think
14:42danvet: and it shouldn't put up roadblocks for eventually unifying this in the future
14:43danvet: where we'd only have a single ->vmap callback in ops structs
14:43danvet: and dma_buf_vmap would call ->pin + ->vmap, while dma_buf_vmap_local would only call ->vmap
14:43danvet: and dma_buf_vmap would take dma_resv_lock for current callers, since they don't
14:46Vanfanel: 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:46Vanfanel: That would give me working v3dv on the Pi4
14:47Vanfanel: But witj 2.3.0 release, vulkaninfo fails with: "vulkaninfo.c:3845: failed with VK_ERROR_INITIALIZATION_FAILED"
14:47Vanfanel: Has something changed regarding the buildsystem with 2.3.0?
14:55Vanfanel: Has working v3dv made into 2.3.0 release? Maybe I am wrong on assuming it has
15:10Vanfanel: Oh... it seems v3dv Vulkan does not work on without X11 on 2.3.0, but it does on current git :(
15:10Vanfanel: I hoped 2.3.0 would be the first version with X-less vulkan on the Pi
15:11Vanfanel: I will have to wait I guess :P
15:27MrCooper: Bertl_oO: when that happens, can you kill compiz and Xorg recovers?
15:31Sumera_: 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:38danvet: Sumera_, nothing in run-tests.sh about the magic that's going on?
15:40danvet: Sumera_, also does it fail without forcing vkms?
15:41danvet: 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:48dcbaker[m]: hakzsam: thanks!
15:50Sumera: 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:59danvet: mripard, are you sure your patches create proper hyperlinks on latest upstream?
16:03mripard: danvet: I checked with make htmldocs, but maybe I missed something?
16:03danvet: maybe it's just a difference between kerneldoc and normal sphinx
16:03danvet: but I just spotted one &foo use that didn't hyperlink
16:03danvet: and struct foo does
16:03danvet: I think
16:03danvet: testing right now
16:07danvet: Sumera, for the run-test.sh stuff might also ask ivyl, he's the igt maintainer and iirc wrote that tool
16:07danvet: or perhaps it was Adrinael
16:14Adrinael: Sumera, what's in the clients list with force active? Are they really using vkms?
16:14Adrinael: It's entirely possible that the device filters have broken IGT_FORCE_DRIVER
16:18danvet: Adrinael, yeah on that I guess --dev name:vkms is on my wishlist
16:18danvet: and maybe deprecating IGT_FORCE_DRIVER
16:20ivyl: danvet: sys:/sys/devices/platform/vkms ?
16:20danvet: oh nice
16:20ivyl: that should work IIRC
16:20Adrinael: danvet, wish granted
16:20danvet: Sumera, ^^ this trick should be in docs
16:20danvet: if it works
16:22danvet: it seems to work
16:22danvet: Adrinael, well deprecating IGT_FORCE_DRIVER included?
16:23Adrinael: That one not yet :P
16:23ivyl: if anything is missing or broken patches/issues are welcome
16:35Sumera_: Adrinael: system-logind and kms_flip- yeah I guess they are using vkms...
16:38danvet: seanpaul, [RFC PATCH 0/2] drm: use dynamic_debug <- jump in
16:39danvet: if this isn't outright from you guys
16:39Sumera_: danvet: works with/without IGT_FORCE_DRIVER and run-tests.sh
16:41seanpaul: danvet: doesn't really help us, would still overrun syslog with drm spam
16:41danvet: seanpaul, oh I'm just throwing everything drm dbg related at you on principle :-)
16:42seanpaul: danvet: that's fair :-)
16:55Sumera_: ivyl : tried `sudo IGT_FORCE_DRIVER=sys:/sys/devices/platform/vkms build/tests/kms_cursor_crc
16:55ivyl: Sumera_: this is not how this exactly works, give me a sec
16:56Sumera_: oops, sorry. mo wonder I got a different error.
16:56ivyl: you have to use --device switch on the test: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-test-programs-common-features.html
16:56ivyl: there's also environemnt variable available if you prefer that instead
16:57ivyl: and there's a tool called lsgpu (builds with IGT) that allows you to test the filters out
16:57ivyl: lsgpu --help
16:58ivyl: 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:02ivyl: It may be the time to get that fixed + mention the device selection in the README + deprecate IGT_FORCE_DRIVER
17:03Sumera_: ivyl: oh right, so I pass the location to --device instead?
17:04ivyl: Sumera_: yep, the lsgpu.c has a bit more details in the comments on how this works
17:08MrCooper: danvet: I honestly think all that messing with Linux headers for Windows builds is just delaying the inevitable
17:27Adrinael: Sumera, if you prefer env variables, IGT_DEVICE is the var that takes filter strings
17:50Vanfanel: 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:52Vanfanel: Any idea on why could be MESA falling there? I mean, what does ENOSPC being returned by drmModeSetCrtc()????
17:53Vanfanel: The physical device is accessed from two different places: could that be the cause of the ENOSPC?
17:55vsyrjala: drm.debug=0x1e and see what the kernel says
17:56vsyrjala: should show somehting at least if it's coming from kms side
17:57vsyrjala: and i think it shoud say the fb is too small
17:59Vanfanel: vsyrjala: thanks, let's see :)
17:59MrCooper: kind of ironic for ENOSPC :) "not enough space for this framebuffer, it's too small"
18:00vsyrjala: it's rather 'the fb doens't have enough space for your src viewport'
18:00MrCooper: makes sense
18:02vsyrjala: one of those rare cases where there is a semi-reasonable errno value we can use
18:03vsyrjala: 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:04Vanfanel: 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:05vsyrjala: yes. you can't scan out a 1902x1080 region from a 640x480 fb
18:06Vanfanel: vsyrjala: Ok, now I need to find where have told Vulkan to scan a 1080p image... thanks!
18:07vsyrjala: since it's using legacy kms uapi that would be the current_drm_mode
18:08Vanfanel: vsyrjala: do you mean the current_drm_mode is supposed to be 1920x1080?
18:09vsyrjala: if your fb is 640x480 your need your mode to be <=640x480
18:09vsyrjala: atm it must be using a 1920x1080 mode, which is why it fials
18:12Vanfanel: vsyrjala: there's something I am missing here. According to what you wrote, mode must be <= fb size. Shouldn't be the opposite?
18:13vsyrjala: 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:15Vanfanel: vsyrjala: yes, makes sense now. Thanks!
18:27Sumera__: 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:31anholt: jasuarez: congrats on getting vc4 ci enabled!
18:50Bertl_oO: MrCooper: yes, X recovers when I kill -9 compiz and restarting compiz works fine as well
18:57melissawen: 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:06daniels: jasuarez: ++ awesome
19:19danvet: MrCooper, yeah for amdgpu_drm.h stuff real work needs to be done
19:19danvet: but stand-alone drm_fourcc.h seems reasonable, and other people seem to care too
19:22emersion: yeah, i think stand-alone drm_fourcc.h would be nice too
19:23emersion: however i don't like the suggested solutions
19:23emersion: (rely on users to include the right header before drm_fourcc.h)
20:54anholt: trying to run mesa's unit tests with asan enabled is so sad.
20:56dj-death: anholt: it's just an opportunity to increase your commit count