00:54imirkin: karolherbst: what'd you have in mind regarding locations?
00:54imirkin: we just take them from tgsi... they are what they are ...
00:54imirkin: we DO assume that indirection is 128-bit aligned, which is true with std140 layouts
03:18bubblethink: Hi. For an optimus laptop (w530), if the external monitor goes to sleep due to inactivity, it never comes back up.
06:09sooda: pmoreau: not quite sure anymore what i was talking about years ago, but that ctx-switching zcull mode is this: (see gr_gk20a_write_zcull_ptr() just above, too) https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=blob;f=drivers/gpu/nvgpu/gk20a/gr_gk20a.c;h=28ccb896afff2a754e62a5a5a3584277539ada59;hb=l4t/l4t-r31.0.1#l843 -- unfortunately, the real magic happens in the pushbufs, that's secret sauce, and I've heard it's very tricky to ...
06:10sooda: ... get right; these values are just read by fecs
06:31sooda: pmoreau: managed to google some matching historical downstream (pixel c) nouveau stuff: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/307241/
06:34sooda: pmoreau: same here https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3969eec18430a9d1abea3c3df994a311b5bc4437
06:38skeggsb: sooda: that stuff, i'm aware of. what're the chances on getting some info/hints on using it from the 3d class perspective? ;)
06:38skeggsb: that kernel stuff isn't implemented because we don't know how to use it
06:39skeggsb: i think a few people have tried, and failed, to figure it out
07:00sooda: skeggsb: low, i guess :/
07:01skeggsb: i should take a crack at it one day myself... i've yet to find time with everything else
12:36karolherbst: mupuf: I have some weirdo G84 GPUs where the pwm fan 0 means fan 100% and 100 means fan 0% :)
12:40mupuf: karolherbst: I guess they forgot to add the reversed flag on the GPIO
12:40karolherbst: or they added it allthough they shouldn't have
12:42karolherbst: will add the vbios
12:44karolherbst: mupuf: but the fan speed always reads 0 rpms anyway
12:44karolherbst: GPIO 9: line 9 tag 0x09 [FAN_PWM] OUT NEG DEF 0 HW
12:44mupuf: ok, then maybe it has NEG and shouldnt 'D
12:44mupuf: as for the fan speed, Tesla was a bit of a hit or miss
12:45karolherbst: is there another table invovled in that?
12:45karolherbst: the PM_Mode table has this: "PWM_div 0xff, Extra_length 10. Extra_count 8"
12:45mupuf: just the GPIOs
12:45karolherbst: and the entry a "Fan 100"
12:45karolherbst: and it's the only perf state
12:46karolherbst: ohh temp table
12:46karolherbst: "bump fan speed to 100% when at 115<C2><B0>C hysteresis 0<C2><B0>C"
12:46mupuf: I think we used to have to poll the GPIO on G84 until nvaX
12:47mupuf: but I think the code still works... it's just that... well... you know... the bios is full of crap
12:47mupuf: and the GPIO might not be connected to the fan's sense wire
12:47mupuf: or it was on some models and not on this one
12:47karolherbst: I can unplug the fan if that helps :p
12:47karolherbst: has only two wires
13:17karolherbst: imirkin: do you know what "CACHE_ERROR" means on a tesla gpu?
13:18karolherbst: g84 in that case
13:18imirkin: it means "welcome to hangsville, population: you"
13:18karolherbst: well, it doesn't hang at least
13:18imirkin: it will
13:19imirkin: give it time.
13:19karolherbst: it's just a simple compute kernel doing a "st u32 # g0[$r0+0x0] $r3 exit"
13:19imirkin: it has to do with context switches and so on
13:19imirkin: ok wait
13:19imirkin: maybe it is relevant
13:19karolherbst: X isn't even using that GPU
13:19imirkin: could be other reasons for a CACHE_ERROR. what's the full thing?
13:20imirkin: no - full error ;)
13:20karolherbst: (still figuring out how to read the actual kernel input in compute shaders)
13:20imirkin: btw - encodings for gmem stuff are unlikely to be validated. make sure you feed stuff through nvdisasm to double-check
13:21karolherbst: from one run: https://gist.githubusercontent.com/karolherbst/080e54d9173b39601ac2752c85376bb3/raw/dc2f86017279245e7ac79e8663e6415460f903f2/gistfile1.txt
13:21imirkin: hmmmm odd
13:21karolherbst: envydis says yes
13:22imirkin: that doesn't FEEL like the usual desync.
13:22imirkin: what's method 380?
13:22imirkin: perhaps we try to bind the wrong compute class?
13:22karolherbst: compute class: NV50_COMPUTE_CODE_CB_FLUSH
13:22imirkin: there are 4 in that gen -- g80, g84, g200, and gt215 (classes)
13:23imirkin: it's funny that the error would happen on that specific method
13:23imirkin: probably not a coincidence
13:23imirkin: ok, this is very unlikely to be the pfifo thing i was talking about
13:23imirkin: this is probably a whole different other thing
13:23imirkin: good luck =]
13:24imirkin: and maybe try an older kernel if it's convenient (at least pre-4.3)
13:24karolherbst: duh :/
13:25karolherbst: that sounds annoying to debug
13:25karolherbst: I am getting a different error than pmoreau got on his mcp79 anyway
13:25karolherbst: does nvidia expose compute shaders on tesla?
13:25imirkin: only opencl
13:25imirkin: and/or cuda
13:26karolherbst: we don't setup the g memory stuff afaik in mesa
13:26karolherbst: might be the actual cause
13:26imirkin: we did
13:26imirkin: with set_global_bindings or something
13:26imirkin: only called via clover
13:26karolherbst: we don't
13:26karolherbst: we push the input memory, yes
13:26imirkin: we did =]
13:26karolherbst: yeah... maybe it got removed
13:27imirkin: hold on, let me find it
13:27karolherbst: it's the NV50_COMPUTE_GLOBAL stuff
13:27karolherbst: I think?
13:27karolherbst: but the header seems wrong anyhow
13:27karolherbst: ohh wait, actually the macros should be fine
13:28imirkin: hm, no we don't
13:28imirkin: yeah, we set it to 0
13:28imirkin: and put the max range to 32-bit
13:28imirkin: oh right - so the buffer better be in the 32-bit va range
13:28karolherbst: maybe I should check up on that
13:29karolherbst: there is also a NV50_COMPUTE_DMA_GLOBAL as well
13:29karolherbst: but I doubt it causes those issues
13:29karolherbst: we set that to fifo->vram
13:30huehner: karolherbst: given that mesa 19.0 freeze is coming up soon, any chance to get the fixes from your threading work we talked about into there?
13:30karolherbst: huehner: most unlikely
13:30karolherbst: that's something I would like to rather merge post branching
13:30karolherbst: and have the full dev cycle as a testing phase
13:30karolherbst: if at all
13:31huehner: karolherbst: ok, thx... if you need any testing some day just ping
13:31karolherbst: well the more testing the better. I am mostly interested in still occuring threading fails
13:31karolherbst: but that's all kind of hard to detect
13:31karolherbst: I am still aware of some potential issues though
13:32karolherbst: screenf flushing is my biggest concern
13:32karolherbst: or generally operations done on the screen rather on the context
13:36karolherbst: ohhh, wait
13:38karolherbst: imirkin: seems like we only put the max range for g15
13:38karolherbst: and 0-0 for all the others
13:40karolherbst: address of the buffer is something like 0x41e000, which sounds fine
13:43karolherbst: imirkin: the errors are triggered by the clEnqueueReadBuffer call when trying to read out the result buffer
13:45karolherbst: aaahhrhhrgjjhhh... debugin clover is really anoying :/
13:46karolherbst: too much pointless abstraction
13:49karolherbst: imirkin: mhhh, okay. So that CACHE_ERROR happens if I run the kernel before trying to read out the memory. If I simply write the result and read it out, that just works
13:49karolherbst: maybe some flushing is required somewhere?
14:03karolherbst: imirkin: "buf->status & NOUVEAU_BUFFER_STATUS_GPU_WRITING" is true as well