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