08:22 dolphin: amdgpu patch fixup seems broken in dim
08:35 dolphin: Removed the fixup as it seems to already exists in the trees.
08:36 dolphin: airlied, sima: ^^ FYI (dropped fixups/drm-next.patch)
09:07 neobrain: When starting Weston from a TTY with EGL_LOG_LEVEL=debug set, does the the EGL debug output get printed in the "--log" target? If not, how do I read it? (asking because stderr output is cut off after 10 lines for me, and I can't find any option to disable this behavior)
09:17 airlied: dolphin: thought i rebuilt successfully, thx for cleaning up
09:21 daniels: neobrain: no, we don’t capture stderr, so you’d need to use shell redirection for that
09:22 neobrain: daniels: hmm are you saying it shouldn't cut off the output after 10 lines? I'm literally just running "weston" without any extra args
09:25 MrCooper: neobrain: it getting cut off may be a kernel fbcon / VT layer quirk, which you can avoid by redirecting stderr to a file with 2>
09:26 neobrain: Ah yes, that seems to be the case. Works with 2>, very good to know!
09:33 soul: I wanna contribute to mesa3d I know opengl and char drivers but I don't know anything about gpu drivers
09:41 pq: neobrain, printing to VT console indeed stop working as soon as graphics more activates, so shell redirect to a file for both stdout and stderr is a good idea. Leaving out --log will get you log output in that file too.
09:41 pq: *graphics mode
10:23 karolherbst: soul: know OpenGL is kinda optional, just pick whatever interests you most and dig into it
10:24 karolherbst: there isn't really a good general "todo" list of things, so people shall usually start workin no whatever they need or find interesting
11:48 luc: Hi, i wonder what would happen if a driver calls drmSyncobjWait() like this drmSyncobjWait(fd, &sync, 1, INT64_MAX, DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL, NULL)?
11:50 dj-death: luc: depends on the state of the syncobj
11:52 dj-death: but pretty much the same as with no flags at all since you only gave a single syncobj
11:52 luc: it seems like the calling process will be set TASK_INTERRUPTIBLE then get waken up immediately assuming the fence is signaled, won't it?
11:54 dj-death: if nobody put a fence in the syncobj prior to the wait, it'll return immediately yeah
11:55 dj-death: if you want to wait for somebody to put a fence in there you have to add DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT
12:14 luc: dj-death: assuming a fence (only one) had been put in the syncobj and also got signaled, then the calling process will go through an immediate task state changeover ( sleep -> woken) ?
13:41 jani: tzimmermann: mlankhorst: drm-tip build still broken https://paste.debian.net/1283485/
13:42 jani: tzimmermann: maybe a broken conflict resolution after 0adec22702d4 ("drm: Remove struct drm_driver.gem_prime_mmap")
13:52 tzimmermann: jani, my fault
13:54 jani: tzimmermann: I'm not looking for people to blame, I'm looking for people to fix it ;)
13:55 tzimmermann:disappears
13:55 tzimmermann: just kidding, i'm on it
13:55 jani: tzimmermann: thanks :)
14:34 mlankhorst: hm weird
14:34 mlankhorst: diff bug I suppose
14:48 tzimmermann: drm-misc-next should work again
18:09 karolherbst: what's the coolest app these day to trace OpenGL applications?
18:10 Kayden: still apitrace
18:57 benjaminl: I generally prefer renderdoc to apitrace, but both are good
19:17 zmike: definitely apitrace
19:17 zmike: you can renderdoc capture off apitrace but you can't apitrace a renderdoc capture
19:19 bl4ckb0ne: both lack wayland support but +1 for apitrace
19:26 linkmauve: I’ve been using apitrace on Wayland for like a decade, what is your issue?
19:28 bl4ckb0ne: stilp depending on xwayland
19:28 bl4ckb0ne: otherwise no issue
19:31 bl4ckb0ne: same goes for renderdoc
19:36 linkmauve: It doesn’t, it depends on whichever waffle platform you built, if you build it for Wayland it will use that, if you build it with gbm it will use that.
19:36 linkmauve: That’s for retracing, while for tracing it will use whichever API the client it is tracing is using.
20:44 DemiMarieObenour[m]: Is it worth reporting bugs in nouveau or should I just tell users with nouveau problems to use a working version?
20:45 kisak: you can't ponder and troubleshoot quirks that are never reported.
21:40 karolherbst: uhhh.. iris pipelines are taking forever again
21:40 karolherbst: or just don't work at all
21:57 daniels: karolherbst: link please
21:57 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/913163
21:57 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/913247
21:58 karolherbst: in the first one I stopped the iris jobs, in the second one there are still active I think
21:59 karolherbst: ohh seems like they got resubmitted automatically as well? pain.... dunno
21:59 karolherbst: let's see...
21:59 karolherbst: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44021504
21:59 karolherbst: there is a timedout job
21:59 karolherbst: hope that's enough info
22:01 daniels: karolherbst: perfect, thankyou!
22:02 daniels: yeah, they all walked off a cliff - should be back shortly
22:08 karolherbst: uhhh...
22:09 karolherbst: okay :) hopefull they work now
22:18 daniels: yeah, I see quite a lot of screaming in our internal device-availability alert channel now I look at it