00:37 mareko: Kayden: it's easy to disable multidraws by skipping the conditional in tc_batch_execute, it would even be possible to add custom tc_batch_execute for each driver, but if we allow that, it can turn into a big mess over time
00:50 imirkin: mareko: what is PIPE_CAP_NO_CLIP_ON_COPY_TEX? i read your commit and tried to understand how it's used in teximage.c, but i don't quite get it
00:51 mareko: imirkin: it skips _mesa_clip_copytexsubimage
00:51 imirkin: right, but like ... why is that legal, and why is it a per-driver-backend decision?
00:53 mareko: I don't know. I think it's a driver decision because some drivers might not work with it. I don't think it's illegal.
00:54 imirkin: what's the end effect, as the driver perceives it?
00:54 imirkin: resource_copy_region gets "larger" parameters?
00:56 mareko: imirkin: mtypes.h explains it
00:56 imirkin: ok
00:57 imirkin: yeah. i guess i just don't get it.
00:57 imirkin: no worries.
01:00 mareko: imirkin: if src bounds are partially outside the current framebuffer, it's better to fill the remaining dst texture area with zeros than keep it random
01:02 mareko: idr: our draw_vbo overhead decreased by 13% with the C++ template when draw merging was disabled
01:03 idr: Wow.
01:03 idr: mareko: I thought about trying it using C++ templates at the time, but... it wasn't a fight that I wanted to deal with.
01:04 mareko: actually it's total performance, not just draw_vbo, so the improvement was even better
01:04 idr: In i965, I was trying to condition on Gen and API (core vs compatibility vs ES).
01:05 idr: Each API had different sets of things that didn't have to be checked, so those conditions could be eliminated from the hot path.
01:05 mareko: With GALLIUM_THREAD=0 to disable draw merging. piglit/drawoverhead:
01:05 mareko: Before: DrawElements ( 1 VBO| 0 UBO| 0 ) w/ no state change, 8736 After: DrawElements ( 1 VBO| 0 UBO| 0 ) w/ no state change, 10059
01:05 mareko: It generates unique si_draw_vbo variants for these parameters: GFX version, has_tess, has_GS, NGG, prim_discard_cs_allowed.
01:05 idr: Interesting.
01:07 mareko: 8736 -> 10059 (thousands of draws), with tc and draw merging, the number is ~25000
01:09 jenatali: Nice
01:09 mareko: so 25 million draws per second right now
01:12 imirkin: anholt: your r-b still hold with the updated changes in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8432 ?
02:58 mareko: one viewperf subtest results:
02:58 mareko: no multithreading: 94 FPS
02:58 mareko: only glthread: 120 FPS
02:58 mareko: only tc: 148 FPS
02:58 mareko: both glthread and tc: 243 FPS
03:33 alyssa: mareko: 25 million draws? wow :o
04:16 mareko: alyssa: it's an extreme case where 256 separate draws become a multidraw
06:59 airlied: aynone from v3d land in here got any idea if CL is a possibility
07:05 HdkR: airlied: It's theoretically possible
07:06 HdkR: It has enough compute bits that you could have a very slow CL machine
07:33 imirkin: how does one make cmake use the python version which is the "python" or "python3" binary?
07:33 imirkin: e.g. i have a python3.9 but it doesn't have numpy
07:33 imirkin: i have a python3.8 which is the "main" python and has numpy
07:33 imirkin: but piglit doesn't detect it. i just removed 3.9 from CMakeLists.txt, but that's obviously not a perfect solution...
07:38 airlied: -DPYTHON_EXECUTABLE? though not sure about that
07:39 imirkin: i'm guessing the problem comes up due to setting Python_ADDITIONAL_VERSIONS in the first place
08:19 austriancoder: maybe somebody has a hint for me how to debug this issue further.. I have a coredump of a qtwebengine based browser and here is the gdb bt: https://hastebin.com/sobiwurido.shell .. after st_draw_vbo(...) the browser is dead. Btw. this happens after 3 months of runtime
08:21 imirkin: austriancoder: do you know what's on st_draw.c:211 of that mesa version?
08:23 imirkin: austriancoder: also does it consistently happen after 3 months?
08:23 austriancoder: imirkin: yes - https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_draw.c?h=mesa-20.1.2#n211
08:24 austriancoder: imirkin: that was the first time it crashed after an update of the whole stack
08:25 imirkin: welp, good luck =]
08:25 imirkin: question i'd ask is why is that signal handler in the backtrace
08:25 imirkin: is it because it was used to interrupt the program to get the trace in the first place?
08:25 imirkin: was it stuck in an infinite loop somewhere?
08:28 imirkin: airlied: you might be the only person who can review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8463 ... if you get a chance
08:29 HdkR: austriancoder: Which signal? Might be worth going to frame 6 and seeing if the instruction executing can cause that signal
08:33 HdkR: That line in the source is doing both a load and a store to memory, can see which edge it is failing on if it is that
08:33 austriancoder: imirkin: the browser has some kind of supervise mode where there is a separate process to check if the real browser process is running - if not the supervisor restarts the real browser
08:34 HdkR: oh, info is local. so it has to be load memory failure if the signal is sigsegv
08:37 HdkR: ib->obj garbage? :)
08:37 austriancoder: HdkR: https://hastebin.com/bazotuyuti.css
08:38 HdkR: info reg for r8?
08:39 austriancoder: r8 0x3c0af818 1007351832
08:39 HdkR: It at least isn't some terrible location
08:40 HdkR: if you do `info thread` you can get the tid. then check /proc/<tid>/maps to see if that is even near a valid location
08:41 HdkR: Not sure how to check mapping ranges in gdb
08:43 austriancoder: HdkR: the process is dead already .. so I have no way to check with /proc/<tid>
08:43 HdkR: `info files` I guess might give the same ranges in gdb according to google
08:43 austriancoder: signal was 11 .. SIGSEGV
08:44 HdkR: Oh? gdb keeps the thread alive locally when it is debugging
08:44 HdkR: Could be different setup I guess
08:44 austriancoder: HdkR: i only got a coredump
08:44 HdkR: blah
08:44 HdkR: info files maybe then?
08:45 HdkR: Not sure if that works
08:45 HdkR: But sounds like ib->obj isn't nullptr but is garbage still
08:55 HdkR: As for why that happens...eh? I can't even see where those yet allocated. Ran out of memory?
09:00 austriancoder: HdkR: https://hastebin.com/tihuperela.yaml
09:00 austriancoder: out of memory.. could be .. hmm ..
09:02 HdkR: Looks like that region it tried accessing is nowhere near mapped
09:03 HdkR: looks like rough range in that mapping would be just under 512MB of ram? Would need a script to parse and add it all though
09:04 HdkR: Just did top vram range - bottom-ish vram range
09:06 HdkR: ARM board with only 512MB of RAM and no swap? :)
09:07 HdkR: or maybe GPU facing memory can't get swapped so just dies...?
09:07 austriancoder: no swap is correct
09:08 austriancoder: 1 GB ram
09:09 HdkR: Guess it could still be an memory leak issue just because of the 3 months of uptime
09:12 HdkR: Hard to tell with the information available sadly :(
09:13 HdkR: Might also be one of those quirks where a buffer is reused but that ptr isn't clear to nullptr
09:24 HdkR: Record memory usage and map. Let it run for a day, record memory usage and map. See if change occured? :)
09:25 HdkR: Repeat, see if it only goes up?
09:37 HdkR: alt-alt failure mode, questionable asan cleanliness could mean random overwrite?
10:10 karolherbst: anybody ever used the thread sanitizer and got _useful_ stacks out of it?
10:14 HdkR: karolherbst: tsan specific to mesa, or tsan in general?
10:14 karolherbst: didn't try with other things
10:14 karolherbst: permanently seeing things like "<null> <null> (nouveau_dri.so+0xb5d300)"
10:15 HdkR: I've had really good success with llvm tsan in applications
10:15 karolherbst: yeah.. maybe I see that because I only compiled mesa with tsan support
10:17 HdkR: Haven't tested a partial tsan compilation i nthe library rather than the app side
10:20 HdkR: One probably I /have/ had is if llvm can't find its symbolizer
10:20 HdkR: Which there is a environment variable to work around that
10:29 karolherbst: right
10:29 karolherbst: oh well
10:29 karolherbst: reocmpiling the CTS with tsan then
10:38 karolherbst: HdkR: mhhh... isn't better
10:43 HdkR: Hm. x86 host + clang?
10:44 karolherbst: tried both gcc and clang, no difference really
10:47 HdkR: Does mesa have a tsan enable option?
10:48 karolherbst: yes
10:48 karolherbst: I am not even sure what the issue is, but tsan is really really bad in resolving the symbols and everything
10:51 HdkR: ah, it's a meson option
10:52 HdkR: I'm curious so I'm giving it a compile
11:12 karolherbst: HdkR: now I built evereything with clang and the proper compile options (I think I missed some) and now it works :/
11:12 karolherbst: well.. partly
11:13 HdkR: __tsan_init symbol is missing for me. Which is a painful error
11:29 karolherbst: mhh.. seems like tsan just skips stuff not compiled with tsan
11:30 karolherbst: HdkR: like, how does this make any sense? https://gist.github.com/karolherbst/931827ee5d68e76ff24a802434025419
11:30 pq: sounds better than msan, which just aborts or such on pieces not compiled with msan :-)
11:30 karolherbst: ehh...
11:30 karolherbst: not everything can be as solid as asan I guess
11:31 pq: which I guess is why asan is much more popular, I'd suppose
11:31 karolherbst: yeah
11:31 HdkR: That looks sane
11:31 HdkR: Surprised there isn't more information though
11:32 karolherbst: HdkR: it's wrong though
11:32 karolherbst: why would the CTS call into an internal mesa function directly?
11:32 karolherbst: why is pthread_barrier_destroy inside glcts?
11:33 HdkR: Probably just need `-fno-omit-frame-pointer` to get a better backtrace?
11:33 karolherbst: I have it set for mesa, but maybe I should add it to the cts as well
11:35 karolherbst: but it's compiled with O0 anyway
11:46 HdkR: Ah there we go, just had to run an app built with tsan as well
11:46 HdkR: how silly
11:47 karolherbst: yeah...
11:47 karolherbst: anyway, most of the issues are caused by the shader cache anyway :D disabling it removes most of the noise
11:47 HdkR: Rebuild that with symbols quick...
11:47 karolherbst: but still
11:47 karolherbst: the reports are quite useless
11:47 karolherbst: https://gist.github.com/karolherbst/f4a2e7ac651a5d0aa5cb3a44751aadd6
11:48 karolherbst: like this one
11:48 karolherbst: I mean.. sure... but still
11:49 karolherbst: mhhh.. it's an indirect call in glcts
11:49 HdkR: karolherbst: http://pastie.org/p/2huTwzQvObbUiRIS7KRwuN
11:49 karolherbst: yeah, that looks fine
11:49 karolherbst: why can't I get something like this :D
11:50 HdkR: This was with llvm/clang 10 for both mesa and my host app
11:50 karolherbst: clang 11 here
11:50 HdkR: on x86-64, debugoptimized on mesa, RelWithDebInfo on my cmake app
11:50 HdkR: and -fno-omit-frame-pointer on my host app at least
11:50 karolherbst: -O0 all the way here
11:51 HdkR: hm
11:51 karolherbst: well, with -g3 and -ggdb3
11:51 HdkR: export LLVM_SYMBOLIZER=`which llvm-symbolizer-10` ?
11:51 HdkR: Oh no, you have symbols
11:53 karolherbst: HdkR: fun fact is, that it's all indirect calls inside glcts
11:55 MrCooper: karolherbst: maybe try without -ggdb3? I'm using that as well and noticed valgrind being unable to resolve symbols as well, haven't tried without yet though
11:55 karolherbst: mhh, let's see
11:59 karolherbst: mhhh, nope
12:27 Vanfanel: emersion: I am trying to implement async flips on the SDL2 KMSDRM backend. Is DRM_MODE_PAGE_FLIP_ASYNC supposed to be working on AMDGPU by now? I saw a patch from 2016 that seems to indicate that it should: https://patchwork.kernel.org/project/dri-devel/patch/1462541524-1135-1-git-send-email-alexander.deucher@amd.com/
12:27 emersion: i don't know, i don't really care about async page-flips
12:27 emersion: sorry
12:28 Vanfanel: emersion: do you know who could I ask, please?
12:28 emersion: you can ask http://localhost:1323/capabilities
12:28 emersion: err
12:28 emersion: you can ask https://drmdb.emersion.fr/capabilities
12:29 Vanfanel: emersion: thanks :)
12:29 Vanfanel: emersion: oh! In general... do async flips any special CAPS to be enabled?
12:30 emersion: dunno
12:30 Vanfanel: ok, ok
12:30 emersion: i'd guess DRM_CAP_ASYNC_PAGE_FLIP would be enough
12:34 Vanfanel: emersion: I know of drmSetClientCap() to set caps, but.. is there a function to test them?
12:34 emersion: drmGetCap
12:36 Vanfanel: oh, nice, thanks! :)
12:50 danvet: tzimmermann, mlankhorst ack for adding zackr and sroland from vmwgfx to drm-misc?
12:50 danvet: mripard already acked yesterday evening
12:51 mlankhorst: danvet: ack for both
13:02 Vanfanel: ok, AMDGPU supports the ASYNC_PAGE_FLIP cap. Still, even if I pass the DRM_MODE_PAGE_FLIP_ASYNC flag to drmModePageFlip(), subsequent drmModePageFlip() calls return EBUSY if I have not blocked anywhere. What am I missing, please? Does somebody know?
13:04 vsyrjala: just wait for the page flip event before trying to issue another page flip
13:05 pq: Vanfanel, you're still passing NONBLOCK flag as well, right? So you need to wait for the flip event.
13:05 pq: ...I'd guess
13:05 vsyrjala: legacy pageflip is always nonblocking
13:06 pq: d'oh
13:12 tzimmermann: danvet, acked
13:13 danvet: daniels, ^^ can you pls wrangle ldap?
13:13 danvet: we got all the acks
13:13 danvet: add zack&sroland to drm-misc I mean
13:15 Vanfanel: pq: There is no NONBLOCK flag in drmModePageFlip() that I can see, indeed, so it must be always non-blocking.
13:16 Vanfanel: vsyrjala: so I must ALWAYS wait for the generated event, right? even with DRM_MODE_PAGE_FLIP_ASYNC flag to drmModePageFlip(), right?
13:16 danvet: yes
13:16 danvet: async just controls how the flip is done in the hw
13:16 danvet: not how we track it and when you can stuff in the next one
13:16 Vanfanel: danvet: I understand.
13:18 daniels: danvet: done
13:19 danvet: zackr, ^^ fyi
13:19 danvet: daniels, thx
13:19 daniels: zackr: you & sroland are in drm-misc now, will take about 10min to take effect but I imagine you won't be awake before then anyway
13:19 daniels: danvet: np :)
13:26 Vanfanel: Well, I am passing the DRM_MODE_PAGE_FLIP_ASYNC flag, I am also waiting for the event of the previous issued flip, and still drmModePageFlip() is returning EBUSY if I don't block in EGL...
13:26 Vanfanel: Here I pass the ASYNC flag: https://github.com/vanfanel/SDL/blob/master/src/video/kmsdrm/SDL_kmsdrmopengles.c#L172
13:26 Vanfanel: And before that, I have waited for the last issued flip here:
13:26 Vanfanel: https://github.com/vanfanel/SDL/blob/a6ffdfc673c2dc15db5d88b5bfdc01d58f453511/src/video/kmsdrm/SDL_kmsdrmopengles.c#L105
13:27 danvet: Vanfanel, hm might be a bug in amdgpu then, not sure
13:27 danvet: ping hwentlan
13:27 danvet: waiting for the event should be enough to avoid the EBUSY
13:28 pq: Vanfanel, what's the timeout in your wait?
13:28 Vanfanel: danvet: That's my understanding too. I tend to humbly believe it's my code, not a bug on the driver, but... I hope hwentlan can lend a hand :)
13:29 Vanfanel: pq: oh, that could be the problem! I am passing a timeout of 0!
13:30 Vanfanel: pq: what should be the timeout for waiting for ASYNC flips?
13:30 Vanfanel: -1?
13:31 pq: depends on what you do...
13:31 danvet: yeah if your wait doesn't wait, then you'll keep getting ebusy
13:31 pq: Vanfanel, reading your wait code though, looks like timeout=0 would only lead to a busyloop?
13:32 pq: so still wait, just inefficiently
13:33 pq: *shrug*
13:33 Vanfanel: pq: do you mean my KMSDRM_WaitPageFlip() in https://github.com/vanfanel/SDL/blob/a6ffdfc673c2dc15db5d88b5bfdc01d58f453511/src/video/kmsdrm/SDL_kmsdrmvideo.c#L342 is inneficient because of the "while" loop?
13:34 pq: tiemout=0 means poll() returns immediately, so you busyloop until something happens, right?
13:36 vsyrjala: Vanfanel: looks like you're not setting waiting_for_flip, so the wait does nothing
13:36 pq: heh, yeah, it's conditional to swapinterval
13:43 Vanfanel: vsyrjala: ohh stupid me! I wasn't setting that... I am setting waiting_for_flip unconditionally now, and I have no more EBUSY returns!! :D
13:43 Vanfanel: KMSDRM_WaitPageFlip() is making it's wait now
13:45 Vanfanel: pq: so, if poll() in https://github.com/vanfanel/SDL/blob/6b4a4b4eec9285308ae1b0c2fbf2e23b4e9ebd2d/src/video/kmsdrm/SDL_kmsdrmvideo.c#L356 returns immediately if timeout=0, so I should return immediately in that case?
13:45 Vanfanel: pq: or... can that function be refactored to avoid using the wait() loop somehow?
13:46 pq: Vanfanel, the choice of timeout is up to you. When you hit the timeout, do you have anything sensible to do other than wait again?
13:50 Vanfanel: pq: well, if poll() returned < 0, no, nothing else to do, there was an error. BUT if poll() returns 0, it means there was a real event happening, and if (events & POLLIN), I deduce it's the pageflip I was waiting for.
13:50 Vanfanel: pq: there's something here I have forgotten or missing at all...
13:51 Vanfanel: pq: oh, yes! I am using the while() loop because there may be other events that don't fit in (events & POLLIN)
13:52 pq: poll() returns 0 on timeout, positive number on actual events to serve
13:52 pq: and we are talking only about the timeout case here
13:52 pq: if there is no error at all, can you return from the wait function even if the wait has not completed yet?
13:53 pq: it looks like you can't
13:53 pq: so the timeout is actually irrelevant, and could be just infinite always
13:53 Vanfanel: pq: I should not return without the event to happen, of course..
13:55 pq: yeah, but that also means that if something is broken and the event never comes, you'll be stuck forever. Which can be the right thing to do, too, depending on how resilient you want your lib to be.
13:56 pq: oh wait, it does look like you can return without error and without receiving the event
13:56 pq: the /* Timed out ...*/ path does exactly that.
13:57 pq: so, I dunno, whatever your users expect...
14:00 Vanfanel: pq: hmmm... always using -1 as timeout for poll() will get me waiting for flip forever, stuck in KMSDRM_WaitForFlip(). But how possible is that a requested pageflip never completes? I mean, if everything is right when I issue the pageflip (CRTC configured OK, etc), it shouldn't happen easily
14:00 Vanfanel: pq: My users would be the SDL2 users that don't use X11, so I don't know what's better :D
14:02 Vanfanel: pq: My undetstanding is that returning when poll() returns an error is resilient enough, isn't it?
14:03 pq: Can you do anything if the flip event never comes? Presumably you can't flip again anyway until it does.
14:03 pq: quit, maybe?
14:04 pq: never getting the event should be an indication of broken software, either yours, the app, or kernel
14:05 pq: maybe quit after 10 seconds or so, so the user should at least get his machine back?
14:06 Vanfanel: pq: that would mean to put a poll() timeout of 10 seconds, right? And it poll() times out, quit.
14:06 pq: yeah
14:07 Vanfanel: pq: I mean, if poll() times out, KMSDRM_WaitPageFlip() would return error and I would quit
14:07 pq: right
14:08 pq: but if your while loop restarts the poll, it might still never quit if unrelated events keep coming
14:12 Vanfanel: pq: but if I quit, there's no chance the while loop is entered again... right?
14:13 pq: I'm talking about the case when the poll() never times out, but also the event you are waiting for never comes
14:14 pq: this can happen if the DRM fd is delivering e.g. vblank events at a steady rate for whatever bad reason
14:18 pendingchaos: can someone who isn't a RADV dev ack this nir_opt_loop_unroll MR before the branch point: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6538 ?
14:36 Vanfanel: pq: you are right. But it seems I am return if the event is an error: https://github.com/vanfanel/SDL/blob/aadaf0e994f425d4a0c8e1d1aa67adea06b81d52/src/video/kmsdrm/SDL_kmsdrmvideo.c#L365
14:37 Vanfanel: pq: and I am also returning if there is a POLLING event (there is data to read) but it's not the one we are waiting for: https://github.com/vanfanel/SDL/blob/aadaf0e994f425d4a0c8e1d1aa67adea06b81d52/src/video/kmsdrm/SDL_kmsdrmvideo.c#L378
14:37 Vanfanel: pq: so doesn't that cover all possible cases?
15:10 pq: Vanfanel, vblank events are proper events, but not the event you are waiting for. So no error, no timeout, if those are flowing for some reason.
15:11 pq: Vanfanel, vblank events hit the POLLIN path, but don't call your pageflip handler.
15:12 Vanfanel: pq: I see... And there's no way to distingish these vblank events?
15:13 pq: well, they would call the vblank handler if you set one
15:13 pq: but that's irrelevant
15:13 pq: the point is, the drm fd might have some data ready for reading, but not the thing you're waiting for
15:13 danvet: you also pass some opaque value along that you get back from the kernel
15:14 danvet: so you can tell them apart
15:14 pq: the solution to that is to *reduce* the timeout value every time you call poll() by the amount you have waited.
15:14 pq: ...waited without getting your event
15:14 danvet: also why can't you use the libdrm code that handles this?
15:15 pq: danvet, hm? He does call libdrm.
15:15 danvet: oh I guess I got confused in the discussion then
15:16 Vanfanel: pq: so the idea is to be in the "while" just a given sum of time that decreases with each poll() wait, right?
15:16 pq: ...I think he calls libdrm through KMSDRM_drmHandleEvent() or at least I hope so, but that's not the culprit here :-)
15:17 pq: Vanfanel, yeah. Essentially you have an event loop, and you might be getting arbitrary events so the loop may keep spinning instead of timing out, while you might never get the one event you are waiting for.
15:18 pq: Vanfanel, we're talking about pretty unlikely failure cases here though, btw. so I'm not sure how much effort you want to spend.
15:19 pq: if the user can quit by just hitting Ctrl+c or so, then maybe that's enough?
15:20 Vanfanel: pq: well, no, the user can't just do that in SDL2 without X :D
15:23 pq: Vanfanel, so to clarify, if the fd delivers an event-you-do-not-care-about every second, then the poll() with 10 second timeout will never timeout (never error out). Instead it tells you you have one fd ready to read with data every second, yet not the event you are waiting for.
15:25 Vanfanel: pq: yes, even if I am passing an event here: https://github.com/vanfanel/SDL/blob/aadaf0e994f425d4a0c8e1d1aa67adea06b81d52/src/video/kmsdrm/SDL_kmsdrmvideo.c#L375, even then, if the event is not a pageflip then the while() exit condition is never set, and I don't get out of the while(). Is that what you mean?
15:25 pq: there is a libdrm function (drmWaitVBlank?) that one can use to subscribe to vblank event IIRC, but I don't recall if it's always one-shot - in case you want to test the bad case :-)
15:26 pq: Vanfanel, yes.
15:28 Vanfanel: pq: what about I just set waiting_for_flip condition on every POLLIN? No drmHandleEvent() call. Then, those "phantom" events would cause an EBUSY instead of an infinite loop. Maybe it's an absurd idea?
15:29 pq: didn't you want to avoid EBUSY?
15:30 pq: but if you are sure nothing else than pageflip events should be coming, then I guess...
15:31 Vanfanel: pq: well, between EBUSY and infinite loops...
15:32 pq: Vanfanel, tbh, I'd recommend a much more strict approach: use the user data argument to verify that even the pageflip event is the right one.
15:32 pq: and do the timeout properly, which requires a bit more code
15:33 pq: I'm a bit paranoid like that
15:33 Vanfanel: pq: and if it's not? Keep on the while as now, just with the added security timer decreasing?
15:34 pq: yeah
15:35 imirkin: any objections to deleting the branch "4088-timespec_get-used-unconditionally-build-fails-when-targeting-macos-10-14-or-earlier" in the main mesa tree?
15:35 imirkin: it's messing up the cgit view
15:35 imirkin: and it shouldn't have been there in the first place
15:35 Vanfanel: pq: so you mean that every pageflip should have an unique ID on the userdata arguiment, right?
15:37 Vanfanel: pq: also, what timeout should I pass to poll()? My guess is, 2 seconds for poll() and a total 10 seconds on the while.
15:37 pq: Vanfanel, I'd do that, but... I'm me. ;-)
15:38 pq: Vanfanel, there's no reason to pass a smaller timeout to poll than your total timeout.
15:38 Vanfanel: pq: ah, I see...
15:39 pq: Vanfanel, or putting it other way, if you want to be exact: timeout=10 seconds; poll(timeout); timeout -= elapsed time;
15:39 pq: err, forgot the while-loop around it
15:39 Vanfanel: pq: yes, but I get the idea
15:39 pq: right :-)
15:39 Vanfanel: pq: what function can you recommend for time measurement at this level?
15:40 kisak: imirkin: maybe give jeremyhu a chance to respond to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8459#note_763024 before taking action?
15:40 pq: can you rely on clock_gettime? gettimeofday()? whatever really, it doesn't need to be accurate.
15:40 imirkin: kisak: oh, i thought i saw that it was merged
15:40 pq: Vanfanel, I gotta go, have fun :-)
15:41 imirkin: but i think it started out with just 'master' on it when i had seen it
15:42 Vanfanel: pq: thanks a lot for your help! Have a nice day!
16:13 zackr: danvet, daniels: thank you both!
16:14 zackr: daniels: btw, now that i do have two little kids i'm up by 8 everyday. "waffles and hide&seek" > work
16:14 zackr: so i don't start working until a lot later
17:47 dcbaker: PSA for mesa people: I just branched for 21.0, so some marge jobs might fail due to pushing the VERSION bump
17:55 alyssa: Happy branch point~
17:56 daniels: zackr: heh :)
18:04 MrCooper: alyssa: heh, even works for the infamous Stevie Wonder song
18:04 alyssa: MrCooper: ?
18:04 MrCooper: "Happy branch point" instead of "Happy Birthday"
18:05 alyssa: oh...
18:07 alyssa: --By some small miracle it looks like all the MRs we had for the branch point did in fact make it through. A happy branch point indeed :>
18:07 alyssa: (We being Panfrostians anyway)
18:17 ccr: "Panfrostians" sounds like some alien race from a distant star system :P
18:24 alyssa: ccr: ..and?
18:24 alyssa: ^_^
18:24 ccr: :)
18:24 ccr:, for one, welcomes the new alien overlords.
18:26 alyssa: We are benevolent.
18:28 ccr: hooray!
18:29 alyssa: So I'm the extra button on a coat in case another one comes loose?
18:34 Kayden: Does anything use swtnl other than i915c?
18:34 imirkin: Kayden: nv04
18:34 Kayden: swrast did, but thats' gone now
18:34 Kayden: ah
18:35 imirkin: with *billions* of users...
18:35 ccr: :D
18:35 imirkin: actually i think all of nouveau_vieux uses some parts of it, but riva tnt/tnt2 had 0 hwtnl
18:35 Kayden: okay. was just wondering if dropping i915c for i915g would let us drop all of tnl too
18:36 imirkin: even nv30/nv40 fall back on swtnl paths (in gallivm for those)
18:42 sravn: mlankhorst: I do not see drm-misc-next in -next?? Looked for 9b028f48e72d31189819eb9989fbfef905d97402 which is not in -next at the moment. Anything missing to be pushed?
18:53 dv_: I wanna try mesa 21, and figured that there may be a good PPA for ubuntu with a git build of mesa
18:53 dv_: however, there are multiple PPAs like that, so I wonder if you can recommend any
18:59 kisak: dv_: oibaf's PPA is the go-to for mesa-git
19:02 sravn: danvet, airlied - are there something missing since drm-misc-next is not in linux-next?
19:07 dv_: kisak, thx
19:07 dv_: and since mesa 21 rc1 should be released today, I suppose it won't be too unstable
19:09 kisak: that's not a reliable assumption. gremlins can appear at any time when using a randomly picked commit of mesa. Only time and good feedback increases stability
19:11 dv_: alright.. worst case, I can still rollback
19:12 vsyrjala: Kayden: does anyone actually use i915g?
19:13 vsyrjala: i also thought i915g doesn't even support gen2
19:13 vsyrjala: dunno, never used it
19:17 alyssa: vsyrjala: Apparently
19:17 Kayden: I don't think it's been used much outside chromeOS, no.
19:17 Kayden: I don't think (most? any?) distros ship it
19:18 alyssa: ChromeOS has i915'able devices?
19:18 Kayden: the original ones :)
19:18 ajax: pineview, right?
19:18 Kayden: pineview.
19:18 dcbaker: yup
19:19 emersion: i got some but reports about the mesa i915 driver recently (not i965)
19:19 emersion: what is this c/g/… thing?
19:19 ajax: classic/gallium
19:20 ajax: src/mesa/drivers/dri/i915 versus src/gallium/drivers/i915
19:20 emersion: oh, i see
19:20 dv_: and when amd releases a new gpu series like the rx 6000, how long does it typically take until support lands into mesa? and, I suppose kernel modules rarely have to be changed, since the vast majority of changes happen in the command stream?
19:20 emersion: so i915g even predates i915c
19:21 dv_: i mean, does amd deliver mesa patches starting right from day 1 after release?
19:21 ajax: emersion: the reverse, the classic driver is older. when it was written gallium didn't exist
19:22 emersion: hm. and i965 is also classic?
19:22 ajax: correct
19:22 emersion: so i915c → i915g → i965 (classic) → iris (gallium) is the full picture?
19:23 alyssa: throw anv+zink in there somewhere ;)
19:23 emersion: lol
19:24 airlied: and crocus :-P
19:24 FLHerne: dv_: Mesa had patches for RX6000 months before release https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5383
19:24 ajax: i'm not sure what relationship → means there. predates? i don't remember whether the gen4 driver or gallium merged first.
19:25 dcbaker: I'm pretty sure i965c predates i965g
19:25 dv_: wow
19:25 FLHerne: dv_: There are quite large kernel changes, new video encoding/display blocks, power management, general register stuff
19:25 dcbaker: IIRC there was i965g and ilo which were two separate things too
19:26 dv_: hm. I was curious about getting a mid-range rx 6000 once it is released and try out some hw raytracing with it through mesa/vulkan
19:26 FLHerne: dv_: (207 patches for the initial kernel code drop! https://lists.freedesktop.org/archives/amd-gfx/2020-June/049968.html)
19:26 dv_: but this sounds like I will also need a newer kernel
19:26 FLHerne: Ah, what Mesa doesn't have yet is RT support
19:26 dv_: might as well upgrade ubuntu as a whole then
19:27 dv_: but I thought even power management stuff is done via DRI these days and the kernel modules are barely more than basic memory management entities that enable the DRI access
19:28 bnieuwenhuizen: no, kernel does display+powermanagement+memory management + provides the interface for mesa to submit commands to the GPU
19:29 dv_: right - forgot about kms as well
19:29 bnieuwenhuizen: as well as basic stuff like firmware loading
20:05 emersion: how should i go about investigating a nouveau nv50 INVALID_STATE error?
20:09 imirkin: emersion: it should print a bunch of stuff
20:09 imirkin: and maybe #nouveau is more appropriate
20:10 imirkin: (i feel like i already annoy this channel enough with useless nvidia-specific things...)
20:17 emersion: oh right
20:19 dcbaker: anholt, MrCooper: not sure if you care that much, but meson 0.55.0 will generate junit from meson test results, in case you wanted to wire that up in gitlab (not sure if you care enough to get meson 0.55.x in the images). the `meson test` patches made me think of it
22:56 zmike: maybe a little offtopic but does anyone know of a good laptop dock that can handle 2 connected monitors, at least 1 of which is 4k?
22:57 zmike: I've got this caldigit one now and it randomly disconnects about a dozen times a day and kills my session
22:59 imirkin: zmike: i have nothing to add, but you might mention how you plan on connecting this dock to your laptop
22:59 zmike: thunderbolt I guess
23:21 Lyude: anarsoul: poke, you around?
23:21 anarsoul: yep
23:22 Lyude: anarsoul: if you have a moment and are running those backlight patches, could you reboot your laptop like (this is a lot, sorry D:), 10-15 times and see if backlight breaks at any point?
23:22 anarsoul: sure
23:22 anarsoul: why? :)
23:23 Lyude: no idea how I didn't see this before, but I noticed one of my systems seems to have a delay between when we write the source OUI and when it takes affect and starts exposing the intel hdr backlight controls over dpcd
23:23 Lyude: which means it doesn't always see the hdr backlight support
23:23 Lyude: i'm probably still going to push the patches today because in that scenario, nothing really regresses, but yeah :\
23:23 Lyude: well, tommorrow after they pass intel-ci and i poke the drm-misc folks
23:24 Lyude: j4ni: btw ^
23:24 Lyude: good news is it does seem to always eventually work, it's just there's some kind of delay we might need to be wary of apparently
23:25 anarsoul: Lyude: I've been using your patchset for quite a while and unless it's introduced in v5 I haven't actually had any issues
23:26 Lyude: alright-that's good to know
23:26 Lyude: i'm going to go ahead with this then, and I'll look later to see if I can find a way to fix this. maybe we can fix it by doing something silly like reading back the OUI before moving forward
23:27 Lyude: OUIs with DP were a mistake
23:28 karolherbst: Lyude: why? :D
23:28 Lyude: karolherbst: shit like this :P
23:29 karolherbst: oh well :D
23:29 karolherbst: not everything can be simple
23:33 imirkin: by that measure, DP was a mistake
23:34 Lyude: counter point: hdmi
23:34 imirkin: i.e. an example of something that Just Works (tm)?
23:34 imirkin: although the HDMI 2.0 stuff is a *tad* janky, but ... what are you gonna do
23:37 anarsoul: Lyude: 10 reboots, no issues with backlight
23:37 Lyude: alright, thanks!
23:37 Lyude: hopefully it's just this panel being weird...
23:40 anarsoul: Lyude: see comment from plush0 from https://aur.archlinux.org/packages/linux-oled/
23:41 anarsoul: so I guess your panel is not the only one
23:42 anarsoul: *phush0
23:42 Lyude: anarsoul: the issue i'm seeing is a bit different, basically when we write the source OUI for intel (0x00 0xaa 0x01) that's supposed to tell the panel to start exposing the registers for hdr backlight control, but they appear to not actually show up for a short period of time after that's written. I'd think if something's going on with the backlight level not being restored properly we might
23:43 Lyude: just be writing something at the wrong time, but maybe they're related
23:43 Lyude: wonder how I can get in contact with them
23:43 anarsoul: just add a comment
23:44 Lyude: gotcha, i wonder if I still have an account on the aur somewhere
23:44 anarsoul: you didn't get rid of it when you joined RH, did you? :)
23:44 Lyude: anarsoul: nah I stopped using arch ages ago. I -did- start using fedora when I got here, but that was actually by choice because i've liked it a lot more then everything else I used.
23:45 Lyude: before fedora I was on gentoo, and before that arch
23:45 Lyude: I found stuff seemed to break less on gentoo, if you can believe that
23:45 anarsoul: heh
23:45 anarsoul: I switched to arch from gentoo
23:45 anarsoul: because I found stuff seemd to break less on arch :)
23:45 Lyude: hah
23:46 Lyude: what a coincidence
23:46 Lyude: ...their captcha is a command involving pacman
23:46 Lyude: >:(
23:46 anarsoul: haha
23:47 vsyrjala: pacman is very good at truncating half my .so files to 0 bytes. has happened three separate times at least
23:47 vsyrjala: i wonder if they don't even try to updated the files atomically...