11:31 cyberpear: karolherbst: is the "on then off again" runpm_fixes patch gone and solved in a new way?
11:31 karolherbst: cyberpear: don't know. I think skeggsb told me that he has something, but I don't think it's upstream yet
11:33 cyberpear: I've been running rebuilt Fedora 29 kernels w/ your runpm_fixes patches with good success on my gp107 (off-and-on-again and pci-prevent-putting... as of 5.2.20)
11:35 cyberpear: hibernating has been very stable, suspend has worked but consumed excess power, with a warm laptop and drained ~30% battery in 8 hours
11:35 cyberpear: (on a ThinkPad X1E/P1)
12:44 karolherbst: cyberpear: you can use this copr: https://copr.fedorainfracloud.org/coprs/karolherbst/Nouveau_Testing/
12:44 karolherbst: I'll try to keep it updated
12:45 karolherbst: uff.. why did my kernel build fail btw
12:45 karolherbst: ohh.. fc30
12:45 karolherbst: meh
12:46 cyberpear: Yeah, I'll be upgrading soon anyway
12:46 cyberpear: Since F31 is out this morning
12:47 cyberpear: `fedpkg mockbuild` is not to bad to handle
12:47 karolherbst: ohh, sure, but having prebuilt binaries is always easier
12:47 karolherbst: and I do them for myself anyway
12:48 karolherbst: I just want to automate it at some point
12:58 cyberpear: Definitely prebuilt is easiest
12:59 cyberpear: I've used your copr successfully in the past
14:25 imirkin_: Lyude: how did the CRC efforts go?
14:25 imirkin_: hae you gotten closer?
14:27 Lyude: imirkin_: haven't gotten into the office yet today or work on it since we talked last night , hoping to get it working today
14:28 imirkin_: awesome
14:28 imirkin_: i'm kinda around, feel free to ask questions
14:28 imirkin_: (although i reserve the right to be totally confused)
14:28 Lyude: hehe, sure thing
16:50 uis: I've benn updated mesa to 19.2.2
16:51 uis: Same program
16:51 uis: ERROR: no viable spill candidates left
16:51 uis: ERROR: no viable spill candidates left
16:51 uis: ERROR: no viable spill candidates left
16:51 uis: nvc0_program_translate:636 - shader translation failed: -4
16:52 karolherbst: uis: yeah.. I doubt that will get fixed soon enough. With what application does that happen?
16:52 karolherbst: and do you know the shader or have a trace or something?
16:56 uis: Prevous apitrace replay - same problem
16:57 karolherbst: which bug?
17:00 uis: nvc0_program_translate:640 - shader translation failed: -4
17:21 imirkin_: uis: the task is to figure out specifically which program is having trouble with, and provide the associated TGSI
17:22 imirkin_: then we can look more closely at what's actually going on
17:23 karolherbst: uis: so, what application is facing this issue?
17:24 uis: Game. "War Thunder"
17:27 karolherbst: I don't have it
17:27 karolherbst: uis: so either have to provide us an apitrace or figure out the shader causing issues and provide us the TGSI
17:27 imirkin_: he already did
17:28 karolherbst: ohh, wait.. I think I remember
17:28 karolherbst: right.. I downloaded it
17:28 karolherbst: ahh and I verified it works on pascal
17:28 imirkin_: right
17:29 karolherbst: okay.. if I don't forget, I can look into it tomorrow or next week
17:29 karolherbst: I could probably also extract the shaders and add it to our shader-db
17:31 karolherbst: sorry for not looking into it earlier
19:58 Lyude: imirkin_: hm, I've -almost- got it. We've got a proper handle now, now the only issue is the INVALID_STATE error: https://paste.fedoraproject.org/paste/4cEy7Z~MvUG3OMfP2-C-vg
20:00 imirkin_: heh
20:00 imirkin_: it almost works. only problem is that it totally doesn't
20:00 Lyude: well it isn't complaining about the handle/args anymore :)
20:00 imirkin_: uhm, so the dma object you invented was 0xff000000 ?
20:00 imirkin_: i assumed you'd just inc-by-1
20:00 imirkin_: that may be the more prudent approach
20:01 imirkin_: given that i don't totally know how those work
20:02 Lyude: imirkin_: ish, we use the head index and crc ctx index and OR them with 0xff000000
20:02 Lyude: lemme update my branch, one sec
20:02 imirkin_: anyways
20:02 imirkin_: if i'm reading this right
20:02 imirkin_: 0x404's value goes to 0?
20:02 imirkin_: which is a bit surprising.
20:02 imirkin_: can i see your patch?
20:03 Lyude: imirkin_: yeah, let me double check the method on that since that's us trying to set the portion of the raster we capture
20:03 Lyude: imirkin_: one sec
20:03 imirkin_: i don't see any mechanism for that to even happen, which is surprising
20:03 Lyude: https://gitlab.freedesktop.org/lyudess/linux/tree/wip/nouveau-crc-v1/drivers/gpu/drm/nouveau/dispnv50
20:03 Lyude: imirkin_: for what to happen, capture?
20:04 imirkin_: no - 0x404 = 0
20:04 imirkin_: wait what
20:04 imirkin_: evo_mthd(push, 0x0404 + (head->base.index * 0x300), 1);
20:04 imirkin_: evo_data(push, 0);
20:04 imirkin_: you definitely didn't mean that.
20:04 imirkin_: i don't know what you meant
20:04 imirkin_: but i know what you didn't mean - and it's that.
20:05 imirkin_: (in crc907d.c)
20:05 Lyude: imirkin_:.... no, it looks like I did mean that: https://github.com/NVIDIA/open-gpu-doc/commit/36db1ace0c3658ad43b5d94ccbba9be15f14dee5#diff-9d053df1ad96812e0b7f3c50e1ceff6eR856 but I am now just noticing that is part of a method that is not solely for CRC capture
20:05 imirkin_: right.
20:05 imirkin_: hehe
20:06 imirkin_: if you always want ACTIVE_RASTER
20:06 imirkin_: just leave it alone
20:06 imirkin_: since the zero is implicitly what gets in there
20:06 Lyude: imirkin_: yeah-I was just about to say we could try that
20:06 imirkin_: (when the other bits get set)
20:06 Lyude: mm
20:06 imirkin_: uint32_t :32; /* reserved */
20:06 imirkin_: i did not know that was legal C
20:06 imirkin_: neat.
20:07 HdkR: <3 anonymous struct members
20:07 Lyude: imirkin_: yep! anonymous stuff in C is nice
20:07 imirkin_:wonders if those are all actually __le32
20:07 imirkin_: we'll never know!
20:19 Lyude: alright, display engine seems to be hanging now when I reset the GPU (and still no CRCs yet), but I can probably figure it out from here
20:23 imirkin_: success :)
20:25 imirkin_: make sure you're doing all the same stuff as with the syncbuf
20:25 imirkin_: you have to make sure that memory is mapped
20:25 imirkin_: in the GPU VM
21:47 imirkin_: Lyude: you have to make sure to clear out the crc state when it's not being set
21:47 imirkin_: i dunno if you are
21:48 imirkin_: i.e. on first modeset
21:50 Lyude: imirkin_: if you mean making sure the ctx is zeroed out before setting it yeah, we definitely should be doing that
21:51 Lyude: i'll double check the sync stuff in a bit, need to work on some other work stuff for a bit
21:51 imirkin_: i mean zero out 430/438
21:51 imirkin_: pfft, working on the stuff you're actually paid to do? so passé
21:51 Lyude: oh, I had just assumed setting both sources to NONE is what we'd want
21:51 Lyude: imirkin_: actually I'm paid to work on nouveau :P
21:52 Lyude: among other things
21:52 Lyude: currently I have to do some of those other things :(
21:52 imirkin_: yeah, NONE for both + zero handle
21:52 imirkin_: just have to make sure that *actually* gets set
21:54 RSpliet: you guys getting paid?
21:54 imirkin_: they _think_ they are
21:54 imirkin_: little do they know...
21:59 Lyude: imirkin_: mhhh, no I don't think 430 is supposed to be zeroed out as the gpu complains more when I do that
21:59 Lyude: haven't looked at the sync stuff yet
22:00 Lyude: note: the value I've been using to disable, ffffff00 (so set both sources to NONE) seems to work fine though
22:00 Lyude: although there's still the crash on unload and the notifier ctx never gets released, which means I'm still doing something wrong - probably the sync stuff I haven't looked at yet
22:28 imirkin_: when i say "zerod" i mean "set to the blank state"
22:28 imirkin_: i.e. "NONE for both, zero handle"
22:46 Lyude: ah, yeah I'm doing that
22:46 imirkin_: ok. it's actually emitting those commands on first modeset?
22:47 imirkin_: the dirty tracking stuff is subtle
22:47 imirkin_: anyways
22:47 imirkin_: gtg
22:47 imirkin_: i'll be around later
22:47 Lyude: imirkin_: I mean, remember the crc stuff happens outside of an atomic commit
22:47 Lyude: and sure thing