04:21 wens: just putting it out there, I'm working on converting the st7789v panel driver to use mipi-dbi for read/write (mostly done) and adding tinydrm support
23:12 karolherbst: gallium question: when I have a resource that is used by multiple pipe_contexts and written to by shaders. Then if I want to map that resource, do I have to wait on all contexts to be done writing to it?
23:15 airlied: karolherbst: yes unless it's unsync map
23:16 karolherbst: mhhhh
23:16 airlied: though maybe you just have to wait for the kernel instead of other contexts
23:16 airlied: since they should fence it
23:17 karolherbst: yeah.. tho the issue I'm debugging is that each CPU thread maps different parts of the resource
23:18 karolherbst: on a different pipe_context
23:18 karolherbst: also there is no expectations to see the writes from different contexts
23:21 karolherbst: looks like using "PIPE_MAP_DIRECTLY" fixes the issue for me.. mhh
23:24 zmike: every other type of map will probably use a staging resource
23:24 zmike: so you'd need to wait and/or trigger a barrier for the readback copy
23:28 karolherbst: yeah but my fallback path should be equally reliable, which it isn't...
23:32 karolherbst: okay a flush + wait before the map also fixes it mhh..
23:34 airlied: if you have internal references to it in a cmd buffer you are recording, then flush/wait is usually needed, but drivers should already be doing that
23:36 karolherbst: yeah.. that's what I was assuming..
23:36 karolherbst: but it's also only broken with iris/xe
23:56 alyssa: there could easily be an iris/xe bug