12:21 karolherbst: ewww "internal compiler error" :/
12:41 MrCooper: Vanfanel: no, drmModePageFlip returns EBUSY if the previous flip is still pending
12:49 Vanfanel: MrCooper: So there is no problem if a new drmModePageFlip() call arrives before the previously issued has completed, right?
12:49 MrCooper: EBUSY is an error, i.e. a problem :)
12:51 Vanfanel: MrCooper: So, for screen updates no synced to vblank, it would be better to use drmModeSeCrtc() once, and thats it: let EGL use that buffer forever, right?
12:51 Vanfanel: Or at least that should work, shouldnt it?
12:53 MrCooper: you can use drmModePageFlip with DRM_MODE_PAGE_FLIP_ASYNC for that, if the DRM_CAP_ASYNC_PAGE_FLIP capability is advertised
12:53 MrCooper: but you always have to wait for the previous flip to complete
12:53 Vanfanel: MrCooper: even if I use DRM_MODE_PAGE_FLIP_ASYNC?
12:53 MrCooper: always as in always
12:54 Vanfanel: ok, I understand
12:57 Vanfanel: MrCooper: Since I have to call drmModeSetCrtc() at least once, shouldnt it possible to call it only once and use the same buffer forever, then? Sorry I already asked, but I would rather not use drmPageFlip(), then wait for flip, etc...
12:57 MrCooper: you can do that, but you'll get artifacts due to watching the GPU draw to the buffer
12:58 MrCooper: normal tearing in the best case, but can be uglier than that
13:01 Vanfanel: MrCooper: Well, but if I dont wait for vsync, I will get tearing anyway, wont I? drmPageFlip() and then wait for flip is the same as drmSetCrtc(), since drmSetCrtc() waits for vsync anyway.
13:02 Vanfanel: I mean, how is it worse to call drmSetCrtc() once and reuse the buffer forever than doing drmPageFlip() with DRM_MODE_PAGE_FLIP_ASYNC?
13:02 Vanfanel: Arent the two options causing the same artifacts?
13:03 MrCooper: no, tearing with async flips is equal to the best case with a single buffer
13:03 MrCooper: the latter can be much uglier
13:04 MrCooper: anyway, don't take my word for it, try it out and see for yourself
13:05 Vanfanel: MrCooper: Thing is, I have been trying these things for the last days and indeed there IS ugly tiled, diagonal drawing patterns when I reuse the buffer forever with a single SetCrtc() call.
13:05 Vanfanel: I guess thats my GPU drawing on the buffer
13:06 MrCooper: yep
13:07 Vanfanel: MrCooper: But then, what is the difference between doing an ASYNC drmPageFlip() + the mandatory wait for flip to complete, and doing drmModeSetCrtc() for each frame? In the end, I am waiting for vsync in both cases...
13:08 Vanfanel: Because, as far as I understand, if I do an ASYNC drmPageFlip() and then I wait for flip to complete, I am in fact waiting for vsync
13:08 MrCooper: the latter blocks until the flip is done, the former lets you do other work on the same thread in the meantime
13:09 MrCooper: no, ASYNC means flip ASAP, not synchronized to vertical blank
13:10 Vanfanel: MrCooper: "no, ASYNC means flip ASAP, not synchronized to vertical blank" -> But it will be done on next vsync anyway, right? there is no way it is done sooner than that
13:10 MrCooper:sighs
13:11 Vanfanel: sorry :(
13:11 MrCooper: did you read what you quoted?
13:12 Vanfanel: MrCooper: Yes, I did. But my understanding is that no flips are possible outside the vsync period.
13:13 Vanfanel: I know drmModePageFlip() will return immediately: it issues a flip, and returns. But the flip itself will not happen until vsync arrives.
13:14 MrCooper: only without ASYNC
13:15 Vanfanel: Oh, so that is why calling several drmModePageFlip() with ASYNC in a row, without waiting for vsync, is NOT a problem, right?
13:15 Vanfanel: because it does NOT have to wait for vsync to do the actual flip
13:19 MrCooper: you always have to wait for the page flip completion event, never for vertical blank
13:20 Vanfanel: MrCooper: Yes! Now I get it, I think: IF I issue an ASYNC drmModePageFlip(), I have to wait for page flip completion, which does NOT happen on vsync in that case. Is that it?
13:21 Vanfanel: Please bear with me. I am trying to understand some subtle concepts here... :)
13:21 MrCooper: that's it
13:21 Vanfanel: MrCooper: Thanks a lot, really
13:27 MrCooper: np
13:54 dj-death: is there a way to figure that 2 file descriptors represent the same GEM instance?
13:57 ickle: kcmp
14:14 bnieuwenhuizen: dj-death: mesa/src/util/os_file.h : os_same_file_description
14:33 dj-death: bnieuwenhuizen: thanks so much :)
16:29 Vanfanel: MrCooper: Do you know if there is a function to wait for flip events? Or should I "manually" wait for them on the file descriptor using pull, select, etc...?
17:21 pcercuei: Vanfanel: drm_crtc_wait_one_vblank(), I suppose
17:27 Vanfanel: pcercuei: that waits for vblank. I need something that waits for the flip event, not for vsync (I just learned tat the flip event can be ASYNC and hence it will not happen on vsync but ASAP)
17:28 Vanfanel: but thanks anyway. I am using FD I guess.
17:29 pcercuei: yeah, I assumed you flipped in vblank
17:30 Vanfanel: pcercuei: not for async screen updates
17:33 pcercuei: I know
20:53 pcercuei: I'm trying to add a driver for a HDMI chip
20:54 pcercuei: I register a drm_bridge with its set of functions and helper functions, so far so good, the .detect and .fill_modes callbacks are called
20:54 pcercuei: I can see it from userspace, it's reported as "connected"
20:55 pcercuei: but then my drm_bridge_funcs .atomic_enable, .atomic_disable or .mode_set are never called
20:57 imirkin: are you forgetting to set some atomic_enable=true sort of thing?
20:57 pcercuei: are these supposed to be called by the DRM core automatically, or should my main driver (ingenic-drm) call e.g. drm_atomic_bridge_chain_enable()?
20:58 pcercuei: most likely I am, yes
20:58 imirkin: tbh i don't really know ... in these situations i just read the core funcs and see what's up
21:37 icee: trying to troubleshoot an application i downloaded (astrodmx, for controlling astronomical cameras). ubuntu focal fossa, ordinary system mesa/glxgears/etc works fine.
21:37 icee: When I run ./astrodmx_capture, it complains ... libGL error: failed to load driver: iris, ditto for swrast, then quits with GLXBadContext
21:37 icee: when I run strace, I can see it load the iris object and a bunch of libraries that iris depends upon, then complain
21:38 icee: When I run ldd on astrodmx_capture, I don't see anything obviously stupid in what libraries it is selecting
21:38 icee: though I don't really know what I'm looking for
21:38 imirkin: libGL loads stuff dynamically
21:38 imirkin: so you won't see it with ldd
21:38 icee: I know, i was looking for it including weird things in the astrodmx package
21:38 icee: rather than system libglx
21:39 icee: but it seems to all point happily to /usr/lib/x86_64...
21:39 imirkin: LIBGL_DEBUG=verbose my provide some interesting info
21:39 icee: indeed it does
21:39 icee: libGL: MESA-LOADER: failed to open /usr/lib/x86_64-linux-gnu/dri/iris_dri.so: ../lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib/x86_64-linux-gnu/libLLVM-9.so.1)
21:40 imirkin: enjoy :)
21:40 icee: well, no clue how to fix or why ;)
21:40 icee: really confused why it should be different vs. glxgears, etc, using the same libraries
21:40 imirkin: iris was built against a libstdc++ newer than what's loaded
21:41 imirkin: does astrodmx_capture ship with its own libstdc++?
21:41 icee: oh, crap
21:41 icee: libstdc++.so.6 => ../lib/libstdc++.so.6 (0x00007f8d6d4a6000)
21:41 icee: OK, thank you.
21:41 imirkin: should be backward-compatible
21:41 imirkin: so you should just be able to update that one directly
21:41 imirkin: with your system one
21:42 icee: nice, i just moved it out of the way and it happily picked the one in /usr/lib
21:42 icee: thanks much
21:42 imirkin: yw