02:14 imirkin_: so ... funny story
02:15 imirkin_: we're not attaching fences to image buffers
02:15 imirkin_: "oops"
02:15 imirkin_: that means that render to image + map buffer don't necessarily end up synchronized
02:44 imirkin_: nm. nvc0_bufctx_fence should take care of it.
06:38 glennk: nv30_transfer_rect_blit produces intermittent trash for < 16x16 pixel wide copies, any ideas?
08:28 karolherbst: glennk: I guess it goes down the (!dst->pitch) path?
08:28 karolherbst: maybe it can't be smaller than 4?
08:30 glennk: the thing is it does render correctly, most of the time
08:30 karolherbst: mhh
08:30 glennk: something like that would fail consistently, not intermittently
08:30 karolherbst: true
08:30 glennk: it looks more like further rendering isn't waiting for end of pipe to drain
08:30 karolherbst: guess synchronization it is then
08:31 glennk: i've tried a few different ways of waiting for idle and cache flushing but nothing seems to bite
12:28 glennk: more nv4x fun, piglit fbo-depth clear fails, but re-running a captured trace on the same machine renders correctly
14:23 imirkin: glennk: sometimes the buffer in vram will just have the right stuff
14:23 imirkin: i hate it when that happens
14:23 imirkin: you can mess with the blit selection logic and force a different method to see if it's a problem with the method
14:23 imirkin: or if it's a problem with something else
14:24 glennk: nah, its actually rendering the content when it shows up, the buffer is cleared at the start of the test
14:25 glennk: using the cpu path for < 16 worked for this case, but it then fails on various other types
14:26 imirkin: yeah, i think there are issues with the cpu path
14:26 imirkin: also, FYI, there's 0 way for the GPU to render to a 3d texture
14:26 imirkin: not a single method
14:26 glennk: random note, nv30_clear_render_target and nv30_clear_depth_stencil seem to have swapped their intent
14:26 imirkin: of uploading texture data
14:26 imirkin: or otherwise affecting the data in any reasonable way
14:26 imirkin: heh
14:26 imirkin: well, those functions are never used
14:26 imirkin: only for st/nine maybe? not even sure about that
14:27 glennk: they definitely get hit for bin/fbo-depth-clear
14:27 imirkin: something must call them directly then
14:27 imirkin: that's surprising
14:27 imirkin: bbiab
14:27 glennk: nope
14:51 imirkin: there should be 0 calls to nv30_clear_render_target that i can see
14:51 imirkin: gallium/drivers/nouveau/nv30/nv30_clear.c:nv30_clear_render_target(struct pipe_context *pipe, struct pipe_surface *ps,
14:51 imirkin: gallium/drivers/nouveau/nv30/nv30_clear.c: pipe->clear_render_target = nv30_clear_render_target;
14:52 imirkin: those are the only instances in nv30
14:52 imirkin: and then there's nothing in st/mesa which would call it
14:52 imirkin: there's stuff in st/nine which will call it though
14:52 imirkin: or i'm blind. another popular option.
14:56 karolherbst: imirkin: vaapi and vdpau do though
14:57 karolherbst: but shouldn't apply either
14:57 imirkin: not super-relevant for nv30 :)
14:58 imirkin: glennk: that's hilarious though that they got swapped. i wouldn't be surprised if that were my bad.
14:58 imirkin: "oops"
14:58 imirkin: ah no. looks like skeggsb had that in his initial nv30 checkin (a2fc42b899de)
14:59 imirkin: maybe it was bad in nvfx too? dunno
15:06 glennk: you're right about it not being called, i had a poorly chosen printf string confusing me which one was used
15:17 imirkin: glennk: btw, after i (or someone) sends you a R-b, you should update the commit in the MR and then assign to marge-bot (or if you can't assign, i'll assign)
15:17 glennk: oh, haven't seen any R-b
15:18 imirkin: maybe i forgot to give it ;)
15:18 imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12154
15:30 glennk: now i'm wondering whats putting a PIPE_FORMAT_R32G32B32A32_FLOAT into a fbo-depth clear GL_DEPTH_COMPONENT16 test case
15:31 imirkin: GL_FLOAT?
15:31 glennk: glReadPixels maybe
15:32 imirkin: i know it's been a while since you've looked at gallium stuff ... but are you familiar with GALLIUM_TRACE=foo.xml env var?
15:35 glennk: so apparently st is creating a buffer for readpixels and then doing a blit to it
15:36 glennk: and the test case was previously working because the driver wasn't reporting support for rendering to that format (i just added that)
15:43 imirkin: probably not the case here, but rendering doesn't work for width=1 surfaces
15:43 imirkin: (pretty sure the dispatch-time validation catches it)
15:44 glennk: the surface here is 123x123
15:45 imirkin: that should be fine-ish?
15:45 imirkin: it means it's non-swizzled
15:45 imirkin: (POT textures are normally swizzled, although not required to be)
15:46 glennk: i got the test passing now, but i'm a bit confused as to the thing that was breaking it
15:46 glennk: there's a RT_CONTROL flag for setting if the pixel shaders should export outputs as fp16 or fp32
15:49 glennk: and if i don't touch that bit the m2mf works fine
20:04 glennk: okay, i spent way too long debugging why fbo-depth was returning depth values that were off by .003