00:00vincenttc: I did that in one test with the same result iirc
00:00imirkin: ok, well you definitely need it no matter what
00:00imirkin: the client has to submit commands to the gpu
00:00imirkin: without that, no drawing, and the "other" side of the dma-buf can't possibly know that's what's happening
00:01vincenttc: either way, it doesn't appear to be enough
00:02imirkin: btw, i assume you're using either 32x32 or 64x64 DRM_FORMAT_ARGB8888 images?
00:03imirkin: from everything i see, that should give you a "live" view of those images
00:04karolherbst: HdkR: 32kx32k?
00:04vincenttc: hmm, strange
00:16imirkin: vincenttc: to double-check, the dma-buf is generated on the same gpu as it's consumed?
00:17vincenttc: imirkin: in this case no dma-bufs are involved, I'm just rendering to the same bo as is attached
00:17imirkin: oh ok
00:19HdkR: karolherbst: On pascal yea
00:19imirkin: can you share some code? i may be able to have a look
00:20imirkin: karolherbst: ok ... so ... the plan is to keep developing my test but artificially limit it to 8k. given that > 8k doesn't seem to work either way, same principles should apply.
00:20imirkin: karolherbst: unfortunately we do have to get this little tidbit figured out, since 16k is required for GL4
00:22karolherbst: mhh, I see
00:22vincenttc: imirkin: the code itself might not be all that readable since it is behind some abstraction but this is the relevant part: https://github.com/swaywm/wlroots/blob/master/backend/drm/drm.c#L696-L711
00:22vincenttc: plane->surf is created with gbm_surface_create iirc
00:23vincenttc: crtc_set_cursor calls drmModeSetCursor
00:24vincenttc: the rendering functions end up in here https://github.com/swaywm/wlroots/blob/master/render/gles2/renderer.c
00:42imirkin: skeggsb: looks like GP104_COPY class has rev'd where the x/y/z offsets go
00:43imirkin: srcx/y go into 0x744/748
00:43imirkin: i can make guesses about the rest :)
00:43imirkin: should try to devise a test that fails on pascal but not earlier
00:45imirkin: (this is with c1b5, but i bet c0b5 also has this)
00:45imirkin: according to HdkR textures can be a lot wider, which would explain the change
00:46HdkR: The widest you could ever want
00:46imirkin: i wonder if it maintained compat with the old stuff, which is why we haven't noticed
00:46imirkin: HdkR: don't underestimate my imagination :p
00:47HdkR: I think it is 2m width now?
00:47HdkR: Would need to double check
00:47imirkin: i can think of bigger numbers.
00:51HdkR: workgroup width also went to the moon in compute
00:52karolherbst: HdkR: again? :/
00:52HdkR: 2147480000 x 64k x 64k
00:53karolherbst: that we already have
00:53HdkR: Ah, alright :)
00:53karolherbst: we set it to 2147483647 though
00:53karolherbst: since kepler
00:53imirkin: since kepler, no?
03:34imirkin: wow, i think i found the bug
03:34imirkin: dumbest. bug. ever.
03:41imirkin: at least logic persists in the universe.
11:47karolherbst: imirkin: duh! ...
11:55karolherbst: imirkin: but we have to do increase that to 32768 for gens which support it?
15:43karolherbst: imirkin: do you think it might be a viable thing to lock all screen operations in order to prevent mt issues in a case where each context already got it's own pushbuffer? I think it only has to cover the functions setup by nvc0_screen_init_resource_functions
15:44karolherbst: and then maybe not even all...
15:58karolherbst: also, there are nice "dEQP-EGL.functional.sharing.gles2.multithread.*" tests :)
16:00karolherbst: ups... yeah, they cause a hang realy fast on mesa-master
16:11karolherbst: okay... got another bo use-after-free corruption
17:56karolherbst: ohh, actually this is a regression from my patches
18:34imirkin: karolherbst: i think i just want to kill the "eng3d" path with fire... it's too hard to make it work for MS up-sample and downsample properly, esp given the various games we play with disabling MS and so on
18:46karolherbst: yeah. I highly doubt there are any downsides using u_blitter either. Or does it have a higher overhead?
18:47imirkin: well, the downside is that it doesn't work
18:47imirkin: and has to be modified to work with nouveau
18:47imirkin: other than that it's great :)
18:47karolherbst: okay sure, but we have to fix our eng3d path also from time to time
18:48imirkin: the issue is that we (a) have a shitty resolve and (b) have pretty buggy handling of MS in general, in that path
18:48imirkin: so ... even if it's "faster", i think dumping it is the right move
18:48imirkin: most of the "fast" cases are handled by the 2d path anyways
18:49imirkin: i haven't looked in great detail, but i think the u_blitter changes to make it work with nouveau's lack of stencil export should be largely achievable
18:53karolherbst: yeah, otherwise u_blitter wouldn't be that great if we couldn't teach it that :p
19:17imirkin: gm200+ has stencil export btw
19:17imirkin: but that won't help me!
23:00vincenttc: imirkin: so, after quite a long search I've managed to find out why the dissapearing cursor problem that I was having occured. When a gbm bo is created with GBM_BO_USE_LINEAR it is initially placed in the gart domain. It is pinned to vram when drmModeSetCursor is called, the rendering operations are presumably still directed at the old location of the bo.
23:00imirkin: would have see how the pinning works
23:01imirkin: in principle it shouldn't matter if it's in gart or vram, the VA remains the same
23:08vincenttc: so, should I report this on the bugtracker?
23:10imirkin: you could
23:11imirkin: chances of it getting fixed by someone other than yourself are limited though
23:11imirkin: since it's a pretty esoteric use-case
23:18vincenttc: mmh, fair enough
23:18imirkin: happy to answer any questions though
23:18vincenttc: if I have some spair time in the future I might try it
23:18imirkin: and given how far you've tracked it down already, i'm sure you'll be capable of working out the solution
23:18vincenttc: but since glFinish "fixes it, it won't be that high of a priority for m either
23:19imirkin: i don't have a good explanation for that
23:19imirkin: glFinish is just glFlush + wait for fence completion
23:19vincenttc: it probably just allows the render operations to finish before the buffer is moved from gart to vram
23:20imirkin: let me quickly see hwo drmModeSetCursor works exactly
23:25imirkin: skeggsb: looks like we never define a cursor_set function?
23:26imirkin: vincenttc: do you happen to get an error when you use drmModeSetCursor?
23:26imirkin: oh wait, nm.
23:26imirkin: we have crtc->cursor set.
23:27skeggsb: imirkin: it's not set because that's deprecated, cursor plane is used instead
23:28vincenttc: imirkin: the move happens in nv50_wndw_prepare_fb when it calls nouveau_bo_pin
23:29imirkin: vincenttc: hmmmm i wonder if the literal MOVE doesn't wait for rendering to complete
23:29imirkin: that'd make sense
23:29imirkin: skeggsb: do we wait for pending fences before scheduling a move?
23:29imirkin: i assume not
23:30skeggsb: pretty sure that happens somewhere, whether it be in the driver or in ttm itself
23:31imirkin: skeggsb: unrelated - did you see i have a reproducible CTXSW_TIMEOUT with a simple-ish dEQP test on a GK208B?
23:31skeggsb: yeah, i vaguely recall seeing that go past
23:32imirkin: any thoguhts? :)
23:33skeggsb: i'd be very surprised if it were related to gr init like the stream master thing you mentioned, because i got us *identical* to RM there when i did volta bring-up
23:33skeggsb: (except for some sm mapping stuff on generations maxwell 2 and up)
23:33imirkin: skeggsb: ok
23:33skeggsb: though, i also don't have a gk208b, so, it's feasible there could be something there too
23:33imirkin: fwiw i gave it a once-over again
23:34imirkin: i did only look at a GK208 boot log
23:34imirkin: not GK208B
23:34imirkin: [and didn't find any discrepancies]
23:34skeggsb: i usually hack the driver to log all reg writes for gr init, and diff it against a mmiotrace of RM
23:35imirkin: i'll try to generate one with the GK208B and see if there's something funky. ideally someone else on a different kepler can chekc if it happens there too
23:35imirkin: or if i'm just extremely lucky
23:35skeggsb: "lucky" ;)
23:36imirkin: you know how it goes
23:36imirkin: i picked a board to plug in that i can actually run my new monitors with...
23:36imirkin: and it has this issue =/
23:36skeggsb: i've got a shiny new monitor now too actually, but not time yet to play with it
23:37imirkin: and i had to fix a bunch of rotation-related bits. o well. all good now.
23:37imirkin: trying to get my hands on a K4000 so that i can do everything all at the same time
23:47karolherbst: skeggsb: ohh, maybe you know this: any idea why sticking vertex buffer into VRAM can cause the channel to be killed?
23:47karolherbst: and it's working fine if we stick them into system mem?
23:48karolherbst: I have like 3 or 4 games which lead to channel to be killed, and sticking all vertex buffers into sysmem apperantly fixes that
23:51airlied: coherency issues? or different response to out of bounds access?
23:52karolherbst: maybe? but we get a CTXSW_TIMEOUT
23:52karolherbst: that's why I am wondering about that issue
23:53karolherbst: it's not like I get a trap or some other warp error or something
23:54RSpliet: Or you're missing an error in a place where you (and the interrupt handler) doesn't expect it, which doesn't get cleared.
23:55karolherbst: I would expect to get a different error message about that though
23:55RSpliet: No, nouveau would miss it
23:55RSpliet: And when FECS/GPCCS try to pause the engines for a context switch, they time out
23:55karolherbst: there is that "nvkm_error(subdev, "INTR %08x\n", stat);" message for unhandled interrupts on the fifo
23:56RSpliet: CTXSW_TIMEOUT is exactly that... well, 99.9% of the times it means "I tried to idle the engines, but it didn't happen in 200ms" or whatever the timeout it set to
23:56karolherbst: I'd agree if that would be our firmware
23:56karolherbst: but because it's nvidias... I have no idea what CTXSW_TIMEOUT exactly means
23:56karolherbst: could be anything
23:57RSpliet: It's the only reason why it could time out.
23:57RSpliet: Idle engines, swap context, resume. That's all a context switch does
23:57karolherbst: maybe nvidias firmware doesn't like something and just bails out for no reason at all
23:57karolherbst: how should we know?
23:57RSpliet: bailing != timeout
23:58karolherbst: and who controls what error is sent to the driver?
23:58RSpliet: You could RE the firmware if you want to be 100% sure, but... well, you can only spend your time once
23:58karolherbst: I mean, I could check if we miss an interrupt or something, but it looks like we always handle unknown ones as well
23:59karolherbst: maybe using nouveau.trace sheds some light? dunno