12:45 karolherbst: imirkin: under which circumstances could the pushbuffer end up with push->cur == NULL when trying to kick it?
12:46 karolherbst: I know have a state where each contexts has its own pushbuf + fence list and it seems to work perfectly fine with single context applications, but when there are more contexts, something goes wrong :/
12:47 karolherbst: (using one hw channel for all contexts)
12:49 karolherbst: side note: for the validation of the const buffers we use a reference from nvc0->screen.base.pushbuf instead of nvc0->base.pushbuf, which we use nearly everywhere else (even if both poiniters point to the same pushbuf).. took me a while to actually figure that out
17:51 karolherbst: mhh seems like a nouveau_pushbuf_validate fixed that... but now I am getting a "../../nouveau/pushbuf.c:723: nouveau_pushbuf_data: Assertion `kref' failed." on those shader compile threads inside dolphins... dunno if that's my fault or actually just nouveau assuming stuff happening on the pushbuf (the thread basically just bings a vbo, compiles, binds a vbo and quits)
17:54 karolherbst: assert is hit when going through glFinish and nvc0_flush
18:10 karolherbst: ohh nvm, there is still some "set stuff inside screen when it is the first context" stuff going on
21:08 karolherbst: imirkin: any ideas why a pushbuf might be not safe to kicked if the things in nvc0_screen_create are skipped? My code seems to work for trivial applications or single threaded dolphin, but when I enabled the multi context features inside dolphin it asserts on the assert(kref) thing inside nouveau_pushbuf_data
21:13 imirkin: "the things in nvc0_screen_create"?
21:13 imirkin: like fence init? then yeah.
21:13 karolherbst: ohh, I have my own fence list inside the context
21:13 imirkin: the kref assert usually means that you're trying to use a buffer that hasn't been registered with the pushbuf mechanism
21:13 karolherbst: so that stuff more or less works
21:13 karolherbst: I have some weird stuttering in glxgears when vsync is disabled
21:13 karolherbst: but rendering is fine
21:13 karolherbst: even inside dolphin
21:14 karolherbst: imirkin: mhh, yeah... figured as much. I forgot that I wanted to check which buffer that actually is
21:14 imirkin: so if you do nouveau_pushbuf_data, the pushbuf has to know about the bo being attached first
21:14 imirkin: i forget how one does that
21:14 imirkin: PUSHBUF_REFN probably
21:16 karolherbst: mhh
21:16 karolherbst: yeah..
21:16 karolherbst: thing is, I don't know what that bo actually refers to
21:16 karolherbst: the dolphin code basically just binds a VAO, compiles shader, binds a VAO again and calls glFinish()
21:16 karolherbst: on that context
21:17 karolherbst: mhh, maybe it sets something up before that, dunno
21:17 imirkin: so nothign _too_ crazy :)
21:18 karolherbst: yeah
21:18 karolherbst: the VAO stuff is a workaround for the nvidia driver
21:18 karolherbst: disabling that actually fixes the context crashes in nouveau :D
21:18 karolherbst: sooo I am quite sure those contexts don't do much
21:22 imirkin: time to dive into the libdrm_nouveau code
21:22 imirkin: perhaps you'll arrive to the same conclusion as me eventually
21:22 imirkin: aka "it must go"
21:22 karolherbst: yeah.. I think I will figure that out sooner or later
21:22 karolherbst: already did some debuging there
21:22 karolherbst: I was just wondering if you have some better guess than I have
21:24 imirkin: not off-hand
21:24 imirkin: although i don't think moving fence stuff into context is workable
21:24 karolherbst: well, I am already happy that I have 0 piglit regressions with the context has its own pushbuf + fence list thing
21:24 imirkin: so my guess is that your issues are a side-effect of that
21:24 karolherbst: mhh, dunno
21:24 karolherbst: it seems to work so far
21:24 imirkin: sure, but that's not a valid test of this sort of thing
21:24 karolherbst: yeah
21:25 imirkin: that just means you don't have any glaring errors
21:25 imirkin: (which is good, mind you)
21:25 karolherbst: I already did same test with having the screen pushbuf being a parent of the context one and kick/ref stuff on two levels... but that doesn't work out that well with multithreading, obviously
23:16 HdkR: karolherbst: Strangely. It seems disconnecting the monitor has fixed my GPU woes?
23:16 karolherbst: HdkR: sounds like the worst kind of bugs
23:16 karolherbst: ask Lyude about those :D
23:16 karolherbst: I think we had something simliar like that
23:16 karolherbst: Lyude should know
23:16 karolherbst: ohhh yeah
23:17 karolherbst: and it was about reboot
23:17 HdkR: I've been going through my typical routine for a week or so now and it is still fine. Although I'm faulting the GPU far less often now
23:17 HdkR: mostly illegal instruction errors rather than memory mapping errors now :P
23:17 karolherbst: "progress"
23:22 imirkin: HdkR: what's your setup?
23:22 HdkR: AMD TR2 2990WX and a Turing card
23:32 imirkin: HdkR: with nouveau?
23:32 HdkR: nah. Nouveau doesn't support Turing yet. Nor cuda :P
23:47 reinuseslisp: Hi. I'm trying to get around H* instructions, "hadd2 $r200 $r50 $r70" works as expected but "hadd2 mrg_h0 $r200 $r50 $r70" (mind the mrg_h0) sets $r200, $r50 and $r70 to zeroes. Does this mean that my Pascal doesn't fully support half floats?
23:51 karolherbst: reinuseslisp: I doubt anybody here took a look at those instructions yet