06:23 hmhm: hello. is the fan control supposed to work on NV110? poking around in /sys does nothing
06:23 hmhm: card is asus strix gtx 960 4GB
06:27 hmhm: im not quite sure the automatic mode is working either
06:28 hmhm: also, when i soft boot to win10 the card is stuck at drawing over 30W of power... normally it idles at about 1/3 of that
06:30 hmhm: im kind of worried the nouveau driver will fry the card.
07:01 gnarface: hmhm: i don't think reclocking works well on those cards
07:02 gnarface: my info may be out of date
07:02 gnarface: but i think you should probably just be happy the default power mode isn't the lowest one
07:26 hmhm: gnarface: thanks. low power is fine, i actually would prefer that ... but im after fan control here
07:26 skeggsb: we can't control fans on gm20x and above, nvidia prevents access to the necessary registers
07:26 skeggsb: only their cryptographically signed firmware can touch it
07:27 skeggsb: and they don't give us that fw...
07:28 hmhm: skeggsb: ok, gotcha. thanks
07:29 hmhm: someone might want to update the freedesktop.org wiki to reflect that as it currently gives the impression that you can do fan control on nouveau & NV110
07:29 skeggsb: gm206 isn't "nv110", it's "nv120"
07:29 skeggsb: gm20x*
07:30 hmhm: right - so is it supposed to work on nv110?
07:30 skeggsb: yes
07:30 hmhm: okay, for me it does not work. im wondering why
07:30 skeggsb: you have a gtx 960, which is gm206
07:31 hmhm: ah... my bad i guess
07:31 hmhm: from the wiki:
07:31 hmhm: NV110 GeForce 750, GeForce 900 Maxwell
07:31 hmhm: NV130 GeForce 1060, GeForce 1070 Pascal
07:32 skeggsb: yeah, that's a little misleading
07:32 skeggsb: they're both maxwell, but we call the gm20x "maxwell 2" because they're a bit different
07:32 skeggsb: ie. more locked down
07:33 hmhm: ah
07:50 hmhm: thanks for the assistance. keep up the good work.
14:40 rhyskidd: karolherbst: all the nvapy PRs have been rebased and should be ready to merge
15:47 pendingchaos: imirkin_: what does NVC0_IB_ENTRY_1_NO_PREFETCH do?
15:47 pendingchaos: (when used with nouveau_pushbuf_data)
15:47 imirkin: tells the fifo to not prefetch the ib ;)
15:48 imirkin: basically the fifo will prefetch commands before sending them off to the various units
15:48 imirkin: this doesn't play well with having an engine write something in
15:48 imirkin: so this is to tell it to not fetch until it's actually "there"
15:49 imirkin: this allows you to put in a stall into the fifo, like "wait for sequence >= N", and not have it read in the later commands
15:49 pendingchaos:nods
15:50 pendingchaos: what does the "IB" and 1 mean?
15:50 imirkin: indirect buffer
15:50 imirkin: fifo takes in a ring of buffer pointers
15:50 imirkin: (nv50+)
15:53 imirkin: prior to that you had to chain them with jumps inserted at the ends
15:53 imirkin: now it's just a bunch of (ptr, length) entries
15:54 imirkin: oh, and since an IB entry is 2 values, headergen generates NVC0_IB_ENTRY_0... and ENTRY_1...
15:54 imirkin: the size goes into entry 1. this is a bit of an abuse of the api.
15:55 pendingchaos: is that what nouveau_pushbuf_reloc is for?
15:55 imirkin: we SHOULD have some way to flag it, but ... we don't.
15:55 imirkin: relocs are for pre-nv50 stuff
15:55 imirkin: there was no vm
15:55 imirkin: so you'd tell the kernel to fill in the address of some object at pushbuf location N
15:56 imirkin: (also there was additional weirdness with whether the object was in vram or gart)
15:57 pendingchaos:nods
15:57 pendingchaos: thanks