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