00:00 zmike: how so?
00:01 mareko: would you ask if set_constant_buffer looked optimal?
00:01 zmike: I'm just curious
00:01 zmike: it would've made sense before, when drivers might get raw byte data
00:02 zmike: but now the frontend does the upload
00:02 zmike: so it's just buffers being passed around
00:02 mareko: does it do the upload even for swrast and HW without constant buffers?
00:03 zmike: llvmpipe asserts that it isn't a user buffer
00:04 zmike: the pipe cap is obeyed in all cases now
00:04 zmike: so I guess it's only drivers without cbufs which get byte data
00:04 zmike: could be a separate interface at that point
00:05 mareko: drivers without prefer_real_buffer_in_constbuf0 still get the pointer to data instead of buffers
00:05 zmike: those drivers don't use tc either though
00:05 mareko: right
00:06 mareko: a new pipe_context callback would be fine for multi-slot constbuf binds
00:06 zmike: maybe I'll try it at some point
00:07 mareko: refactoring set_constant_buffer might stop being fun very quickly
00:07 zmike: I've already done it enough times
00:11 zmike: next q: KHR-GL46.shader_image_load_store.advanced-sync-textureUpdate does a shader image write(A) draw -> bind A as sampler + bind A as framebuffer draw
00:11 zmike: no memory barrier between draws
00:11 zmike: what triggers synchronization in radeonsi for this?
00:12 zmike: it seems like this shouldn't work based on spec language around memory coherency and yet
00:12 zmike: or well, it does a TEXTURE_UPDATE barrier between draws, which doesn't cover this usage and gets ignored anyway
00:15 mareko: zmike: yeah that's undefined without memory barriers
00:15 zmike: hm
00:15 zmike: confusing then since everyone seems to pass it
00:17 zmike: mareko: can you verify that you aren't emitting sync for this test?
00:32 mareko: yes there is a sync
00:36 mareko: set_framebuffer_state emits a barrier in radeonsi, which is called between all draws
00:40 zmike: interesting
00:40 zmike: and that barrier also synchronizes the sampler read?
00:40 mareko: yes
00:40 zmike: but isn't that out of spec?
00:40 mareko: yes
00:41 zmike: ok
00:41 mareko: the test might fail on radeonsi if set_framebuffer_state had no attachments
00:41 mareko: FB attachments is what generates the barriers
00:42 zmike: I see
00:45 mareko: most drivers don't insert barriers based on tracking resource usage because it would be too much overhead with thousands of pipe_resources; they just conservatively insert barriers where barriers may be necessary
00:46 zmike: sure
00:46 zmike: I ran into that a little with catia
00:47 mareko: thousands of resources?
00:51 mareko: set_framebuffer_state should always synchronize shader reads and FB writes, only shader writes need memory_barrier
00:53 mareko: set_framebuffer_state should also wait for compute shaders, otherwise compute sampler reads -> FB writes wouldn't be synchronized
01:03 mareko: the biggest trap in GL is that it doesn't have a barrier to prevent this hazard: shader reads -> FB writes, which means drivers have to either track resource to deduce where barriers should be, or all transitions between draw and dispatch should insert an implicit barrier
01:04 mareko: *resources
01:07 zmike: indeed
01:08 mareko: e.g. this case: glDispatchCompute(); glDraw(); // the driver must insert a barrier between them
01:09 zmike: well technically there should be glMemoryBarrier between them
01:09 mareko: not when it's "shader read -> FB write"
01:09 zmike: ah
01:09 zmike: I think that falls under the case of implicitly synchronized for framebuffer access
01:19 mareko: it implies that drivers should check for previous compute work in draw_vbo and insert a barrier if needed
05:49 glehmann: jenatali: did you have time to look into https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42321 yet?
06:38 tursulin: mlankhorst: hi - are you doing another drm-misc-next-fixes pr today?
06:39 tursulin: if so could you pick up https://patchwork.freedesktop.org/series/168781/ and slap cc: stable on it?
07:09 mripard: lucaceresoli: I don't think it's on anyone's todo list
07:12 lucaceresoli: mripard: ah, I see, I had misunderstood
07:13 lucaceresoli: mripard: so it's on my TODO list now
08:33 pq: FireBurn, re: Vino for DisplayLink; curious, I thought it does some heavy image compression? Can you do that efficiently in the kernel?
11:47 MoeIcenowy: is a NIR bool32 containing values neither 0 nor 0xffffffff some kind of undefined behavior?
12:07 glehmann: yes
12:39 jenatali: glehmann: Not yet
14:08 zmike: mareko: I see the issue in that test case; it does a TEXTURE_UPDATE barrier after the shader image write, and then it does TexSubImage2D, which mesa transforms into a gpu pbo upload
14:09 zmike: so the test case's memory barrier has no effect
14:09 zmike: this is some kind of a mesa internals issue but I'm not sure how to effectively represent it
14:13 zmike: I think the memory_barrier call needs to be deferred until the next "action" so that it can be rewritten if necessary
18:06 zmike: hm maybe I can do without so much surgery
22:16 FireBurn: pq: I've almost got the codec cracked, I'm not sure how efficient it'll be yet though
22:16 FireBurn: It only employs that when there isn't enough bandwidth
22:17 FireBurn: The main blocker is getting sub=0x45 engagement + Stream_Ready