12:45karolherbst: imirkin: under which circumstances could the pushbuffer end up with push->cur == NULL when trying to kick it?
12:46karolherbst: 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:47karolherbst: (using one hw channel for all contexts)
12:49karolherbst: 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:51karolherbst: 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:54karolherbst: assert is hit when going through glFinish and nvc0_flush
18:10karolherbst: ohh nvm, there is still some "set stuff inside screen when it is the first context" stuff going on
21:08karolherbst: 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:13imirkin: "the things in nvc0_screen_create"?
21:13imirkin: like fence init? then yeah.
21:13karolherbst: ohh, I have my own fence list inside the context
21:13imirkin: the kref assert usually means that you're trying to use a buffer that hasn't been registered with the pushbuf mechanism
21:13karolherbst: so that stuff more or less works
21:13karolherbst: I have some weird stuttering in glxgears when vsync is disabled
21:13karolherbst: but rendering is fine
21:13karolherbst: even inside dolphin
21:14karolherbst: imirkin: mhh, yeah... figured as much. I forgot that I wanted to check which buffer that actually is
21:14imirkin: so if you do nouveau_pushbuf_data, the pushbuf has to know about the bo being attached first
21:14imirkin: i forget how one does that
21:14imirkin: PUSHBUF_REFN probably
21:16karolherbst: thing is, I don't know what that bo actually refers to
21:16karolherbst: the dolphin code basically just binds a VAO, compiles shader, binds a VAO again and calls glFinish()
21:16karolherbst: on that context
21:17karolherbst: mhh, maybe it sets something up before that, dunno
21:17imirkin: so nothign _too_ crazy :)
21:18karolherbst: the VAO stuff is a workaround for the nvidia driver
21:18karolherbst: disabling that actually fixes the context crashes in nouveau :D
21:18karolherbst: sooo I am quite sure those contexts don't do much
21:22imirkin: time to dive into the libdrm_nouveau code
21:22imirkin: perhaps you'll arrive to the same conclusion as me eventually
21:22imirkin: aka "it must go"
21:22karolherbst: yeah.. I think I will figure that out sooner or later
21:22karolherbst: already did some debuging there
21:22karolherbst: I was just wondering if you have some better guess than I have
21:24imirkin: not off-hand
21:24imirkin: although i don't think moving fence stuff into context is workable
21:24karolherbst: well, I am already happy that I have 0 piglit regressions with the context has its own pushbuf + fence list thing
21:24imirkin: so my guess is that your issues are a side-effect of that
21:24karolherbst: mhh, dunno
21:24karolherbst: it seems to work so far
21:24imirkin: sure, but that's not a valid test of this sort of thing
21:25imirkin: that just means you don't have any glaring errors
21:25imirkin: (which is good, mind you)
21:25karolherbst: 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:16HdkR: karolherbst: Strangely. It seems disconnecting the monitor has fixed my GPU woes?
23:16karolherbst: HdkR: sounds like the worst kind of bugs
23:16karolherbst: ask Lyude about those :D
23:16karolherbst: I think we had something simliar like that
23:16karolherbst: Lyude should know
23:16karolherbst: ohhh yeah
23:17karolherbst: and it was about reboot
23:17HdkR: 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:17HdkR: mostly illegal instruction errors rather than memory mapping errors now :P
23:22imirkin: HdkR: what's your setup?
23:22HdkR: AMD TR2 2990WX and a Turing card
23:32imirkin: HdkR: with nouveau?
23:32HdkR: nah. Nouveau doesn't support Turing yet. Nor cuda :P
23:47reinuseslisp: 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:51karolherbst: reinuseslisp: I doubt anybody here took a look at those instructions yet