01:31imirkin: skeggsb_: did you see that NVA8 bug that bisected to the change which started bringing up falcons in pmu ctor? odd...
01:32skeggsb_: no, i didn't notice that yet, but that actually makes sense
01:32skeggsb_: thanks for the pointer :P
01:33imirkin: well, it makes sense insofar as pmu being different on nva8, but ... i thought should still work
01:33imirkin: or is it the v0 falcons there?
01:33imirkin: (is there such a thing)
01:33skeggsb_: all the cases of the nva8 think i've seen are in optimus configs, which means we're trying to touch things we shouldn't be touching prior to devinit now
01:34imirkin: ah, ok
01:34imirkin: well nva8 is also popular with desktop chips
01:34skeggsb_: (assuming that by "bringing up falcons" you mean it's touching falcon regs, and not just constructing the sw part)
01:34imirkin: marketed as GT 210
01:34imirkin: often fanless
01:34imirkin: skeggsb_: commit 1e2115d8c0c0da62405400316f5499d909e479bc
01:34imirkin: in this case it's a laptop
01:34imirkin: (and it's optimus)
01:34skeggsb_: yeah i know, but the bug i'm thinking of, i've only seen happen on optimus configs
01:35imirkin: + return nvkm_falcon_v1_new(&pmu->subdev, "PMU", 0x10a000, &pmu->falcon);
01:35imirkin: in the ctor
01:35imirkin: dunno if that touches things it shouldn't
01:35imirkin: but yeah, it dies before devinit
01:35skeggsb_: there's actually quite a few other things wrong for gt21x pmu falcon that i found when i looked into it, but i couldn't explain why the behaviour change
01:36skeggsb_: hmm yeah, it looks potentially like things could go horribly wrong with that change, depending on the board state at the time
01:37imirkin: nvkm_falcon_ctor does nvkm_falcon_rd32()
01:37imirkin: which i have to assume is a big no-no
01:37skeggsb_: if you're doing that in ctor() you have to be *very* careful, in this case, i suspect PMU is powered down still, and the reads return bad values
01:38imirkin: or hang for good measure
01:39skeggsb_: i'll see what i can manage about fixing it
07:16pmoreau: imirkin: I could try to get you some Witcher 2 traces if you want; I saw you asked for some in #dri-devel.
08:24karolherbst: imirkin, pmoreau : I think I still have a witcher2 trace
08:25karolherbst: not uploaded though :(
08:26hakzsam: imirkin: yeah, should be still easy to crash your box with f1
08:31karolherbst: maybe I will work on that trap handler thing for real and then we could even add hang detection and stuff like this
08:33karolherbst: imirkin: do you know if we can trap the shaders from the kernel side whenever we detect a CTXSW timeout?
12:55imirkin: karolherbst: if you have one that shows the badness being talked about, that'd be great
12:56imirkin: karolherbst: well ... it's somewhere in the context. mwk would know a lot more about it.
13:00karolherbst: imirkin: what kind of badness? random weirt triangles in blue/greenish colors?
13:00imirkin: the stuff being talked about for radeonsi
13:00imirkin: black grass or something?
13:00imirkin: or does it not happen with nouveau?
13:01karolherbst: afaik no
13:01karolherbst: everything was fine except random triangles
13:02imirkin: karolherbst: hmmm ok. maybe we don't return on discard?
13:07ccaione: hey guys, I have a GT1030 (NV138/GP108) with chipset == 0x138. I'm only interest in modesetting but if I use the GP107 section in the driver I got https://pastebin.com/12fMdaPD
13:08karolherbst: imirkin: well, I will check it out at some point
13:08karolherbst: mwk: shader trap handler
13:09karolherbst: mwk: I was thinking on traping the shader from the kernel whenever we detect a CTXSW_TIMEOUT
13:09imirkin: ccaione: make a log with nouveau.debug=trace and file a bug along with your vbios
13:09imirkin: karolherbst: shader trap handler won't help you there
13:09imirkin: karolherbst: the shader trap handler is for ... shader traps
13:10imirkin: CTXSW_TIMEOUT is a gr error condition
13:11ccaione: imirkin: when hooking up the chipset with the GP107 section or without?
13:11imirkin: ccaione: when hooking it up
13:11imirkin: ccaione: it's rare that there are DISP changes in minor chip revisions
13:11imirkin: (definitely not unheard of, of course...)
13:12imirkin: chances are whatever issue you're hitting can also be hit on GP107 and others -- just hasn't been due to different connectors or whatnot
13:12ccaione: well, on the pastebin link is what I get for case 0x138: device->chip = &nv137_chipset;
13:12imirkin: ccaione: right, but boot with nouveau.debug=trace and include the full thing
13:12ccaione: yeah, doing it now
13:13karolherbst: imirkin: I know, but maybe we want to dump the state somehow
13:13imirkin: karolherbst: sure, just nothing to do with the shader trap handler :)
13:13karolherbst: but we could also just add a bunch of instructions to detect such infinite loops and trap from inside the shader
13:14karolherbst: well if we can dump the state from the kernel, we could also do that, true
13:15imirkin: it's the only way
13:15karolherbst: okay, shouldn't be as hard as implementing a shader trap handler
13:15imirkin: welll.... you have to figure out where the state lies
13:16karolherbst: shouldn't be that hard
14:11ccaione: imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=101601
18:42karolherbst: imirkin: no issues with witcher2 on nouveau for me
18:44karolherbst: are there any issues with dow3?
18:52pmoreau: TW2 seemed fine for me as well. Laggy but fine.
18:52karolherbst: I know it had issues in the past, but they are gone now
18:53pmoreau: Grrrrr… I forgot I should not change the clocks after the GPU goes to sleep…
18:53karolherbst: pmoreau: use my branch instead :p
18:53pmoreau: I should patch my kernel with those
18:53karolherbst: top 8 commits: https://github.com/karolherbst/nouveau/commits/clk_update_v2
18:54pmoreau: Ok, thanks
18:54karolherbst: and if you like the risk, use my stable_reclocking_kepler_v7 branch
18:54karolherbst: it adds adjustemnts on temperature changes and a file for changing the boost level
18:55pmoreau: I tend to only use the NVIDIA GPU for my OpenCL work. Otherwise, I barely play.
18:55karolherbst: need to work on a way to poke skeggsb_ with higher effiecency :p
20:30hakzsam: imirkin_: I'm not going to look at the bindless series today
20:31hakzsam: but this week, for sure
20:32imirkin_: hakzsam: no worries... it doesn't work anwyays :)
20:32hakzsam: yeah :)
20:32karolherbst: hakzsam: do you think you will have time to look at my precise series? shouldn't take too much time
20:33hakzsam: right, that one too
20:35imirkin_: hakzsam: thanks for looking over my changes. that combineLd/St thing took a *lot* of staring at the code
20:36imirkin_: on the bright side, i think i have a much better idea of how MemoryOpt works now
20:37imirkin_: i think it should be possible to optimize it further by splitting the pass into 2 -- one to "merge" loads and stores, and another to coalesce things into pairs
20:37hakzsam: yes, that pass is a bit complicated, but your changes make sense to me
20:37hakzsam: and that piglit tess test failed since ages
20:38imirkin_: i had always assumed it was something weird about clip distances
20:38hakzsam: I think I looked at it also, without any success...
20:42hakzsam: exactly like the F1 issue, but that one looks hard to figure out
20:42hakzsam: and without an useful debugging tool which detects VM faults&co, it's not going to be easy
20:43hakzsam: ie. like R600_DEBUG=check_vm
20:48imirkin_: maybe i magically fixed it with my changes ;)
20:48imirkin_: ... the eternal hope ;)
20:48hakzsam: that would be awesome, but .. I don't think :)
20:55imirkin_: highly unlikely =]
21:32hakzsam: karolherbst: v4 looks good to me
21:39hakzsam: imirkin_: I'm looking at bindless actually, what happens when a texture (or a buffer) is invalidated? looks like you are using the old TIC. I think you have to re-upload a new one
21:40imirkin_: mmmmmmm probably
21:40hakzsam: most likely :)
21:40hakzsam: the resident TIC will contain an invalidate addr at some point
21:40hakzsam: which might explain some VM faults later on
21:40imirkin_: could be :)
21:41imirkin_: only for buffer textures, of course
21:42hakzsam: also, adding all resident buffers at every draw call is going to hurt perf a lot
21:42hakzsam: but that could be fixed later
21:42imirkin_: unfortunately there's no way to remove things from a bin
21:43imirkin_: but yeah, one could just invalidate it when residency status changes
21:43hakzsam: that would be better
21:43imirkin_: also one could add api to remove things from a bin ;)
21:43hakzsam: yep :)
21:44hakzsam: after a quick look, the most important issue is buffers invalidation
21:44imirkin_: thanks for looking
21:44hakzsam: imirkin_: when does Dirt Rally crash btw?
21:44imirkin_: thoughts on the image thing?
21:44imirkin_: during loading
21:44imirkin_: also i noticed a weird thing
21:44hakzsam: I haven't looked at images yet
21:44imirkin_: without bindless, i get the "dirty rally" logo on top, and the loading progress thing on bottom
21:45imirkin_: with bindless
21:45imirkin_: i get both on both
21:47hakzsam: let me know when you have time to fix up the buffers invalidation issue, not sure if Dirt Rally will work after that, but it should help
21:48imirkin_: definitely won't hurt!
21:48hakzsam: sadly, piglit doesn't contain any tests for that situation, my fault :)
21:49hakzsam: feel free to write one though
21:54karolherbst: hakzsam: thanks :)
21:56karolherbst: hakzsam: I don't have push access, so would you mind pushing it as well? I put the updated commits with your r-by on my gallium_precise branch
22:20hakzsam: karolherbst: yes, just wait some time if someone else reviews the series
22:22karolherbst: hakzsam: you are the 4th one
22:22karolherbst: or should I wait for more?
22:23hakzsam: yeah, but the only one for v4 :)
22:23hakzsam: just wait one or two days
22:51pmoreau: Is it ok to push directly trivial patches to envytools? (In this case, "Calsius" -> "Celsius")
22:51karolherbst: yes :p