00:00 Kayden: if server_wait_sync made context A's deferred work actually happen, we'd be fine
00:00 Kayden: if context B's work sat around indefinitely until context A's work actually got submitted and eventually happened, we'd be fine
00:00 Kayden: (assuming something forced that to happen eventually)
00:01 mareko: you're right
00:01 Kayden: The scary thing to me is....having server_wait_sync in context B submit context A's deferred work means....how is this thread safe
00:02 mareko: Kayden: we could disable deferred flushes if there are multiple contexts in the share group
00:05 Kayden: that might side-step the problem, I'm not sure if you can add contexts to the share group after creating some fences that happen to be deferred already
00:06 mareko: Kayden: that can happen indeed
00:08 mareko: Kayden: do we expect multiple GL contexts cooperating from multiple threads?
00:09 Kayden: I figured that would be a prime reason to use multiple contexts and syncobjs
00:09 Kayden: though, I can totally believe this doesn't happen in practice much - especially since you've had this in radeonsi for several years now
00:09 Kayden: (perhaps "not much" -> "basically ever")
00:11 Kayden: ickle: what's the latest on WAIT_FOR_SUBMIT?
00:11 Kayden: seems like that would be a nice solution to this problem
00:12 HdkR: I know at least one app that uses shared contexts from two threads. One for rendering, one thread for presentation. That sort of cooperating?
00:12 Kayden: stuck in not-actually-landing hell due to igt testing?
00:14 mareko: HdkR: does it use glWaitSync? (server-side sync)
00:14 Kayden: (ClientWaitSync should be fine)
00:15 HdkR: Hm, I don't recall which one it would be using now
00:15 mareko: EGL is fine too
00:15 HdkR: Oh, then w/e, I have a hard time caring about glx
00:16 Kayden: this is just GL though
00:16 Kayden: ARB_sync
00:18 Kayden: actually I don't really see how ClientWaitSync works either
00:19 ickle: there was someone tasked with polishing, went quiet again
00:19 Kayden: ClientWaitSync (fence_finish) may need to flush commands in another context as well
00:19 Kayden: right now it just... doesn't. and waits
00:20 Kayden: which I think would be fine if we had WAIT_FOR_SUBMIT again
00:22 mareko: Kayden: yes it deadlocks, though it doesn't bother me as long as I don't see the deadlock in reality
00:23 Kayden: almost like you want to just block until the other thread submits the work
00:25 mareko: radeonsi deadlocks, that is
00:26 Kayden: ickle: I guess I don't understand - if we create a syncobj, it starts unsignalled. if we drm_syncobj_wait on that, it should wait until it's signalled...by something, someday
00:26 Kayden: and may just block forever if it isn't
00:26 Kayden: if that's true then clientwaitsync is fine
00:26 ickle: a syncobj is a just a tag that points to nothing on creation
00:26 mareko: BioShock Infinite runs slow without deferred flushes
00:27 Kayden: mareko: Yeah...I remember it being 20% for you. It's 9% on my laptop
00:27 ickle: we need to install a proxy fence wait on that, and have the fence wait to be replaced; that's wait-for-submit
00:28 Kayden: mareko: bioshock is pretty insane - they <Begin OQ, draw, End OQ, FenceSync> 450 times/frame, and then poll for fence completion at the start of every frame. When they could...just check the query status
00:29 Kayden: mareko: and I think all within a single context, too
00:29 Kayden: there's no reason for them to do it that way as far as I can tell
00:29 Kayden: but it's what they do, so...have to make it not suck
00:31 mareko: gotta love workstation apps: no textures, just set vertex attribs, draw, repeat
00:31 Kayden: ickle: I guess I could replace drm_syncobj's with a... <actually submitted lock, syncobj> pair...and maintain my own queue of submissions in userspace...
00:31 Kayden: this sounds kind of nasty
00:32 Kayden: mareko: haha, yeah, who uses images, just gouraud shading FTW
00:50 Kayden: ok I've decided to apply the ostrich algorithm and add pipe_debug_messages for waiting on fences that haven't been flushed from another context
00:50 Kayden: that way we might at least get a message about it being totally broken
00:51 Kayden: and hopefully by the time we get an actual report about that the kernel API will have finally landed and we'll have the tools to do something about it
10:44 sravn: mripard_: (could not find other drm-misc maintainers online). Commit 8d6cb2f7fb90018d9e3e ("drm/drm_panel: fix export of drm_panel_of_backlight, try #3") is not in upstream kernel. Anything I shall do to get it in the upstream kernel? It is in drm-misc-next but not in any -fixes branch (as far as I know)
13:56 pcercuei: sravn: Re: modeset callback on panels. That would be useful too when the panel supports rotation
15:19 pcercuei: Is there a way to have fully cachable GEM buffers?
16:45 imirkin: pcercuei: i think there's a shmem variant of gem buffer backing
17:08 pcercuei: imirkin: thanks, I'll take a look
17:10 imirkin: pcercuei: but basically the drm driver decides ... so if it's cma, it's cma, if it's shmem, it's shmem
17:13 pcercuei: yep
17:48 pcercuei: hmm, I just miss one function... a shmem variant of drm_fb_cma_get_gem_addr()
17:52 pcercuei: I guess I can just call drm_va_node_start() on the gem_object's vma_node
17:58 pcercuei: hmm. No
17:58 danvet: narmstrong, any idea why devm_clk_get_enable is in meson/axg-audio.c and not somewhere more useful?
17:59 danvet: I've found a pile of drm drivers that could make extreme use of this thing
18:01 narmstrong: danvet: wut ? No idea
18:02 danvet: you reviewed that code, hence the ping :-)
18:20 pcercuei: imirkin: turns out shmem isn't really an option, since my DRM driver (ingenic-drm) requires contiguous buffers
18:20 pcercuei: So it's CMA or CMA
18:23 imirkin: pcercuei: right ... that was my point about the drm driver kinda determining what it needs
18:23 imirkin: shmem is good when there's no dma or whatever
18:26 pcercuei: alright
21:52 pcercuei: Is there a way to retrieve the mmaped address of a GEM buffer?
22:10 pcercuei: alright, cached GEM buffers are working