01:50 pmoreau: skeggsb_: ping http://lists.freedesktop.org/archives/nouveau/2015-September/022308.html Do you have any concerns about this patch? Should it be tested on more machines, should I get more information about it?
01:59 hakzsam: pmoreau, btw, to fit with the nvkm_mask() style, I think the 'add' parameter should be renamed to 'value', but that's only a minor issue :)
02:00 RSpliet: pmoreau: go go go and run my kernel :-P
02:01 RSpliet: tracked down and fixed the GPIO issue, which should mean that higher perflvls now run at the right voltage
02:15 pmoreau: RSpliet: I don't have my laptop at work, but I'll definitely give it a try when I come back!! :-)
02:15 pmoreau: Cool!
02:21 RSpliet: great, thanks for being my guinea pig :-P
02:40 darlac: RSpliet: 0f seems to be stable on my nv96
02:42 RSpliet: that's great news! thanks
02:42 RSpliet: darlac: that
02:42 RSpliet: s using my tree? from when?
02:43 darlac: from today ;p
02:43 darlac: 0f: core 500 MHz shader 1250 MHz memory 400 MHz AC DC *
02:43 darlac: AC: core 500 MHz shader 1250 MHz memory 249 MHz
02:44 RSpliet: that's not my tree
02:45 RSpliet: and... is that a DDR2 card?
02:45 RSpliet: (in which case it might be my tree :-P)
02:47 RSpliet: darlac: my work so far has only been on GDDR3 cards, so... sorry to disappoint you, but since your memory is untouched you can't yet unleash the full potential of your card using nouveau
02:52 karolherbst: okay, yesterday after unloading nouveau my kernel crashed :/
02:53 mupuf: karolherbst: hmm, is that a new thing?
02:54 karolherbst: any ideas? https://gist.github.com/karolherbst/39a10196fdbf41c1dc36
02:54 karolherbst: mupuf: actually, it happens sometimes
02:54 karolherbst: maybe it was the third time in 2 or 3 months
02:54 karolherbst: this was inside pstore
02:55 paneidos: skeggsb_, imirkin: I filed a bug for the issue, bug number is 92178
02:55 mupuf: karolherbst: oh dear, it is linked to my code..
02:55 karolherbst: mupuf: which one?
02:55 mupuf: fan_update
02:55 karolherbst: ohh you changed gk104_fifo_intr?
02:55 mupuf: nope
02:55 karolherbst: ohhh
02:55 karolherbst: ther eis fan_update
02:56 karolherbst: maybe unload while fan update is a bad idea?
02:56 mupuf: well, there are multiple fixes that can be done
02:56 karolherbst: anyway, it totally crashed my kernel
02:56 mupuf: but first, one needs to understand the backtrace
02:56 mupuf: and it really makes no sense right now
02:57 karolherbst: want all the stuff from pstore?
02:57 mupuf: why would best_mask_cpu.isra call nvkm_fan_update?
02:57 karolherbst: it is a bit hard to read though
02:57 mupuf: Only ptimer should call nvkm_fan_update
02:57 mupuf: but maybe it got optimized away
02:57 karolherbst: mupuf: interrupt?
02:57 darlac: RSpliet: it is GDDR2 :(
02:57 karolherbst: don't know for sure, maybe kernel memory was corupted?
02:57 karolherbst: as I said: my entire kernel crashed
02:58 RSpliet: darlac: well, on the bright side it's stable, but I don't have a DDR2 card to develop this stuff myself, so I can't push this any further currently
02:58 RSpliet: sorry
02:58 karolherbst: "Kernel panic - not syncing: Fatal exception in interrupt"
02:58 mupuf:don't see why nvkm_fan_update would call gk104_fifo_intr too
03:00 karolherbst: mupuf: here is everything: https://gist.github.com/karolherbst/39a10196fdbf41c1dc36#file-gistfile1-txt
03:01 karolherbst: maybe something bad happend before
03:01 mupuf: sorry, can't do that now
03:01 karolherbst: okay
03:01 karolherbst: then I will try to figure it out
03:08 karolherbst: mupuf: the tesla card is a bit weird
03:08 mupuf: Tesla is weird
03:08 karolherbst: mhh it failed to change the pcie version
03:08 mupuf: it was a ton of experiments with power management
03:08 karolherbst: but max speed is 5.0
03:09 karolherbst: I hope I did something wrong :D
03:11 karolherbst: weird
03:11 karolherbst: I can't change the pcie version on that one
03:12 karolherbst: wow, crashed the card
03:12 karolherbst: that is, suprising
03:12 karolherbst: I only set the card to the pcie speed it was actually at already
03:13 karolherbst: as it seems, there is much more hidden fun than I actually thought there is
03:23 darlac: If i boot into kernel provided by distro and then kernel from RSpliet's tree - nouveau works, but if I boot into compiled kernel two times in a row, I have black screen :/
03:25 mupuf: karolherbst: ah ah
03:25 mupuf: I am sure there is!
03:26 darlac: dmesg http://pastebin.com/4YPzT4SA
03:29 karolherbst: mupuf: but I don't understand why changing to v2 fails, but 5.0 is reported max speed
03:30 karolherbst: PPCI.CONFIG_LINK => { UNK2 = 0 | TARGET_SPEED = 5_0GT | CARD_SPEED = 5_0GT | SYSTEM_SPEED = 5_0GT | UNK16 = 0x60 | UNK28 = 0x3 }
03:30 karolherbst: or this reg is wrong for tesla
03:30 karolherbst: but I doubt that
03:30 mupuf: did you read the pcie documentation?
03:31 karolherbst: partly
03:31 mupuf: is this reg in?
03:31 karolherbst: the nvidia cards are using own regs
03:32 mupuf: but they likely map to some extent to what the pcie spec says
03:32 karolherbst: no, the pcie spec is way to complicate, and the blob only does a few things
03:32 karolherbst: the pcie stuff seems to be implemented on the gpu actually
03:33 karolherbst: and you just tell the gpu what it should do
03:33 mupuf: ack
03:33 RSpliet: karolherbst: yes, nvidia probably only implements a subset of the spec
03:33 RSpliet: but it's informative nonetheless I found :-P
03:33 karolherbst: RSpliet: no, I meant the gpu implements it
03:33 karolherbst: not the driver
03:33 RSpliet: so did I
03:33 karolherbst: I see
03:34 karolherbst: there is so much you have to take care of, the traces aren't even close to what the pcie spec wants
03:34 karolherbst: trace: poke into 1 or 2 reg and you are fine: spec: before you actually thinking of changing speed, do a bunch of crap, so that you can do bunch of crap, so that you can prepare for speed change :)
03:34 RSpliet: keep in mind that the traces touch the "back side" of the PCIe registers
03:35 RSpliet: they are likely to have an influence on the front side (eg, the registers defined in the PCIe spec)
03:35 karolherbst: yeah
03:35 karolherbst: lspci does read the pcie regs out I think
03:36 RSpliet: yes
03:36 karolherbst: but I didn't went that deepd yet. I just do what the blob does and double check with parsed lspci output
03:38 karolherbst: mupuf: we were thinking if it would be possible to install some port triggers, so that ssh conect would power on reator :D
03:42 karolherbst: I don't want to trace the blob :(
03:44 karolherbst: fun
03:44 karolherbst: there are 8400 GS which doesn't support v2
03:44 karolherbst: okay, but why is 5.0 reported as max speed
03:46 karolherbst: at least I found something out: don't touch 0x88460 if you aren't in v2 mode
03:59 karolherbst: okay, also the vbios doesn't have any pcie speeds
03:59 karolherbst: seems like this card is v1 only
03:59 karolherbst: strange strange indeed
04:00 karolherbst: mupuf: okay, I would need another tesla card :)
04:00 karolherbst: mupuf: do you know which one you've got?
04:03 pmoreau: karolherbst: I'll be back home on Thursday evening, and then whole Friday. I have almost all Tesla 1st gen chipsets, and could plug and play with them if you want.
04:04 karolherbst: pmoreau: some of them are v2 for sure?
04:04 pmoreau: I have no idea about their PCI version
04:04 karolherbst: what means first gen tesla?
04:05 karolherbst: G8x?
04:05 pmoreau: [NV50-GT200[
04:05 pmoreau: So G8x and G9x
04:05 pmoreau: (+ MCP7x)
04:05 pmoreau: I should have a list somewhere
04:06 pmoreau: karolherbst: https://phabricator.pmoreau.org/P7
04:06 karolherbst: okay, nice
04:07 pmoreau: Didn't put much information in it, it was mostly for reclocking purposes
04:07 karolherbst: there seems to be only a few v2 teslas in the first gen then
04:07 karolherbst: ohh
04:07 karolherbst: sadly the chipset doesn't tell which pcie version is used
04:07 pmoreau: I'll have a look on Thursday night
04:08 karolherbst: so mupuf put a G86 in reator which is pcie v1
04:08 karolherbst: but reports 5.0 speed
04:08 karolherbst: I think the regs are pretty messed up on tesla
04:08 karolherbst: because if I do something to the pci config reg, the card crashes
04:08 karolherbst: as if it wouldn't be able to change pcie speed
04:09 pmoreau: karolherbst: If you could hack a script to extract all information you want about PCIe and paste somewhere, I'll happily run it once I get access to the cards.
04:09 karolherbst: pmoreau: do you know which g86 you have?
04:10 karolherbst: pmoreau: I don't know how to get the "maximum" supportec pcie version on tesla and fermi
04:10 karolherbst: even the blob just tries
04:10 pmoreau: Could it be a 8600 GS? Don't remember
04:10 karolherbst: and if it fails, it tries again
04:10 pmoreau: :D
04:10 pmoreau: bbl
04:10 karolherbst: and tries and tries whenever it changes perf level
04:15 karolherbst: seems like there is no G8x desktop gpu able to do v2
04:15 karolherbst: but a few mobile ones
04:16 karolherbst: pmoreau: any g9x would do
04:19 karlmag: Hmm.. would this be a good place go ask for buying advice for nvidia based graphics cards?
04:21 karolherbst: karlmag: only if you want to use nouveau :p
04:21 karolherbst: you could like ask for which chipsetyou would get the most perf currently with stock nouveau
04:23 karlmag: karolherbst: I do want to use nouveau, yeah.
04:26 karolherbst: karlmag: then any kepler card should do
04:31 karlmag: sorry, got called away
04:31 karlmag: back story; old hardware (mobo, etc) got blown up (litterally) by bad psu, so now I get a new, shiny mobo/cpu (i7) and kind of want something to match up with it a little.
04:32 karlmag: Only thing I know I want is a card that can drive 4 monitors
04:33 karolherbst: kepler can drive 4 monitors
04:33 karlmag: also, it would be nice if the purchase doesn't totally break the bank :-P
04:33 karolherbst: maybe not with nouveau, but that can be figured out then
04:33 karolherbst: as I said: anything kepler based
04:33 karolherbst: maybe first gen maxwell is also quite okay, but there are some recklocking issues left I think
04:33 mupuf: karolherbst: I would suggest not touching the reg on kepler cards and be done with it?
04:33 karolherbst: mupuf: which reg?
04:34 karlmag:looks at list of graphics cards on webshop and scratches his head :-P
04:34 karolherbst: any why kepler?
04:34 mupuf: the pcie speed
04:34 karolherbst: ohh I don't touch anything if pcie vesion is at v1
04:34 karolherbst: nouveau didn't crash the gpu
04:34 karolherbst: I was
04:34 mupuf: can you read the version?
04:34 mupuf: sure sure
04:34 karolherbst: yeah of course
04:34 mupuf: but why are you even trying?
04:34 karolherbst: what trying?
04:34 karolherbst: some cards are booting with v1
04:34 karolherbst: and are able to do v2
04:34 karolherbst: and only with v2 you can change pcie speed
04:35 mupuf: ok, how do you detect what version is supported by the gpu?
04:35 karolherbst: on kepler it is easy
04:35 mupuf: hopefully, we do not need to hardcode that
04:35 karolherbst: on tesla the blob tries
04:35 karolherbst: if you mask 0x1 0x1 in 0x154c on tesla
04:35 karolherbst: the 0 bit may stay 0
04:35 karolherbst: => only v1 supported
04:36 mupuf: why is it exposed in PFIFO?
04:36 karolherbst: it was moved for fermi
04:36 karolherbst: but for fermi it is in PUNITS
04:36 karolherbst: 0x02241c 0x1 0x1 on fermi
04:37 RSpliet: that's PBUS, not PFIFO
04:37 karolherbst: mupuf: also there is this nice reg on kepler: https://github.com/karolherbst/envytools/commit/31543f92ad87f13c85f5322f0605728b5228bdfb
04:37 karolherbst: but it is 0x8c1c0
04:39 karolherbst: there might be a bit in some reg for tesla/fermi though, but the blob doesn't seem to know what the actual max version is
04:39 RSpliet: arguably they know the max version of the chip, but not the motherboard
04:40 karolherbst: yes, it is PBUS.HWUNITS_1 in envytools
04:40 karolherbst: RSpliet: no, it is the chip they don't know either
04:40 RSpliet: of course they do, they made it :-P
04:40 karolherbst: why should they even try if they now in the first place?
04:41 e3b0c44298fc1c1: hey guys I just had a lockup, hard to reboot PC from reset button; http://pastebin.ubuntu.com/12611078/ this from dmesg, help?
04:41 RSpliet: because the motherboard may not support it?
04:41 karolherbst: why do they even try multiple times?
04:41 RSpliet: to keep the driver stateless?
04:41 karlmag: karolherbst: is there later than 1st gen maxwell out there? If so, how to recognize?
04:41 karolherbst: RSpliet: from one trace: https://gist.github.com/karolherbst/6a1e586170a18f208bd3
04:41 karlmag: sorry, I'm rather clueless on the matter
04:42 karolherbst: karlmag: GM10x is first gen
04:42 karolherbst: RSpliet: also they know that the system only supports 2.5
04:43 karolherbst: the gpu even knows
04:43 karlmag: i.e nothing one can read from tech details on a typical webshop...
04:43 karolherbst: karlmag: look it up
04:45 mupuf: RSpliet: ah, it makes more sense!
04:45 karolherbst: RSpliet: the painfull part is, that there are G86 with v1 support, and some with v2 support
04:46 karolherbst: same goes for g84
04:46 mupuf: karolherbst: the mobile versions support it?
04:46 karolherbst: yes
04:46 karolherbst: some
04:46 karolherbst: :D
04:46 mupuf: you can check if it is a mobile part in the vbios
04:47 karolherbst: quadro 570M is g84m with only v1 though
04:47 karolherbst: NVS 320M is g84m with v2
04:47 RSpliet: karolherbst: I would assume the chip just supports it regardless
04:47 RSpliet: and it depends on the motherboard whether it works
04:48 karolherbst: RSpliet: no, I am looking up the gpus directly
04:48 karolherbst: not the traces
04:48 karolherbst: there are jsut some g84 cards with v1 support and some with v2
04:48 RSpliet: what data do you use to conclude this?
04:48 karolherbst: of course the motherboard is important later, but the gpu knows what the slot supports
04:49 RSpliet: could there be a FUSE value that tells you this?
04:49 karlmag: so... going for anything gtx 960 should be "safe" then?
04:49 karolherbst: mupuf: I had such a discussion with mupuf or imirkin already where I began to throw nvidia spec pdfs at him :p
04:50 karolherbst: there are also v2 only kepler cards
04:51 RSpliet: right, but a chip is a chip is a chip, so unless support was added in a certain revision (the last byte of reg 0), there must be a way to disable it. Fuse (strap) are a likely candidate
04:51 karolherbst: may be yes
04:51 karolherbst: g84 is the first chip the blob tries to change the pcie version
04:55 karlmag:considers this; https://www.komplett.no/product/850779/datautstyr/skjermkort/pci-express/msi-geforce-gtx-960-4gb-armor-2x
04:55 karlmag: sorry, that page is in Norwegian
04:55 karlmag: http://www.msi.com/product/vga/GTX-960-4GD5T-OC.html#hero-overview
04:55 karlmag: that should be the same
04:56 karlmag: I'm guessing such cards really doesn't come with passive cooler :-P
04:56 karolherbst: 960 is second gen maxwell
04:57 karlmag: Probability of it working (w/3-4 monitors using nouveau) is fairly ok?
04:58 karlmag: Or is it a bit to early for them?
05:01 karlmag: karolherbst: or maybe I just misinterpreted something you said earlier (about maxwell gen 1, which made think "perhaps less probs with v2+")
05:09 karolherbst: RSpliet: anyway, I don't care that much about tesla pcie speeds, that I really want to figure all the depths out. As long as nouveau don't crash the cards, and it works for some, it should be fine
05:09 karolherbst: anyway, I don't do anything the blob does not
05:14 pmoreau: karlmag: gen 2 Maxwell (GM20x) brings more problems regarding Nouveau, as it requires firmware signed by Nvidia for 3D acceleration, fan management and some other stuff
05:15 pmoreau: karlmag: Nvidia is supposed to release those signed firmware so that we can use them, but we're still waiting for it
05:17 karlmag: pmoreau: right... so I guess "no" then, basically
05:21 pmoreau: Right now, you should go for gen 1 Maxwell, or Kepler
05:21 karlmag: http://www.gigabyte.com/products/product-page.aspx?pid=4948#ov so.. that one is kepler, right?
05:22 pmoreau: But if you're hopeful and don't need 3d acceleration right now, you could still get a gen 2 Maxwell :-)
05:22 karlmag: I don't *need* it per se.
05:23 karlmag: But also I would like something that mostly would work.
05:23 pmoreau: It's a GM107 apparently, so gen 1 Maxwell
05:23 karolherbst: karlmag: everything from 9xx is gen2 maxwell
05:23 karlmag: ok, right..
05:23 karolherbst: 7xx is either kepler or gen1 maxwell
05:24 karolherbst: (or fermi)
05:24 pmoreau: 9xx yeah, but not for 9xxM
05:24 karolherbst: yeah, but he wants a deskotp gpu,
05:24 pmoreau: Apparently 920M is either GF117 or GK208... --"
05:24 karlmag: I just love how they're making it easy to distinguish (not)
05:25 karolherbst: I don't know how the gddr5 situation is on maxwell though
05:25 karolherbst: maybe my patch works there, maybe not
05:25 karolherbst: I think it did on reator, but that was maybe luck or something
05:25 pmoreau: No idea... And I have no 1st gen Maxwell to test on
05:25 karlmag:hits his head on the desk...
05:26 karolherbst: karlmag: titan should run fine though
05:26 pmoreau: :D
05:26 karlmag: karolherbst: well... I belive I saw the prices for those...
05:26 karlmag: so.. uhm.. no... :-P
05:26 karolherbst: then go with any 760 or 750
05:26 karolherbst: ohh wait
05:26 karolherbst: no 750
05:27 karolherbst: 760
05:27 karolherbst: 750 is gen1 maxwell
05:27 karolherbst: and reclocking is in a not that good shape
05:27 karlmag: "breaking the bank" <- hope not to..
05:27 karolherbst: 760 is fine
05:27 karolherbst: starting at 220$?
05:27 karolherbst: don't know
05:28 pmoreau: 760 are starting at 220$? Really?
05:28 karolherbst: gddr5 740 is also alright
05:28 karolherbst: pmoreau: don't know
05:28 pmoreau: Isn't that the price tag of 960?
05:28 karlmag: titan series
05:28 karolherbst: uhhh
05:28 pmoreau: Oh, ok
05:28 karolherbst: checking
05:28 pmoreau: I bought my 960 for ~200 euros
05:28 karolherbst: ohh 170€
05:29 karolherbst: GTX 960
05:29 karolherbst: pmoreau: everything above x60 isn't that unstable in price
05:29 karolherbst: they don't drop as fast as the lower gpus
05:30 karolherbst: wait ....
05:30 karolherbst: I checked 960
05:30 karolherbst: stupid me
05:30 karolherbst: 760 starting at 170€ :D
05:30 pmoreau: yeah apparently...
05:30 karolherbst: as it seems 760 is more expensive
05:30 karolherbst: karlmag: how much do you want to pay?
05:30 karlmag: I've been looking at this webshop (referred to earlier). They have 83 nVidia cards with 2GB or 4GB ram...
05:31 karolherbst: karlmag: 4 display ports?
05:32 karlmag: yeah, that's the main thing
05:32 karolherbst: 650 Ti
05:32 karolherbst: asus 660 also has 4 ports
05:32 karolherbst: plait 650 Ti
05:32 karolherbst: the plait is at 130€
05:33 karolherbst: 2 dvi, hdmi, dp
05:33 karolherbst: karlmag: https://geizhals.eu/palit-geforce-gtx-650-ti-boost-ne5x65b01049-1060f-a923157.html
05:33 karlmag: price.. well.. when you go past around 250 euros it's about time to stop thinking.. Less is good, of course
05:34 karolherbst: this one is 133€
05:34 karolherbst: there is also a 1GB vram version, but well
05:34 karolherbst: why buy 1GB if 2GB costs like 5€ more
05:35 karlmag: karolherbst: well.. I'd rather get one locally (as in Norway), both due to warrenty laws and also import charges
05:35 karolherbst: of course
05:35 karolherbst: but now you know a model ;)
05:35 karolherbst: karlmag: I usually use this site to search for special stuff: https://geizhals.eu/?cat=gra16_512&xf=6680_7~3082_4~143_PCIe+3.0+x16~653_nVIDIA
05:36 karolherbst: you can filter there pretty good and find what you need
05:36 karlmag: https://www.komplett.no/category/10412?sort=Price%3AASCENDING&subcategory=10488_PCI%20Express&cnet=Grafikkprosessorfabrikant_A03616%20%20%C2%A7NVIDIA&cnet-A00241-queryfacet=[2047483648%20TO%202247483648]&cnet-A00241-queryfacet=[4194967296%20TO%204394967296]&hits=96 this list is what I have been looking at
05:36 karolherbst: karlmag: do you have a pcie v3 motherboard?
05:36 karolherbst: mhhh
05:36 karlmag: wow.. that was an fugly URL, sorry
05:36 karolherbst: without filters such a list kind of useless :/
05:37 karlmag: karolherbst: yeah... the filtering sucks a bit there..
05:37 karolherbst: you should check the url
05:37 karlmag: I've told them too
05:37 karolherbst: you will see what I mean
05:38 karolherbst: just sort by price and you are good to go
05:39 karlmag: https://www.asus.com/us/Motherboards/X99AUSB_31/ motherboard will be that one.
05:39 karlmag: I say "will be", because I haven't gotten it yet
05:40 karolherbst: so much site, so less information :/
05:40 karolherbst: but the main pcie slot mainly depends on the cpu anyway
05:44 karlmag: the CPU I'm getting is a 28-lane one so... "3 x PCIe 3.0/2.0 x16 ( x16, x16/x8, x16/x8/x4)"
05:45 karlmag: and also "1 x PCIe 2.0 x16 (x4 mode)" + "2 x PCIe 2.0 x1 (x1 mode)"
05:48 karolherbst: mhhh
05:50 karlmag:ponders if he should just give up on new graphics card for now and get one at some later point instead.
05:54 karolherbst: for 130€ it is quite okay
05:54 karolherbst: it is not like you can't sell it for at least 60€ 2 years later
05:54 karlmag: "just" have to find it around here :-P
05:55 karlmag: meh.. too many browser windows and -tabs... loosing track :-P
06:01 karlmag: looks like I'm finding gtx650 Ti boost cards on other webshops.. but price difference to the v1 maxwell (gtx750Ti) I found earlier is in the eur10-20 range..
06:01 karlmag: Maybe cross fingers and go for that instead
06:01 karolherbst: 650 ti is kepler for sure
06:01 karolherbst: and as long as it has 4 ports you should be fine
06:01 karolherbst: you need my gddr5 patch if you want to go to 0f though
06:04 karlmag: there is that too I guess
06:41 karolherbst: mupuf: at least version upgrade works on the fermi card
06:44 karolherbst: okay, pcie patches are working on the fermi card :)
07:13 karolherbst: ohhh we don't have any g80 traces
07:16 karolherbst: I somehow doubt that any g8x card can actually do 2.0, so maybe I disable the pcie speed stuff for those
07:32 glennk: karolherbst, fairly sure g80 is all pcie 1.x
07:33 glennk: g92 is 2.0
07:44 mupuf: karolherbst: I have two g80, one of which is a tegra
07:45 mupuf: err, quadro
07:45 karolherbst: I highly doubt now that any g8x is pcie v2
07:45 karolherbst: g9x would be ebtter
07:45 mupuf: so if there is one supporting v2, it would be the quadro
07:45 karolherbst: mhh
07:45 mupuf: in any case, do not prioritize old gpus :)
07:45 karolherbst: closer investigation didn't how anything
07:46 karolherbst: mupuf: I am done with fermi+ already :D
07:46 mupuf: really? Did you post the patches?
07:46 karolherbst: worked nicely on your fermi
07:46 mupuf: I can have a look at them tonight
07:46 karolherbst: not yet
07:46 karolherbst: still thiking about stuff
07:46 karolherbst: they are on my pcie_speed branch though
07:46 mupuf: ok
07:46 karolherbst: newest stuff will be always there
07:46 mupuf: I will have a look at it tonight
07:47 karolherbst: tanks
07:47 karolherbst: *thanks
07:47 karolherbst: for fermi the recklocking stuff has to be tweaked a little though
07:47 karolherbst: otherwise you can't change pstates
07:47 mupuf: don't accumulate too much code before upstreaming, it will be a pain for you to rebase it constantly and you may have to rewrite a lot of code along the upstreaming process
07:47 karolherbst: I use own source files anyway
07:47 karolherbst: added a pcie.c file
07:48 karolherbst: and some pci subdevs
07:48 karolherbst: there is nothing in there except pcie_rearm
07:48 karolherbst: so there is nothing to rebase that upon anyway
07:51 karolherbst: mupuf: anyway, I think parsing the vbios has an issue there somewhere
07:51 karolherbst: nvbios prints 8.0 for both your, and mine fermi
07:56 karolherbst: ugh, +830 loc :/ okay, it is more than I thought it would be
08:10 imirkin: karlmag: as others here suggested, kepler is really the way to go nowadays
08:10 karlmag: imirkin: yeah, I guess I concluded with that too.
08:11 karlmag:tries to find a magic wand to make the situation better. (clue-by-four to nvidia, perhaps? :-P )
08:13 karlmag: I guess I'll think about it for a day or two.
08:14 karlmag: the kind of sad thing is the price difference between a kepler and a maxwell v1 is almost neglectable. And the price jump up to v2 isn't extremely bad either..
08:21 karolherbst: karlmag: maxwell v1 isn't that bad, mupuf I could take a look at maxwell gddr5 though, but do you know in which state it is currently?
08:22 pmoreau: karolherbst: Didn't you had a try at reclocking it? Or was it mupuf?
08:22 karolherbst: I did, but I am not sure about the result actually
08:22 imirkin: maxwell v1 is bad.
08:22 pmoreau: :D
08:22 imirkin: it doesn't work.
08:22 imirkin: don't get one.
08:23 karolherbst: pmoreau: do you have a maxwell?
08:23 mupuf: imirkin: it does not work? You talk about reclocking or 3d rendering in general?
08:23 pmoreau: karolherbst: A 960 at home, which is not long to fit in my current desktop case
08:23 mupuf: ben said that we do not parse the clock tree as expected
08:23 imirkin: mupuf: i talk about 3d rendering in general, and there's no completed EXA impl, so there's no 2d rendering either.
08:23 mupuf: ack
08:24 pmoreau: s/not/too
08:24 imirkin: i mean it obviously kinda-sorta works. but nowhere near reliable. glamor barely functions.
08:24 karolherbst: I thought that the 0f pstate didn't crash the maxwell card on reator
08:24 karolherbst: but I don't know if the memory was clocked up
08:24 karolherbst: if at least the PLL configuration is the same like on kepler, maybe it works with my patch too?
08:24 mupuf: karolherbst: yeah, we did suceed in reclocking the gpu ... but it may not be set to the clocks we intended to :D
08:25 karolherbst: ohh maxwell just used the kepler functions for ram
08:26 karolherbst: and the fermi ctor? :/
08:27 karolherbst: ohh well
08:28 karolherbst: yeah don't know, would have to check about it
08:28 karolherbst: but I know that either ram reclocking or core reclocking doesn't work at all with maxwell
08:28 karolherbst: maybe both, maybe I am not sure about anything maxwell related either :D
08:30 karolherbst: mupuf: what bothers me a little, fermi seems to adjust the lnkCap speed to the lnkSta speed, where kepler just keeps lnkCap at max and only changes lnkSta speed :/
08:30 karolherbst: I mean the blob does it this way, but I don't know why
08:31 mupuf: for fun!
08:33 karolherbst: :O
08:33 karolherbst: microsoft help is helpful :O
08:33 karolherbst: ULONG PortNumber :8; <===
08:33 karolherbst: yeah why not
08:33 karolherbst: maybe the gpu tells us the port in which it is currently
08:41 karolherbst: does anybody with a g90+ gpu and two pcie slots do the following? nvapeek 0x88000 0x1000 and if it is kepler+ also nvapeek 0x8c000 0c1000 for both or all slots?
08:41 karolherbst: there should be obviously some changes
08:42 karolherbst: mainly width, but maybe there are other differences too
08:42 mlankhor1t: hmz..
08:42 mlankhor1t: 0c1000 ?
08:42 karolherbst: ohh
08:42 karolherbst: 0x1000 :)
08:42 mlankhor1t: 2 pci-e slots? do you mean double width?
08:42 mlankhor1t: or connected to 2
08:42 karolherbst: no, two or more slots where the gpu fit into
08:42 karolherbst: do the peek in one
08:43 karolherbst: power off computer, change slot, power on, peek again
08:43 mlankhor1t: oh that..
08:43 mlankhor1t: i wish I could right now :(
08:43 karolherbst: I only ha ve a laptop so I can't do that :D
08:43 karolherbst: and I never did this before
08:43 karolherbst: might tell us something
09:36 Yoshimo: i found an old card with the label GTX275, does anyone know which codename that equals?
09:37 imirkin: G200 probably
09:39 Yoshimo: NVA0 finally found the wiki entry ;)
09:39 imirkin: yes, which is G200
09:40 imirkin: you should even have reclocking on that one in 4.3-rcN
09:40 Yoshimo: karolherbst: i even found a card that might be usefull ;)
09:52 pmoreau: RSpliet: Building time! :-)
10:40 pmoreau: RSpliet: It is better: I don't get a grey background in glxgears, and it always displays the gears.
10:40 pmoreau: RSpliet: But, GR is still unhappy, and I get some random blue pixels all over the screen (most likely GR being unhappy), and the display will still freeze after a few secs of glxgears
10:41 pmoreau: It could be, though, that reclocking is working, but that it's uncovering some hidden bug somewhere else.
10:41 imirkin_: most likely fb being unhappy actually
10:44 pmoreau: https://phabricator.pmoreau.org/P38
10:45 pmoreau: https://phabricator.pmoreau.org/P39 This one has the error messages thrown by glxgears
10:45 pmoreau: The previous one only had the one from starting X.
10:56 yoshimo: on my Kubuntu with a gtx275 right before the loading progress bar appears there are some square artifacts visible, didn't have them with a fermi and a maxwell so far
10:56 imirkin_: what version of mesa?
10:57 imirkin_: i fixed a bunch of bugs in mesa 11
10:57 imirkin_: either way, if you can create an apitrace capture of the issue (whereby the issue is seen on replay) please open a bug
10:58 yoshimo: mesa is at 11
10:59 imirkin_: perhaps i broke stuff in mesa 11 too ;)
11:00 yoshimo: tracing the login , sounds like a challenge
11:01 imirkin_: yeah, those things are a huge pain
11:22 RSpliet: pmoreau: I still see no fiddlings with GPIO in your trace :s
11:23 RSpliet: what's the default value of e104 and e108?
11:26 RSpliet: wait, I can look that up myself probably :-P
11:46 RSpliet: pmoreau: this might sound a bit extreme, but please invert all requested GPIO signals in nvkm/subdev/fb/ramnv50.c: line 283 0->1, line 323 add an !, line 401 1->0
11:52 karolherbst: does anybody of you have experience with splash screens while not using any initramfs?
11:53 imirkin_: what does initramfs have to do with it?
11:53 karolherbst: usually so far everything I encountered required initramfs
11:54 karolherbst: maybe I am just stupid configuring it the right way
11:57 karolherbst: but as long as drm and the device driver is built in the kernel it should be fine I assumed, so yeah I even don't know why it shouldn't be possible
11:58 imirkin_: how does it know if it's initramfs or not?
11:58 imirkin_: what's the diff between initramfs and regular init?
12:01 karolherbst: I think because it wants to run before actuall init is started (or as the first action done by init)
12:01 karolherbst: before mounting stuff or anything
12:07 pmoreau: RSpliet: Indeed, it does sound a bit extreme. :-)
12:07 pmoreau: RSpliet: I'll do that in a couple of minutes. Still need the default data for e104 e108?
12:08 pmoreau: Could be that the VBIOS does not initialise them, or that they are different from the ones on your card: remember my laptop thinks different for quite a few things. ;)
12:36 cjb: Hi! Got a GTX 960, getting "failed to load {nv126_fuc409c,fuc409c}", the firmware packages don't seem to have this one in yet. Any options?
12:37 imirkin_: cjb: use the nvidia proprietary driver
12:37 imirkin_: cjb: GM20x isn't supported beyond modesetting by nouveau
12:39 cjb: imirkin_: aw. okay, thanks
12:40 cjb: I tried using the binary driver with a 5K monitor and getting a black screen, but y'all can't help with that :)
12:40 imirkin_: did you hook it up over DP?
12:40 imirkin_: fwiw modesetting should work with nouveau
12:40 imirkin_: just no acceleration
12:40 imirkin_: although i'm not aware of anyone having tried a 5k monitor with nouveau
12:42 cjb: yeah, 2x DP
12:42 imirkin_: oh wow
12:42 imirkin_: yeah there's no way that'll work with nouveau :)
12:43 cjb: I managed to get the binary driver to see it as two separate 2560x2880 displays, which it is
12:43 cjb: but then asking it for Xinerama across both of them black screens
12:43 imirkin_: well.... you don't want xinerama
12:43 imirkin_: you want to use TwinView
12:43 cjb: ooh
12:43 imirkin_: good luck :)
12:47 cjb: huh, it just started working, though with a unity panel down the middle of the screen that the mouse snaps to
12:47 imirkin_: make the other monitor the primary
12:48 imirkin_: Option "TwinViewXineramaInfoOrder"
12:49 cjb: I have a feeling that if I restart X, everything's going to fall over
12:49 imirkin_: seems likely
12:51 cjb: hm, windows span the whole display fine, it's just a panel in the middle
12:53 imirkin_: right
12:54 imirkin_: flip the xinerama order
12:54 imirkin_: and the panel will be on the right screen
13:02 cjb: I switched from unity to gnome-shell and now everything's cool
13:02 imirkin_: maybe unity doesn't respect xinerama hints
13:02 cjb: I think the Xinerama order was correct, or at least changing it didn't do anything. but gnome-shell's fine with me so I'll stick with this for now. Thanks a bunch!
13:02 imirkin_: np
13:02 imirkin_: you could also physically switch the monitor cables
13:03 imirkin_: that'll likely force unity to move
13:05 pmoreau: RSpliet: I don't seem to have the same line numbers as you... Could you paste the lines somewhere maybe?
13:15 mupuf: skeggsb_: the patch of Ondrej contains a typo: PCI_VENDOR_ID_SI instead of SIS
13:16 imirkin_: mupuf: not a typo
13:16 mupuf: imirkin_: hmm, how so?
13:16 imirkin_: mupuf: git grep PCI_VENDOR_ID_SIS
13:17 mupuf: ah, I see
13:17 imirkin_: now repeat without the trailing S :)
13:17 mupuf: well, the original made the typo then :p
13:17 hakzsam: mupuf, could you please update the kernel on reator because we can't build nouveau anymore ?
13:18 mupuf: ok
13:18 hakzsam: soc/tegra/fuse.h is not found
13:18 hakzsam: thanks
13:21 mupuf: hakzsam: are you sure you are not using the blob's partition?
13:21 mupuf: because drm-next has not been updated since I last recompiled it
13:21 hakzsam: mupuf, how can I check that?
13:21 mupuf: uname -a
13:21 hakzsam: 4.1.6
13:21 hakzsam: ok blob partition I guess
13:22 mupuf: 4.2.0-rc8-NV+ --> this is the nouveau partition
13:22 mupuf: I wonder why grub-reboot became permanent
13:22 hakzsam: yes, because I didn't use it the last time I rebooted
13:23 mupuf: well, maybe someone used grub-set-default 2
13:23 hakzsam: I always use grub-reboot
13:24 hakzsam: mupuf, I'm still on the blob partition after grub-reboot 0 && reboot...
13:25 mupuf: ok, type reboot, let me check
13:25 hakzsam: ok
13:28 imirkin_: let's see if blob fw magically makes atomics work
13:29 rektide2_: is the NVidia Shield TV with it's X1 processor at all useable in Nouveau? Also the new Pixel C tablet has this proc.
13:30 imirkin_: rektide2_: not today... maybe eventually
13:30 rektide2_: i asked a couple weeks back, someone was in channel trying to get some mode-setting out of it at that very moment
13:31 imirkin_: out of X1?
13:31 imirkin_: the display unit is separate from novueau... presumably still the same tegra stuff
13:31 imirkin_: tagr_ is the one to talk to about that
13:32 imirkin_: the X1 gpu just does 3d accel, which will potentially be supported by nouveau
13:32 imirkin_: but like all the other GM20x chips it requiers secure signed firmware to boot up
13:32 rektide2_: or some such boot-up feat. it was karolherbst. " currently figured out how to set voltage a bit", august 12
13:32 imirkin_: but unlike the other GM20x gpu's, the nvidia guys (specifically gnurou) are actively trying to make that work upstream
13:32 rektide2_: my mistake
13:32 rektide2_: bad recall on my part
13:32 imirkin_: that bit was most definitely not related to anything you care about
13:33 rektide2_: what do i know? it sounded like part of the road to progress. way cool that nv is helping with this lift some.
13:34 imirkin_: they're helping with the tegra chips only... i assume google's leaning on them
13:34 rektide2_: err should have put some :) faces in there somewhere or something to lighten that up
13:35 rektide2_: this secure bios situation sounds fairly dire
13:35 rektide2_: i was under the impression nv had turned the leaf, that they got tired of being linus's whipping boy
13:37 imirkin_: from what i've heard is that it's based around some sort of windows security requirement
13:37 imirkin_: but they've gone way overboard and in a completely illogical fashion
13:38 imirkin_: they might be using it as an excuse to clamp down on people reselling boards with fake vbios's that convince drivers they're some higher gpu
13:38 karolherbst: I don't really think secure boot actually can do anything about device firmware anyway
13:38 karolherbst: because in the end, the device can always fake the vbios it "exports"
13:38 imirkin_: well, everything has to be signed
13:39 karolherbst: imirkin_: actually I had a ati card for my mac once with that problem
13:39 imirkin_: which makes it harder to fake things
13:39 karolherbst: reflashed windows gpu
13:39 karolherbst: imirkin_: yeah but example for hdds, when the bios got overwritten you are screwed
13:39 karolherbst: secure boot won't help here
13:40 rektide2_: this is a perfect case study for the FCC which is mandating wifi hardware not operate out of band
13:40 karolherbst: which is a total stupid idea anyway
13:40 imirkin_: nooooope, blob firmware doesn't magically make atomics work
13:40 imirkin_: that was a bit wishful
13:41 karolherbst: rektide2_: also both cases (nvidia firmware, and router software) are totally different
13:43 glennk: imirkin_, sounds similar to the GS issues on evergreen :-(
13:43 imirkin_: glennk: but.... i'm SOOO CLOSE!
13:43 imirkin_: i can *taste* atomics
13:43 imirkin_: heh
13:44 glennk: GS even works on r6/r7xx which are the buggiest gpus known to man :-(
13:44 imirkin_: there are some firmware calls the blob does... i'm fairly sure they're unrelated but i'll throw them in for good measure
13:44 imirkin_: glennk: but not R600 i assume ;)
13:44 glennk: we... don't talk about R600 :-)
13:45 imirkin_: "well it *seemed* like it was going to work"
14:03 karolherbst: mupuf: if you still want to look at my pcie patches, the "implement generic code" is the most important one, if there is something seriously wrong, I have to change all the others as well ;)
14:20 mupuf: karolherbst: well, I spent some time with hakzsam to fix an issue with perf counters on fermi
14:20 mupuf: and now, i am working on my finnish before going to bed
14:20 karolherbst: no problem
14:20 mupuf: tomorrow's class is going to be funky
14:20 karolherbst: :)
14:20 karolherbst: I always had a question about those fancy perf counters
14:21 karolherbst: will it be possible to get the current core/memory/pcie load with them?
14:21 mupuf: Iwill be on vacation from thursday to wednesday
14:21 mupuf: I will be travelling around france, so I should have time to spend on nouveau but may not have the internet connection at all time
14:22 karolherbst: no problems. The pcie work has low priority anyway, and I still want to find hardware which is unhappy about those
14:22 mupuf: yes, it will be possible
14:22 mupuf: but hakzsam's work is not for those counters
14:22 mupuf: although they would allow you to get the same info
14:22 mupuf: but pmu/pdaemon has counters dedicated for that
14:22 mupuf: 10a500
14:22 karolherbst: I think I found them once
14:22 karolherbst: but they have to be activated right?
14:23 mupuf: activated?
14:23 mupuf: you need to program them
14:23 mupuf: and then poll them periodically
14:23 karolherbst: ohhhh
14:23 karolherbst: I see
14:23 karolherbst: how "hard" would it be? because I really would like to have that information
14:23 mupuf: nvidia does it at 1 Hz on the lowest perf setting
14:23 mupuf: and 10 Hz on the others
14:24 karolherbst: mhh okay
14:24 mupuf: my script to dump everything should already poll them
14:24 karolherbst: what do I have to look for to find out how to program it the right way?
14:24 mupuf: if you want to do it on nouveau
14:24 karolherbst: yeah it works on the blob
14:24 karolherbst: yeah
14:24 mupuf: I wrote a userspace program once for nvidia
14:24 karolherbst: I want that for nouveau
14:24 mupuf: that allows you to switch the performance level based on the load
14:24 skeggsb_: the gk20a pmu implementation in nouveau already uses the pmu perf counters, which you could use as a reference
14:25 karolherbst: ahhh okay
14:25 karolherbst: is it in the pmu subdev?
14:25 mupuf: skeggsb_: and we have the kernel side for that?
14:25 skeggsb_: karolherbst: yes
14:25 skeggsb_: mupuf: hm?
14:25 karolherbst: skeggsb_: if you want, you can also have a look on my pcie stuff, it should be ready for tesla+ gpus up to maxwell gpus
14:25 skeggsb_: karolherbst: yeah, i have that on my list, as well as merging your pll patch
14:26 karolherbst: nice :)
14:26 mupuf: skeggsb_: who is doing the polling? The blob or pmu?
14:26 karolherbst: allthough I doubt that for desktop it makes a big difference, but for my gpu it does a really big one
14:26 skeggsb_: mupuf: the host is polling for some reason, not sure why they didn't use the pmu ucode's implementation like they do on nvgpu
14:26 karolherbst: skeggsb_: 0f is stock 0f, 0f+ is 0f with pcie at 8.0: https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
14:27 skeggsb_: fuck me, people will love the glxhears boost :P
14:27 karolherbst: :D
14:27 skeggsb_:bets on a phoronix article
14:27 karolherbst: DRI_PRIME
14:27 mupuf: skeggsb_: we need to ask them if that's what they plan on doing from now on, if so, we can add support for the business counters super quickly!
14:28 imirkin_: skeggsb_: well, it's a 25% boost in a few games too
14:28 imirkin_: skeggsb_: which isn't bad for a handful of register writes
14:28 mupuf: agreed
14:28 skeggsb_: mupuf: i'd have done it already if i though there was any point, not like we can make any kind of sane use of them until we can actually change clocks properly
14:28 skeggsb_: thought*
14:28 mupuf: well, I am apparently about to receive my K1
14:29 skeggsb_: imirkin_: yeah i know, but hears really stands out, i'm sure that'll be the focus given the quality of phoronix articles ;)
14:29 mupuf: and this will be the platform that I will focus on to finish power management
14:29 skeggsb_: mupuf: gk20a already does automatic reclocking in nouveau
14:29 imirkin_: i care a lot more about what end users see than what the phoronix comments are, tbh
14:29 karolherbst: skeggsb_: stuff like glxgears and glxspheres are capped because of texture transfers between the gpus
14:29 skeggsb_: imirkin_: i know ;)
14:29 mupuf: skeggsb_: oh, I missed it! I remember helping one nvidia engineer to get it working, but I thought the efforts did not pay off! Good to hear!
14:30 mupuf: I wrote a userspace version of it to help the engineer get started
14:30 mupuf:did not sleep-enough this night because of it
14:30 mupuf: but anyway, there is still the need for power and clock gating
14:31 mupuf: and we apparently have enough doc for it, and it will require quite a lot of work to get well integrated
14:31 skeggsb_: our pmu needs a lot of work to make all those gating methods possible :P
14:31 mupuf: the plan is still to change our interface to copy the blob's?
14:32 skeggsb_: i suspect in the end it'll be something like that, but who knows
14:32 skeggsb_: would make things simpler, going forward
14:33 mupuf: I have been holding on any kind of pdaemon work because of this
14:33 imirkin_: skeggsb_: are you aware of any PTE flags that need to be set for e.g. compute to work?
14:34 imirkin_: [i mean for resources to be useable in shaders]
14:34 skeggsb_: kinda waiting on nvidia for info on the interfaces... however, i guess we could probably scare up some kind of approximation for the features we currently use
14:34 skeggsb_: imirkin_: not that i *know* of
14:34 skeggsb_: gk20a nvgpu will likely hold the answer to that, they support compute
14:34 mupuf: skeggsb_: yep, same here for the interfaces
14:37 hakzsam: skeggsb_, I think you already know that "nvif: replace path-based object identification" breaks contexts creation from mesa? because I just bisected that commit while trying to use mesa and nouveau HEAD :)
14:37 imirkin_: skeggsb_: any ideas off hand about where i should for why i get memory-ish errors when trying to access gmem from shader?
14:37 imirkin_: skeggsb_: i tried using blob ctxsw fw, and doing the FIRMWARE calls that they do
14:38 skeggsb_: hakzsam: breaks context creation?! how?
14:38 skeggsb_: mesa seems to be working here..
14:38 imirkin_: hakzsam: i've been using ben's tree for a while, worksforme as well on a GK208
14:38 skeggsb_: are you using the hacked up libdrm with patches that never got merged still?
14:38 skeggsb_: because, that'll break
14:38 hakzsam: skeggsb_, http://hastebin.com/jiguzuzodo.vbs
14:39 hakzsam: skeggsb_, nope, I don't think I use them
14:39 hakzsam: I will check again
14:39 skeggsb_: imirkin_: good, because it worked for me on everything from nv4 to gm10x ;)
14:39 imirkin_: skeggsb_: wow you tried an nv4?!
14:39 skeggsb_: hakzsam: i got bitten by that during initial testing, i had a stale libdrm laying around that was getting used accidentally
14:39 imirkin_: impressive. i only have an nv5 :)
14:40 skeggsb_: imirkin_: well, nv5, but close enough
14:40 imirkin_: ah
14:40 imirkin_: iirc there were some surprising differences in the code between them
14:40 imirkin_: something pll-y as i recall
14:40 skeggsb_: and nv4 doesn't do a lot of methods in hardware
14:40 skeggsb_: you can set some gr debug bits to emulate that part on nv5 too
14:40 skeggsb_: .. which i didn't actually do, because i forgot..
14:41 imirkin_: hehe
14:41 imirkin_: well it's hopefully documented
14:41 skeggsb_: mwk documented it pretty well when he wrote the swmthd implementations
14:47 hakzsam: well, works fine but it's pretty strange because I did 'make distclean' before re-building mesa without those libdrm patches... sorry for the noise
14:47 derstrom: Hi. I have installed Debian 8 running on a system with a GeForce GTX 750 Ti (NV117). I'm stuck at 1280x1024 resolution and I'm not sure what I need to do to get the microcode/firmware I need for Nouveau to work properly.
14:50 imirkin_: derstrom: you need at least kernel 3.19 for modesetting to work, and 4.1 for acceleration
14:50 imirkin_: derstrom: also iirc debian has a habit of force-disabling modesetting on nouveau (which nukes the driver)
14:50 imirkin_: but i'm not sure -- i don't actually use it
14:51 imirkin_: derstrom: also if you're using displayport, there are a bunch of fixes in 4.3-rcN which should help you
14:51 derstrom: Ah right :-(. Debian stable is at 3.16.x. I doubt 4.x will be on Debian stable until 9.0 is out
14:52 karolherbst: imirkin_: I think it gets disabled when you installed with nomodest
14:52 imirkin_: derstrom: ah ok. well, 3.16 was released probably before the GTX 750 came out
14:52 imirkin_: er hm
14:52 derstrom: Should I be surprised things even work? :)
14:52 karolherbst: like if the installer has a too old kernel and "safe" mode is the only thing which works
14:52 imirkin_: actually 3.16 may have had modesetting for GM107
14:53 imirkin_: derstrom: well, you're probably just using the vesa driver. expected that it works and gives you a 1280x1024 resolution.
14:54 derstrom: I guess the only choice is not to use Debian. Thank you for your help.
14:54 karolherbst: skeggsb_: regardin clock gating: I was able to reduce my gpu power consumption by over 10% in idle with some clock gating reg writes
14:54 imirkin_: you could use debian but grab a newer kernel...
14:54 karolherbst: but it wasn't close enough to what the blob does (but I didn't touch any power gating stuff)
14:54 imirkin_: derstrom: looks like modesetting for gm107 was merged into v3.15
14:55 imirkin_: derstrom: so... sounds like you probably have nouveau disabled
14:55 karolherbst: and because there isn't much more on my list for my gpu, I planned to look into that deeper if nobody else wants to do that
14:57 derstrom: imirkin: I've tried looking into this but I'm not sure how to enable modesetting. Is it a boot parameter I need to add?
15:00 karolherbst: derstrom: remove nomodeset ;)
15:04 imirkin_: whoa! no more gr fail on kepler! it just plain doesn't work now. yay?
15:05 imirkin_: IMMED_NVC0(push, SUBC_3D(0x1528), 0);
15:05 imirkin_: interesting.
15:08 Boohbah: oh, i have a patch to try! :)
15:10 imirkin_: i wonder if it's a vram vs gart thing?
15:11 derstrom: I have checked /etc/default/grub and tried enabling modesetting with modprobe. Restarted X and I still have the same problem as before.
15:11 imirkin_: nooope. all vram.
15:11 imirkin_: grrr
15:11 imirkin_: derstrom: pastebin dmesg and xorg log
15:12 karolherbst: derstrom: you have to boot with kms enabled
15:12 karolherbst: as far as I know it isn't that easy to switch to kms at runtime?
15:13 karolherbst: skeggsb_: do you know if nouveau gets all three loads for tesla or only core load?
15:13 pmoreau: skeggsb_: You are talking about the structure object named nvkm_pci_func (of type nvkm_subdev_func), not the structure of type nvkm_pci_func, right?
15:14 derstrom: imirkin: http://pastebin.ca/3178448
15:14 derstrom: karolherbst: I did try rebooting.
15:15 karolherbst: what is your kernel cmdline?
15:15 imirkin_: derstrom: can you pastebin dmesg and xorg logs, not greps of various things?
15:16 imirkin_: i wouldn't be surprised that the issue is that debian ships the idiotic firmware user helper
15:17 imirkin_: which in turn causes a harder failure than nouveau expects
15:17 imirkin_: derstrom: try booting with nouveau.config=PGRAPH=0
15:18 derstrom: OK thanks. I'll give it a try.
15:19 karolherbst: I get load data :O
15:28 derstrom: imirkin_, thanks, got native resolution working now. Although no 3D acceleration; I suspect I'll need to upgrade to a newer kernel to sort that out.
15:28 imirkin_: derstrom: that's right, you need kernel 4.1 for accel
15:28 imirkin_: derstrom: or you can extract blob ctxsw firmware from an mmiotrace
15:29 imirkin_: derstrom: probably harder than upgrading the kernel ;)
15:30 derstrom: I'll look into an mmiotrace, as I'd rather not upgrade the kernel if I can avoid it. Thank you for your help.
15:31 RSpliet: pmoreau: sorry, I got the line numbers from the patch, see https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/09de762f1cf3f713248abca6792aa927fac06406
15:31 imirkin_: skeggsb_: do we enable cache snoop by default?
15:31 RSpliet: they did probably change
15:32 pmoreau: RSpliet: Ok, will give a look soon and try that
15:32 RSpliet: line 320, 363, 457
15:33 RSpliet: pmoreau: ^ :-P
15:33 imirkin_: skeggsb_: errrr... ignore that question
15:33 imirkin_: skeggsb_: a better one -- how does nouveau_bo_map work for VRAM bo's?
15:35 airlied: imirkin_: I'm guessing snooping is default, I think generally we avoid mapping vram if possible
15:35 imirkin_: but what if we do a nouveau_bo_map -- what does that actually do?
15:36 imirkin_: basically i'm looking for some reasons why atomics fail
15:36 airlied: maps the PCIE BAR
15:36 imirkin_: the BAR is only 256MB or so
15:36 airlied: yup so I assume if it isn't visible, it fails to map the PCIE BAR
15:36 airlied: though not sure how nouveau does that
15:37 imirkin_: yeah.... which is why i'm asking
15:38 airlied: are you trying to look inside gmem from the cpu?
15:38 imirkin_: i guess we ~never nouveau_bo_map the vram buffers in mesa either.
15:38 imirkin_: no
15:38 imirkin_: i'm trying to come up with theories as to why the gpu hates me
15:38 airlied: the only time we'd ever mmap vram is for the frontbuffer I'm guessing
15:39 imirkin_: and i could imagine it not wanting to do atomic ops if someone were looking at the vram via mapped access
15:39 airlied: there's not some special page table bits or anything?
15:45 pmoreau: RSpliet: Looks like you might get my T-b. No corruption, no GR being unhappy and glxgears working correctly so far.
15:46 RSpliet: excellent! :-)
15:46 pmoreau: Let's see if it survives the Portal test. ;)
15:49 pmoreau: it's still working! And I get 45 fps
15:49 pmoreau: RSpliet: Awesome job!! :-)
15:49 imirkin_: and all you had to do was reverse the polarity :)
15:49 pmoreau: :D
15:49 imirkin_: too many flips to keep in poor Roy's head
15:50 RSpliet: imirkin_: exactly
15:51 pmoreau: So, I get 45fps at 0f, 33 at 0e, 21 at 05 and 9 at 03
15:51 RSpliet: that sounds very plausible
15:52 RSpliet: I'll just go and fix it up for GT21x as well
15:52 RSpliet: and then I'll send stuff off to the ML
15:52 pmoreau: I should be able to try Planetary Annihilation as well
15:53 pmoreau: But wasn't GT21X already supported and working?
15:53 imirkin_: skeggsb_: we appear to be setting a flag called "read only" in nvgpu
15:53 RSpliet: very little cards change the voltage on GT21x
15:53 imirkin_: skeggsb_: u32 target = (vma->access & NV_MEM_ACCESS_NOSNOOP) ? 7 : 5
15:53 pmoreau: Just the clocks, but not the voltage?
15:53 RSpliet: yep
15:53 imirkin_: skeggsb_: and bit 4 is "gmmu_pte_read_only_true_f"
15:53 pmoreau: Oh, ok
15:54 RSpliet: I haven't seen a single card that changes FBVDDQ
15:54 imirkin_: oh gr. that's on the first dword.
15:54 RSpliet: and some that change... the other one :-P
15:54 pmoreau: :D
15:54 pmoreau: What is FBVDDQ?
15:55 RSpliet: reference voltage for the RAM
15:56 imirkin_: skeggsb_: we're also setting the "vol" bit, which they set if (!cacheable)
15:56 pmoreau: Ok
15:57 pmoreau: Keeping the discrete on 0f is keeping the fan somewhat busy, way more than usual :-)
15:57 RSpliet: haha yes that's to be expected :-D
15:58 karolherbst: how does the pmu stuff actually work? It collects some data and after a specific time the value has to be read out?
16:00 RSpliet: pmoreau: would you like your tested-by on the NV50-related patches?
16:01 imirkin_: gnurou: if i repro my troubles on a GK20A, would you be interested in helping debug why global memory accesses don't work from a shader?
16:01 pmoreau: RSpliet: I would :-)
16:09 karolherbst: ahh now I get how this works
16:09 karolherbst: ohhh
16:10 karolherbst: this pretty trivial
16:11 karolherbst: hakzsam: is it part of your perf counter work also to provide these current load information?
16:11 karolherbst: ohh wait
16:12 airlied: imirkin_: did you try asking the nvidia email yet?
16:12 imirkin_: airlied: i've tried it a dozen times before, i'm not touching it again
16:12 karolherbst: RSpliet: are you implementing the perf counter stuff? I really don't know who is doing what and the real names behind the IRC tags :D
16:13 imirkin_: airlied: i might as well be sending the mail to /dev/null
16:13 imirkin_: actually /dev/null is better because at least there, i know what the outcome will be.
16:13 airlied: imirkin_: well ask gnurou is probably the same thing :)
16:13 airlied: since I assume the emails go to him
16:14 imirkin_: actually apparently he wasn't even on that list for a while
16:14 RSpliet: karolherbst: nope, that's hakzsam
16:14 imirkin_: although i understand that he is now
16:14 karolherbst: ohh okay
16:14 RSpliet: hackszam
16:14 RSpliet: hakk...
16:14 RSpliet: whatever
16:14 karolherbst: I think your first try was right
16:14 RSpliet: :-D
16:14 karolherbst: I really would like to have those load information readable somehow, but I don't want to do something he already finished
16:15 karolherbst: or what he planned to do
16:18 imirkin_: airlied: anyways, my observation is that that list is a huge waste of time for asking questions. i bet if i ask for documentation on register XYZ or something like that, they'll make it happen
16:18 pmoreau: karolherbst: hakzsam, aka Samuel Pitoiset
16:18 karolherbst: mhhh
16:18 pmoreau: He made a presentation at XDC '15 and ;14
16:18 karolherbst: yeah
16:18 karolherbst: somehow I though RSpliet would be the better fitting nick name :D
16:19 imirkin_: karolherbst: that's Roy Spliet, also presented at XDC '14
16:19 imirkin_: with a surprisingly british accent
16:19 karolherbst: mhh
16:20 karolherbst: maybe I really should watch those some time
16:20 pmoreau: You should ;)
16:21 airlied: imirkin_: yeah well I suppose anything that takes them a lot of time is probably going to go slower
16:22 karolherbst: airlied: I don't think time is the problem here
16:22 imirkin_: airlied: maybe. i haven't gotten answers to most of the questions i've asked over the past year or more that it's been around
16:22 karolherbst: they usually know the answer and if not, then well
16:23 imirkin_: airlied: and since i try to put in a bunch of effort into making clear questions when i send them out, it just doesn't seem to be worth my time
16:23 karolherbst: skeggsb_: by the way: did you got any answer regarding your gddr5 question?
16:23 karolherbst: :D
16:23 RSpliet: hmm, time to get myself another news article
16:32 karolherbst: waaait a moment
16:32 karolherbst: why is nouveau so close to the blob with pixmark piano?
16:32 RSpliet: because nouveau is awesome?
16:32 imirkin_: karolherbst: that'll have to be rectified!
16:33 imirkin_: i'll go add some sleeps now...
16:33 karolherbst: I investiage this
16:37 karolherbst: mhh gputest pixmark piano: blob 22-23 fps, nouveau 16-17 fps
16:38 karolherbst: and this is like a gpu core only benchmark
16:38 imirkin_: that seems like the usual deal
16:38 imirkin_: about 60-80% of the perf...
16:38 karolherbst: yeah, but I got the feeling, that I usually get below 60
16:44 karolherbst: mhhh
16:45 karolherbst: the pmu shows me much lower gpu core loads with nouveau
16:45 karolherbst: around 65&
16:45 karolherbst: %
16:45 RSpliet: are you maxing out a CPU?
16:45 karolherbst: I am running pixmark_piano
16:45 karolherbst: this produces 100% core load with blob
16:46 imirkin_: what about cpu load with nouveau?
16:46 imirkin_: is it at 100%?
16:46 karolherbst: above
16:46 imirkin_: hm... so it's multithreaded? that's unfortunate.
16:46 RSpliet: is there a CPU that hits 100% load?
16:46 karolherbst: well
16:46 karolherbst: 115%
16:46 imirkin_: what about with blob?
16:47 karolherbst: RSpliet: nope
16:47 karolherbst: two cores at 60%
16:47 karolherbst: actually one at 60, one at 50 and one at 20
16:48 karolherbst: ohhhh wait
16:48 karolherbst: I have to reset the regs :/ silly me
16:51 karolherbst: much better now
16:51 karolherbst: the gpu core is now at 100% :D
16:52 imirkin_: ?
16:52 karolherbst: actually above, but that may be because I wrote a bash script to read them out
16:52 karolherbst: imirkin_: the pmu regs have to be resetted between reads because of overflow
16:52 imirkin_: ah
16:52 RSpliet: bash script raising gpu load?
16:52 karolherbst: no
16:53 karolherbst: a bash script reading the gpu load out :D
16:53 karolherbst: https://gist.github.com/karolherbst/538d5429587dada60845
16:53 karolherbst: the initialization I did myself though
16:53 karolherbst: this script just reads and resets
16:55 karolherbst: okay, works as expected and the values are making sense
16:56 karolherbst: now serious stuff
16:57 karolherbst: imirkin_: ohh right, is there something I could do for helping with that funy msaa x8 issue I've got in heaven?
16:57 imirkin_: you could figure out why it happens and fix it ;)
16:57 imirkin_: fwiw i repro'd it on all hardware
16:57 imirkin_: so... it's something annoying.
16:57 karolherbst: okay
16:57 imirkin_: i guess it'd be annoying no matter what
16:58 imirkin_: but it's not some kepler-only thing
16:58 imirkin_: i bet our MS blits are failing or something
16:58 imirkin_: that whole blit logic is all dumb and broken
16:58 karolherbst: or it is an issue in every chip specific code path :p
16:58 imirkin_: well, the 3d blitter stuff is mostly shared
16:59 karolherbst: funny how the load is the same on the blob and nouveau
17:18 karolherbst: imirkin_: if you want you could try that script out. It should also initialize some values now
17:18 karolherbst: ohh wait
17:18 karolherbst: didn't test this
17:20 karolherbst: okay now it should work. I don't know if this works on non kepler chips though
17:20 karolherbst: and it prints bs if there is no load
18:33 gnurou: imirkin_: I am still not on that list, I'd really like to replace it with a bug tracker actually
18:34 imirkin: gnurou: oh. i thought you managed to get added to it... my bad
18:34 gnurou: imirkin: as for the shader issue, I'd love to, but not even sure I could allocate time for it... too many things to do :(
18:35 imirkin: gnurou: fair enough. i'm going to give it another shot with ssbo -- my hope is that only atomic ops are affected
18:35 imirkin: (admittedly ssbo has atomic ops as well, but it lets you do regular loads/stores which should ease debugging)
18:36 imirkin: gnurou: should you have a burning desire to spend time figuring this out, ping me :)
18:36 gnurou: imirkin: sorry about that. it's just that I have reached the limits of how much I can scale :/
18:36 imirkin: yeah, no worries
18:36 imirkin: i wasn't really expecting you to be able to do it
18:36 imirkin: but asking is pretty easy :)