00:28mwk: Echelon9: hey, I see you've made a lot of envytools pull requests
00:28mwk: what are your plans regarding it?
00:34Echelon9: @mwk: Generally interested independent Linux graphics developer
00:34Echelon9: I've contributed to vc4 and i965 drivers in Mesa so far
00:34Echelon9: And taking a look at the nv stack (I like a challenge)
00:35mwk: ah, sounds like fun
00:35mwk: well then
00:35mwk: welcome to the madhouse
00:35Echelon9: So, have started out with simple tasks to learn more about the state of the code and tooling
00:40Echelon9: what areas are you looking at currently @mwk
00:52mwk: REing ancient cards for fun and no profit
00:56Echelon9: Which family series?
01:14Echelon9: Nice. Is it hard to get hold of working AGP systems (motherboard etc) to develop with those GPUs?
01:20nyef: Probably more tedious than anything, especially if they have to serve as build hosts. (-:
01:21imirkin: i think it's all nfsroot
01:22nyef: "nfsroot: loathe it or ignore it, you can't love it."
01:23nyef: I think that the first time I knowingly used an nfsroot was the mid-'90s. It really hasn't gotten any better since.
04:42gnurou: karolherbst: when you resume from sleep, is secure boot performed again? It should be normally, then I'd expect the PMU to be in the same state as after the initial secboot, so surprised that you are getting different behavior
05:40gnurou: karolherbst: mmm, could it have to do with the fact that the unload blob is called during suspend? what happens if you load/unload Nouveau then load it again, can you load your PMU code?
05:42gnurou: karolherbst: in any case, when running the unload blob, we are re-loading code into the PMU, so if you follow what is done there you should be able to load your code too
10:32gnurou: karolherbst: mmm actually on configurations where there is no LS PMU blob, /stupidme could just automatically run the unload blob right after secure boot is completed instead of lazy-doing it... this should leave you with the PMU in a clean state
10:32karolherbst: right, there is this unload blob
10:37karolherbst: gnurou: will you write a patch for that then? I could try it out a hacky way today afternoon just to confirm this
10:37karolherbst: What does the unload blob do actually? Just cleanup all the stuff and reset some regs only a HS image can reset?
10:38gnurou: karolherbst: precisely. Also it unlocks the WPR region that the load blob has just set
10:38gnurou: Write PRotected
10:38karolherbst: I see
10:39gnurou: the region that contains the firmwares to be loaded into other falcons and that *only* the PMU can write, to avoid code injection
10:40gnurou: I am actually swamped with something else right now, but it should not be difficult to do: in acr_r352_reset_nopmu(), just cann acr_r352_shutdown() right after acr_r352_bootstrap()
10:40lynx`: hi. is a nouveau developer possibly interested in my GeForce GTX 960 (NV126) card?
10:40karolherbst: gnurou: I actually tried to call nvkm_secboot_fini
10:40karolherbst: inside nvkm_pmu_init
10:40gnurou: at this point the GR firmwares will already be loaded and you should be good
10:41karolherbst: gnurou: what I did was this: move the PMU subdev to a lter point, so it gets init after secboot and gr
10:41karolherbst: and then try to reset the PMU inside nvkm_pmu_init with nvkm_pmu_fini and nvkm_secboot_fini
10:41gnurou: I would expect that to work
10:41karolherbst: me too
10:41gnurou: what happens precisely?
10:42karolherbst: pmu falcon doesn't get into run state
10:42karolherbst: more I don't know
10:42karolherbst: I can't start the PMU either
10:42karolherbst: by hand
10:42gnurou: because since the unload blob can be run without issues, I suppose you should be able to load code and run the PMU
10:42gnurou: the first code that the unload blob runs is a bootloader that is not signed, entering HS mode happens way after
10:42karolherbst: maybe I need to run nvkm_secboot_init again
10:43karolherbst: ohhw ait
10:43karolherbst: there is no secboot_init
10:43karolherbst: already thought about it
10:43gnurou: have you tried nvkm_falcon_reset()?
10:43karolherbst: maybe not in this combination
10:43karolherbst: mhh true, pmu_fini doesn't call nvkm_falcon_reset afaik
10:43gnurou: try and follow the procedure done by secboot to load and run code, this should definitely work
10:44karolherbst: yeah, it works after suspend without problems
10:44gnurou: need to leave for now, will come and check again later - good luck
10:45karolherbst: yep, no falcon_reset is called :) the missing out of the unload image might also explains the errors I got with falcon_reset without secboot_fini
10:45karolherbst: then it makes sense
10:56mupuf: imirkin: why not rename UNK1690 to ZERO_WIN?
10:56mupuf: or does it contain a bitfield with more unknown stuff?
11:00pq: as in, you can only ever lose with that reg? ;-)
11:04mupuf: pq: hehe
11:04mupuf: the idea is that if you get 0 * inf, what do you return?
11:04mupuf: inf or 0?
11:04mupuf: with zero_wins, you get 0
11:13karolherbst: we could always return 0 and have more optimized shaders :O
11:13karolherbst: allthough I highly doubt it matters much
11:14RSpliet: karolherbst: talking about zero_wins? This stuff should strictly defined by the GL/CL/DX specifications
11:14karolherbst: I see
11:15karolherbst: well still, we could add this info into our compiler
11:15RSpliet: I presume the sole existence of the flag is for https://cgit.freedesktop.org/mesa/mesa/commit/?id=e1346f25bf6e40496c8db868fe03e20b900c41e4
11:15RSpliet: which is why Ilia added this info to the compiler ( https://cgit.freedesktop.org/mesa/mesa/commit/?id=b755f2f233e621d8fa066d5e7dfd1b24f8ecf46d )
11:15karolherbst: I see
11:15RSpliet: keep up mate ;-)
11:16karolherbst: I was talking about shader opts :p
11:16RSpliet: There's very little optimisation you can do based on this info hopefully
11:17RSpliet: (but do tell me what you have in mind, I can't think of anything for which this makes a difference)
11:18karolherbst: I can't either
11:41mupuf: RSpliet: you could get rid of the mul altogether if you know both operands .... but it was true before this too :D
11:42RSpliet: so it makes no difference ;-)
11:43RSpliet: (it's true though that for NV50 const propagation might have to be rechecked for correctness)
11:46mupuf: I doubt we have such opt
11:46RSpliet: mul with two constants, one of which is inf?
11:46RSpliet: sounds like a peephole opt to me
11:47RSpliet: question is whether this is handled at the GLSL level or in the nouveau compiler
13:58imirkin: mupuf: it's updated in the rnndb headers iirc
14:00imirkin: mupuf: also, with ieee semantics, 0 * inf = nan, not inf.
14:10imirkin: also, yeah, the compiler isn't clean WRT this stuff and const folding, but ... meh. i don't really care.
14:10imirkin: find me an app that cares, and i'll care.
14:11mupuf: thanks for letting us know!
14:12imirkin: for example, i think the compiler will const-fold 0*x -> x.
14:13imirkin: -> 0
14:13imirkin: instead of leaving it in place on the odd chance that x is inf or nan.
14:13imirkin: basically like 50% of the opts we make are unsafe under ieee rules
14:59mupuf: imirkin: lovely :D
19:22tacchinotacchi: I think you're the guys who are more fit to answering this question
19:23tacchinotacchi: are glsl's sin() and cos() single instructions on modern cpus?
20:05karolherbst: mupuf: is your network crappy or is it mine?
20:22karolherbst: gnurou: that's my current patch: https://gist.github.com/karolherbst/77c11d98293e77904aa76f8acb9b1083
20:22karolherbst: still doesn't work
20:37karolherbst: ohh, that nvkm_pmu_fini is for sure wrong