10:30karolherbst: on the 0e pstate my tesla isn't able to properly drive my VGA attached display
10:30karolherbst: allthough the gpu has no memory and hence no memory clock
10:34karolherbst: so, my active adapter works too then
10:53Caterpillar: Do you know if it is possible to have on the same Linux system, a Radeon RX480 and an old Geforce GTX260? Tomorrow I will receive the RX480 but I cannot still unplug the Geforce because it is part of liquid cooled system and I have to buy some hydraulic pieces before unplugging the tubes
10:54karolherbst: why shouldn't it work?
10:54karolherbst: in the end you can use prime offloading to use both
10:55karolherbst: either reverse or normal
10:56NanoSector: wasn't nvidia working to support prime in their binary driver?
10:57NanoSector: or is that me being too optimistic about the fedora 25 prime blog post
10:57karolherbst: you mean their crappy prime support? or real prime?
10:57Caterpillar: karolherbst: what is prime offloading?
10:57NanoSector: karolherbst, prime as in dri_prime
10:57karolherbst: Caterpillar: rendering on one, displaying on another gpu
10:58karolherbst: NanoSector: well, nvidia uses just that, but they only implement that sink offloading stuff I think
10:58Caterpillar: karolherbst: cool, I did not know it was possible to do that
10:58karolherbst: aka the crappy one
10:58karolherbst: Caterpillar: ignore "optimus": https://nouveau.freedesktop.org/wiki/Optimus/
10:59karolherbst: ohh wait
10:59karolherbst: you could just plug your displays into the amd card...
10:59karolherbst: I guess
10:59karolherbst: then you won't need it
10:59Caterpillar: karolherbst: I am afraid that the system (Fedora 24) could choose to render using the Geforce
11:00NanoSector: do you have proprietary drivers?
11:00karolherbst: Caterpillar: it shouldn't
11:00NanoSector: on arch at least that overwrites mesa's libgl which causes issues with open source drivers
11:00Caterpillar: NanoSector: actually yes, but I will switch the entire system on open drivers
11:01NanoSector: i wonder how fedora's mac support is
11:02Caterpillar: NanoSector: Apple Mac?
11:02NanoSector: yes, the speed of this thing makes me want to stab myself
11:02Caterpillar: NanoSector: is good, I know some people using Fedora on their Macs
11:02NanoSector: last I tried Arch on this, half the stuff wouldn't work
11:02Caterpillar: contact me if you experience troubles in making the WiFi work
11:02NanoSector: e.g. bluetooth (which kind of sucks if you use a bluetooth keyboard and mouse)
11:03NanoSector: oh i don't expect wifi issues, this has an atheros wifi card, not a broadcom thankfully
11:03karolherbst: I have a bcm4321 in my mac mini, guess if it works
11:04NanoSector: my tablet however has a broadcom SDIO wifi card
11:04NanoSector: I have to extract an nvram file from my UEFI firmware to get it to work
11:04Caterpillar: concerning my question, later I will try searching "Mesa select videocard" on Google
11:04karolherbst: Caterpillar: mesa will pick what is the main on X
11:05Caterpillar: karolherbst: therefore should I edit xorg.conf? Oh, noes, I hate it
11:05karolherbst: Caterpillar: nope, X should detect it on its own
11:05karolherbst: if there is no display on one GPU, don't use it
11:05Caterpillar: karolherbst: mmh ok
11:05karolherbst: if it does.... the tell X to screw itself ...
11:05karolherbst: you could just tell X to load the dummy X driver for the nvidia gpu
11:06karolherbst: Caterpillar: like here: https://gist.github.com/karolherbst/1f1bdd1a3822df74097f
11:06karolherbst: only the nvidia device
11:06karolherbst: and with adjusted busid
11:07NanoSector:makes a Fedora 24 USB
11:08Caterpillar: karolherbst: so "dummy" should disable a card, correct?
11:09karolherbst: well, in fact no, the gpu is still there and accessable, but X won't do anything with it
11:11Caterpillar: karolherbst: you're the best, this is very useful
12:27mupuf: karolherbst: http://codepad.org/Ne2gnzmN <-- the titan
12:29karolherbst: any idea how nvidia generates the UUID?
12:29karolherbst: current pcie width: 1x
12:30karolherbst: mupuf: I assume the titan is on the 16x pcie slot?
12:31karolherbst: mupuf: the log is cut off by the way
12:31RSpliet: "inserting the Titan was like cramming an elephant down an anthill"
12:32karolherbst: imirkin, hakzsam_: I guess I will resend the postraconstfolding series without the RA change for now until we figure out a good way to actually adjust the RA part
12:33karolherbst: mupuf: interesting
12:33karolherbst: 0x41 93 OVERVOLTAGE_LOGIC Max Active 2091000 KHz GPC2CLK (set from 1212 mV NVVDD)
12:33karolherbst: 0x4d 95 RELIABILITY_ALT_LOGIC Max Active 2065000 KHz GPC2CLK (set from 1200 mV NVVDD)
12:33karolherbst: 0x42 97 RELIABILITY_LOGIC Max Active 2012000 KHz GPC2CLK (set from 1162 mV NVVDD)
12:34karolherbst: maybe those are our three max volt entries?
12:34karolherbst: but I doubt that
12:34karolherbst: they are :O
12:35karolherbst: unk7: 2 -> -- ID = 2, mode: 1, link: -1, voltage_min = 1137500, voltage_max = 1162500, volt = 1261332 + (-96 * T * 5^6) >> 10 [µV]
12:35karolherbst: unk8: 0 -> - ID = 0, mode: 0, link: -1, voltage_min = 1137500, voltage_max = 1212500, volt = -1916996 + (40653 * S) / 10 + (-130130 * S²) / 100000 [µV]
12:35karolherbst: unkc: 1 -> -- ID = 1, mode: 1, link: -1, voltage_min = 1175000, voltage_max = 1200000, volt = 1298832 + (-96 * T * 5^6) >> 10 [µV]
12:35mupuf: karolherbst: I will go back to the nvc1 ;)
12:35karolherbst: the votlage_max values are reported by the log
12:35karolherbst: nice :)
12:36karolherbst: I guess nvidia might disable some of those
12:36karolherbst: but we won't do it anyway
12:36karolherbst: those 0.5% more perf
12:36mupuf: Lekensteyn: thanks a lot for your finding
12:37karolherbst: I like it how we don't do anything wrong according to the findings :)
12:37karolherbst: noticed how the unkc field correspondends to the 0x4d entry?
12:37mupuf: yep, too bad we did not get this to begin with, it would have saved a lot of trouble :D
12:38karolherbst: as if it was added later
12:38karolherbst: and reduced the fun
12:38mupuf: anyway, I will go back to the fan insanity
12:38karolherbst: mupuf: I added some stuff in nvbios for the gpio/conn stuff
12:39karolherbst: the PWM_1 gpio should be actually "FAN_ALERT"
12:39karolherbst: no clue what it does though
12:40karolherbst: and a bunch of SLI stuff too
12:40karolherbst: seems like the GPU use the GPIO to tell the other ones when they are ready with their stuff or so
12:41mupuf: yes, I read your patches this morning
12:41mupuf: got this out from the DCB docuentation, right?
12:44karolherbst: :/ sad
12:44karolherbst: nothing new
12:45karolherbst: let me check if my boost logic is right though, I should get to the clock from the voltage like nvidia-smi prints it out
12:46karolherbst: mupuf: ohh wait
12:46karolherbst: mupuf: mind dumping it once for 1°C and once for 95°C?
12:46mupuf: hmm, sorry, already working on the c1 :s Will plug it back when I am done
12:46karolherbst: k, thanks
12:50karolherbst: actually, this should work on mine as well
12:52karolherbst: ohh wait, it doesn't
12:52karolherbst: silly me
12:55karolherbst: the clocks are adjusted to the current temperature
12:55karolherbst: or rather the volt requiernments for that clock
12:55karolherbst: the same thing I implemented :D, but differently
12:56karolherbst: mhhh now I am thinking
12:56karolherbst: maybe it would make sense to have a list of limiters and just revalidate the current state against changes
12:58karolherbst: the hell is mid point
12:58karolherbst: has the same clocks than rated tdp
12:59karolherbst: ohh wait, wrong
12:59karolherbst: same as turbo boost
14:06Lekensteyn: mupuf: thank you all for your hard work on nouveau, typing this with an external screen connected powered by nouveau :-)
14:07karolherbst: ohh what times when users were already satisfied with working displays on nouveau :D
14:07mupuf: Lekensteyn: I cannot take credit for almost naything you are using with nouveau
14:07mupuf: aside from fan management
14:07mupuf: and if you reclock
14:07mupuf: these are the only aspects I worked on that are available
14:07mupuf: oh, and perf counters
14:07karolherbst: nvidia should build more GPUs with LEDs, then everything could thank mupuf!
14:07mupuf:really only cares about PM, it would seem
14:08Lekensteyn: haha :P need instructions how to add LEDs to my GPU :P
14:08karolherbst: Lekensteyn: upgrade it to a titan or 980
14:09Lekensteyn: nvidia-smi --debug seems quite new, it was only added to driver version 352 (2015-08)
14:10mupuf: oh, good to know we have not been idiot for that long :D
14:10Lekensteyn: actually, the first 352 version was in 2015-05 (based on arch logs)
14:11mupuf: one can trust arch quite well for this
14:11mupuf: data collection is ... a little boring
14:11mupuf: good that it is automatic
14:17karolherbst: uhh, my power budget patches even create a memory leak...
14:27karolherbst: Lekensteyn: I have something for ya
14:27karolherbst: Lekensteyn: https://gist.github.com/karolherbst/49737d42e456edc63912c1ac1043aa03
14:28Lekensteyn: karolherbst: I've seen that before. Is this with pcie_port_pm=off?
14:29Lekensteyn: does your laptop use PR3? (bios date >= 2015?)
14:29karolherbst: I highly doubt that
14:29karolherbst: the bios is from 2012 or so
14:29Lekensteyn: ok, then it should not be the case
14:29karolherbst: efi: EFI v2.31 by American Megatrends
14:30karolherbst: efi: ESRT=0xcbf82998 ACPI 2.0=0xcb952000 ACPI=0xcb952000 SMBIOS=0xcbf82498
14:30karolherbst: ohh, it is actually from 03/12/2014
14:30Lekensteyn: have to grep for DMI:
14:30karolherbst: that isn't helpful
14:31karolherbst: DMI: Notebook P15SM /P15SM , BIOS 1.03.04PM v2 03/12/2014
14:31Lekensteyn: ehh, wait, that is also in the log you posted :P
14:31karolherbst: Tesla GPUs are so much fun
14:31karolherbst: 90°C full idle
14:32Lekensteyn: huh, 90 degrees Celsius?
14:32Lekensteyn: is that a measurement error?
14:33karolherbst: I've removed the dvd drive from my mac mini, maybe the air circulation isn't good anymore
15:18karolherbst: skeggsb: your 4.9 branch seems to work
15:27karolherbst: uhhh: https://www.reddit.com/r/pcmasterrace/comments/4qt8pf/geforce_experience_sends_a_detailed_log_of_your/
15:31karolherbst: Lekensteyn: mind checking for this and dump everything nvidia sends? :D
15:41pmoreau: imirkin: You beated me to it! I was going to close it as duplicate of 94990
15:42Lekensteyn: karolherbst: what details are you interested in? it seems that I'd have to install GeForce experience on Windows and tap the network traffic?
15:45karolherbst: Lekensteyn: nope, I meant to investigate on Linux
15:45Lekensteyn: whether the nvidia driver phones home?
15:46Lekensteyn: also, fail at their data collection website http://sprunge.us/NhRd
15:49karolherbst: Lekensteyn: well in general I am interested in everything they send
15:52Lekensteyn: hey karolherbst , I just noticed a nvidia-debugdump binary in usr/bin/, what is it?
15:54karolherbst: no clue?
15:55karolherbst: but I like how that sounds
16:13karolherbst: imirkin: good catch
16:41whompy: It has been a while since I've tinkered much with nouveau, but I saw that skeggsb is looking for testing on his atomic stuff. To test, you build from the nouveau tree on his github repo and load that with another kernel, correct?
16:42karolherbst: whompy: you could just use his kernel tree as well
16:42karolherbst: but he messed up on htis linux-4.10 branch
16:42whompy: I recall it being a bit of an odd beast in the past. Is that still correct?
16:43whompy: I'm a bit leery to do much with mainline/4.10 at the moment as the 4.9rc stuff has been obnoxious for my computers.
16:43karolherbst: what do you mean? his kernel tree is a simple kernel tree
16:44whompy: Neither will find the root partitions. Kk. I seem to be misremembering.
16:44karolherbst: try https://github.com/skeggsb/linux/tree/linux-4.9
16:44whompy: Will do.
16:44karolherbst: it says 4.9, but it is a 4.8 tree
16:44karolherbst: with 4.9 drm changes
16:45karolherbst: I am currently bisecting his 4.10 tree
16:46whompy: Ah, okay. That would be perfect for my testing. Thanks again!
16:46karolherbst: I hope 4.8-rc8 is fine for you?
16:46karolherbst: the other one would be 4.9-rc2
16:46whompy: Yeah. 4.8* has been fine. I think there was an upstream change with a workaround in 4.9 that happens to hate my machines. I haven't tried rc4 yet, though.
16:47whompy: has to do with... something virtual. Not enough coffee in my system right now.
16:47karolherbst: kernel bisecting is fun
16:48whompy: Oh yes. Haven't had to do that in quite some time. Twas a good learning experience for a casual user, though.
16:59karolherbst: skeggsb: found the commit
17:00karolherbst: whompy: uhhhh. I just checked, I think his 4.9 tree doesn't contain that stuff
17:00whompy: good timing. Just about to hit make.:)
17:00whompy: the 4.10 tree is built from 4.9rc2, correct?
17:01whompy: I think I know what to disable to make it work.
17:01karolherbst: skeggsb: odd: https://github.com/skeggsb/linux/commit/f6795bda9c2ee8173398533cab355fe259a9c1f1
17:22karolherbst: skeggsb: after reverting that on the branch, everything else seems to work just fine
17:24karolherbst: except that this tesla doesn't seem to like to drive 2 screens at full hd at all
17:25karolherbst: wow, I get like 30 fps with glxgears
17:25karolherbst: on lowest perf level
17:26karolherbst: 400 with vsync disabled
17:50karolherbst: skeggsb: but for whatever reason, that atomic stuff doesn't really seems to work. I add modes the hw shouldn't be able to do, but it just set them and doesn't revert to a working one
18:03imirkin: karolherbst: do you know if i should be testing his linux-4.10 branch or devel-kms?
18:04imirkin: i'd *prefer* to stick to v4.8, actually, if possible...
18:04karolherbst: devel-kms is his nouveau tree
18:04karolherbst: otherwise his kernel tree and linux-4.10
18:04karolherbst: no clue then
18:35karolherbst: should I run piglit with ./piglit-run.py -1 --dmesg tests/gpu.y or something else?
18:35imirkin: probably "py"
18:36karolherbst: ohh, sure
18:36imirkin: although ben just pushed a patch that maybe will fix the concurrency stuff
18:36karolherbst: but besides that?
18:36imirkin: see https://people.freedesktop.org/~imirkin/
18:36karolherbst: right, I never run with -1
18:36karolherbst: and it worked
18:36karolherbst: I guess the biggest concurrency killer is X
18:36imirkin: --dmesg implies 1
18:37karolherbst: who needs dmesg output anyway, I just want to catch regressions
18:46karolherbst: it is so much faster without -1
18:46imirkin: make sure you have that latest patch
18:46imirkin: otherwise you'll get hangs
18:47karolherbst: in nouveau?
18:47karolherbst: I ran master+something pretty much all the timne
18:47karolherbst: maybe this I don't have
18:50imirkin: anyways, i think you're less likely to hit it with your super-gpu
18:51imirkin: whereas i was always hitting it on my bargain-bin hw
18:51karolherbst: you also drive X with yours
18:51imirkin: probably doesn't help
18:51karolherbst: I don't even have the nouveau ddx loaded
18:51imirkin: although i was getting hangs with DRI3 + prime on an intel main gpu
18:51imirkin: (with a GK208)
18:51karolherbst: yeah, cause nouveau ddx is loaded
18:52karolherbst: X is silly if it's there
18:52karolherbst: I am already at test 17k
18:53imirkin: yeah, i wasn't loading the secondary GPU into X when i was getting hangs
18:53imirkin: that said, this was like ... a year ago
18:53karolherbst: ... the biggest CPU burner while piglit runs: plasmashell and X
18:53karolherbst: and kwin
18:54imirkin: try with PIGLIT_NO_WINDOW=1
18:54imirkin: should go about 10x faster too
18:54karolherbst: uhh, what a splendid idea
18:55imirkin: ok, looks like there's absolutely no hope of getting the current branch going on v4.8
18:55imirkin: missing functions like drm_atomic_state_put, incompatible types, all kinds of goodies
18:55karolherbst: ahhh right
18:55karolherbst: I remember
18:55karolherbst: I had to drop those for my master_4.8 branch
18:55imirkin: error: 'struct drm_plane_state' has no member named 'src'
18:55imirkin: it just ain't happening
18:55karolherbst: yeah, you can't use those on 4.8 :(
18:56karolherbst: check my master_4.8 branch, that's the best I could do
18:56imirkin: not worth it for now
18:56imirkin: i need to reboot to powercycle one of my hd's that's dying
18:56imirkin: hopefully that'll get it going again.
18:57imirkin: debating whether i should replace it, or just get a pair of 8TB drives
18:57imirkin: [to replace my 4x 2TB drive setup)
18:58karolherbst: so much storage
18:58karolherbst: and I am already happy about my 1.8T
18:58imirkin: well, in raid5, so 6T of usable space
18:58imirkin: and i've hardly filled it all
18:58imirkin: but getting there
18:58imirkin: only about 1.5T left
18:59imirkin: i'm sure i could delete 1T of stuff if i had to
18:59karolherbst: fun, df doesn't list all my drives
18:59karolherbst: mhh, I think I need another 1TB drive...
19:00karolherbst: maybe 2TB aren't that expensive anymore
19:00imirkin: less than $100
19:00karolherbst: as I said: I am happy with my 1.8TB storage :D
19:00imirkin: right. laptop.
19:00karolherbst: mhh lets see
19:01karolherbst: 5TB for 220€
19:01karolherbst: the heck
19:01karolherbst: I see
19:02karolherbst: I can put in 2x 2,5" @ 9,5mm, one 2,x5" @ 7mm and 2 mSata SSDs :)
19:02karolherbst: I don' buy a seagate.. the hell am I
19:03imirkin: according to backblaze's latest reports, seagate is by far the worst these days
19:03karolherbst: I guessed
19:03karolherbst: I usually buy WD
19:03imirkin: yeah, WD ain't great, but they're not much worse. i think HGST was supposedly the best
19:03imirkin: which is the leftover of IBM iirc
19:04karolherbst: well, my WDs seems to work just fine, none of my WDs broke until now, so
19:04karolherbst: but I always buy those 24/7 things
19:04imirkin: i bought 4 2T WD's in 2010 or so - all 4 have now failed. first 3 during warranty period iirc.
19:05imirkin: the super-cheapo ones though - WD Green or whatever, which had a ton of issues.
19:05karolherbst: your fault
19:05karolherbst: mine is a WD10JUCT-63J6SY0
19:06imirkin: got replaced with WD20EARX which are a lot more reliable
19:07karolherbst: 14263 hours power on
19:08imirkin: 55710 for me :)
19:08karolherbst: well, on a laptop those drives usually go to sleep if nothing is to be done anyway
19:08imirkin: only 35K on the replacements tho
19:08karolherbst: at least I configured them this way
19:08imirkin: 5 Reallocated_Sector_Ct 0x0033 135 135 140 Pre-fail Always FAILING_NOW 515
19:09imirkin: SMART overall-health self-assessment test result: FAILED!
19:09karolherbst: 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
19:09imirkin: this is the first time i've seen a drive actually say that :)
19:09nailyk: robclark: can I bother you with freedreno?
19:09imirkin: nailyk: i think you're looking for #freedreno
19:10nailyk: oh there is a chan? Thanks!
19:10karolherbst: imirkin: my other one is a WD5000LPVX-22V0TT0
19:11karolherbst: uhh, I still have my segate...
19:11karolherbst: I thought I banned this one
19:11nailyk: but he isn't in it :s Anyway thanks!
19:11karolherbst: ohh right, I added it after my SSD failed
19:12imirkin: yeah he is.
19:13karolherbst: "perf: interrupt took too long (4021 > 4005), lowering kernel.perf_event_max_sample_rate to 49000" :O
19:13karolherbst: never got that
19:15karolherbst: imirkin: what do you think about the HTE721010A9E630 ?
19:17karolherbst: well, those are 3,5" ones
19:18imirkin: i understand... but that's where i get my info from. i have no additional knowledge :)
19:20karolherbst: HGST indeed seems more reliable
19:21karolherbst: but I would rather choose 5 years of warrenty, but the heck, 3 are enough :D
19:21imirkin: whether this has any bearing on their laptop drives, who knows
19:23karolherbst: it's the only one with 7200 rpm and high reliablity things
19:24karolherbst: okay and I will give SSDs another try, don't fail me this time...
20:55karolherbst: mupuf: okay, I think I got that clock gating working on my tesla, I have no power sensor though :(
20:55karolherbst: but I have the apple sensors with a 0.25 °C accuracy for the gpu, which helps a lot
20:56karolherbst: vblanked glxspheres64 stabilizes at around 84.75°C
20:56karolherbst: and with enabled clockg ating, tmeperature falls below 83°C
20:57karolherbst: enabling again -> rises to 84.75°C
20:58karolherbst: poke 1588 1 seems to be one of the important things
21:02karolherbst: and 1098 seems to configure something
21:04karolherbst: gpu stabilizes at 82.5°C with the enabled stuff :)
21:09mwk: 1.5kLOC and I haven't submitted a single method yet
21:09mwk: *and* I've already found a ton of bugs in nouveau nv04 grctx switching
21:11mupuf: karolherbst: yeah, absolutely, 1588 is greaty
21:12mupuf: and IIRC, there is something in register 200 to enable clock gating
21:12karolherbst: 200 is PMC.ID isn
21:12karolherbst: 't it?
21:12mwk: karolherbst: nah, PMC.ENABLE; PMC.ID is 0
21:12mupuf: isn;t it PMC.ENABLE?
21:12karolherbst: right, I meant ENABLE
21:12karolherbst: that bit was already set
21:12karolherbst: I think
21:13mupuf: but there was something in the high bits, IIRC
21:13karolherbst: anyway, 2.25°C less heat is good :)
21:13karolherbst: I poked ffffffff in it, and nothing changed
21:13mupuf: yep ;)
21:13karolherbst: trying out glxspheres64 without vsync :D
21:13mupuf: try writing 0 and reload nouveau :p
21:13karolherbst: 85.5°C, not bad
21:14karolherbst: stupid unstable load
21:14karolherbst: and silly firmware controled fan
21:15mupuf: mwk: well, seems like fun is being had
21:16karolherbst: it droped below 84°C even with glxspheres64 running
21:16karolherbst: like super immediatly
21:16mwk: mupuf: indeed it is
21:17karolherbst: okay, so yeah, maybe this isn't so hard to actually use
21:17karolherbst: 1098 and 1588 are the only things I have to touch to reduce temp by 2°C
21:17mwk: mupuf: only one more state test and I'm going to start submitting nv4 methods
21:21mupuf: mwk: how do you know you are done?
21:21mwk: mupuf: I don't, really...
21:21mwk: but atm I have modeled all writable MMIO registers in my structures
21:22mupuf: makes sense
21:22mwk: and I have properly simulated how writing any of them affects the others
21:22mwk: oh, and I can save/restore them all at once, which is *not trivial*
21:23mwk: if you do it in the wrong order, you can destroy earlier registers by writing later ones
21:23mwk: plus some regs can only be saved/restored properly if some other regs are set to proper values
21:24mupuf: I see, and that's the nouveau bugs you uncovered?
21:25mupuf: makes sense
21:25mwk: nouveau just goes straight through the list of saved/restored registers
21:25mwk: instead of doing the right dance
21:26mupuf: mwk: that may explain why parrallel piglit fails
21:26mwk: ... on nv4?
21:28mupuf: no, I am extrapolating
21:29imirkin: mwk: + insrt(state->xy_clip[xy][idx >> 3], idx * 4 & 0x1f, 4, cstat);
21:30karolherbst: mupuf: it doesn't fail for me
21:30imirkin: mwk: unless i'm totally off, that's inconsistent...
21:30mwk: huh, looks weird
21:30mwk: I copied that part from nv3...
21:30imirkin: i.e. if idx >> 3 != 0, then idx * 4 & 0x1f == 0.
21:31mwk: but it does seem to be correct
21:31mwk: I should've written it as (idx & 7) * 4, true
21:32karolherbst: idx * 4 & 0x1f isn
21:32karolherbst: 't that equal to idx * (4 & 0x1f) ?
21:32mwk: it's (idx * 4) & 0x1f
21:32imirkin: mwk: ah right. ok, that makes more sense. (and is equivalent).
21:34karolherbst: I see
21:34karolherbst: I was never good with this
21:35mwk:knows the operator priorities too well for his own good
21:35RSpliet: to get my 2ct worth of nitpicks in, it could be (idx * 4) & 0x1c ... whether that would clarify things though
21:36imirkin: i like the idx >> 3 vs idx & 7 thing
21:36imirkin: makes it clear that idx is effectively 2 values
21:36karolherbst: well, to be consistent, it should be (idx << 2) & 0x1c anyway
21:37imirkin: (idx & 7) << 2 (or * 4) is clearest
21:37karolherbst: I meant to be consistent with the idx >> 3
21:38imirkin: idx >> 3 is basically shaving off the bottom 3 bits. idx & 7 grabs those 3 bits.
21:38imirkin: so they complement each other
21:40imirkin: thanks =]
21:40karolherbst: uhm I dislike the decimal notation if an hex value is meant :O
21:40karolherbst: (idx & 0x7) * 4 much better
21:41mwk: of course
21:41mwk: the whole nvhw/pgraph* thing badly needs a refactor
21:41mwk: and the most important issue is 0x7 vs 7...
21:42karolherbst: have to be aware of issues devs have while reading the code
21:42karolherbst: they will always complain about those things and become less productive
21:42karolherbst: very important
21:43mwk: pgraph_xy.c is basically a hellscape of code duplication
21:43mwk: and that was before it got copied to pgraph_xy3.c and then pgraph_xy4.c
21:44RSpliet:build karolherbst a bikeshed
21:44RSpliet: paint it any colour you like, as long as it's blue
21:44mwk:hopes he can avoid pgraph_xy10.c, the current version should be somewhat generic...
21:45karolherbst: RSpliet: how did you know that was the first thing I would do :O
21:47mupuf: mwk: you have hopes to move to nv10 soon? :o
21:48mwk: mupuf: very soon
21:48mwk: the goal would be to do the 2d test simultanously on nv4/nv5/nv10
21:49mwk: AFAICT the 2d engine should be basically the same on nv4-nv40, so I really want to write it generically
21:50mwk: 3d, of course, is a different matter
21:50mwk: now *that* is going to be a mess
21:50imirkin: nv50 2d shouldn't be that much harder
21:50mupuf: imirkin: or the lack of it?
21:51mwk: imirkin: nv50 2d is a completely different beast
21:51imirkin: mwk: yeah, just ... not a very complex one
21:51mwk: oh really?
21:51imirkin: mwk: i guess i dunno. but you can't do THAT much with it. it's pretty much all the nv04_2d stuff but without the silly object things
21:52imirkin: [i never fully figured that stuff out tbh]
21:52mwk: it's a part of the main 3d pipeline of the card
21:52mwk: that alone makes testing it a pain
21:52imirkin: yeah i guess
21:53mupuf: imirkin: when did they get rid of it?
21:53mwk: mupuf: not yet
21:53imirkin: mupuf: dunno. still there on pascal afaik
21:53mupuf: oh, I may be confused with intel (?)
21:53imirkin: amd radeon, probably
21:53imirkin: the GCN gpu's got rid of their 2d engine
21:53mwk: the silly object things were gone on G84, but the actual 2d functionality is still there
21:53mupuf: so, what can it do?
21:54mwk: three things
21:54mupuf:expected blits to be done by pcopy
21:54imirkin: pcopy is limited in what it can do
21:54mwk: solid drawing, blit with scaling, image from cpu upload with stretching
21:54mwk: all 3 support a lot of funny raster ops, too
21:55mupuf: I see, so, the display controller is basically more complex than the 2d engine :D
21:55mwk: clipping, a few kinds of blending, logic ops involving a repeating pattern, color key
21:55mwk: and of course, color format conversion
21:56mupuf: I see. Do we even make use of this engine?
21:56imirkin: 2d engine? sure, in the DDX
21:56mwk: also, converting paletted images to RGB
21:56imirkin: and for blits in mesa
21:56mwk: ie. lots of shit
21:56imirkin: [when the 2d engine supports the stuff, otherwise we hit the 3d engine]
21:57mwk: anyway, nv4-nv40 2d engine is basically unmodified (same registers, except perhaps at different mmio addresses), and separate from 3d
21:57mupuf:obviously should pay more attention to the rendering side
21:58mwk: G80 exposes more or less the same functionality, but with a new hw implementation integrated with the 3d pipeline
21:58imirkin: it's a lot of information to keep track of
21:59mwk: the actual G80 even exposed the old classes for compatibility, but G84 nuked them
22:03mwk: it should be possible to take the nv4 2d hwtests and make them pass on nv40 with just minor hammering here and there
22:03mwk: but for 3d... let's see
22:05mwk: nv1 "3d", nv3 d3d0, nv4 d3d5, nv4 d3d6, nv4 emulation of nv3 d3d0, nv10 celsius, nv10 emulation of nv3 d3d0, nv10 emulation of nv4 d3d5, nv10 emulation of nv5 d3d6, nv20 kelvin, nv20 emulation of nv10 celsius, nv30 rankine, nv30 emulation of nv20 kelvin, nv40 curie
22:05mwk: each of them different, each of them alone more complex then the whole 2d pipeline
22:06imirkin: although some easier to do once others are done :)
22:07mwk: yeah, well
22:07mwk: the emulations should just need figuring out how the card hammers a square peg into a round hole
22:08mwk: but it's still a separate thing that needs its own RE
22:08mwk:, in particular, is interested in the hw nv20-to-nv30 vertex shader ISA translator
22:09mwk: quite impressive
22:12karolherbst: anybody else want to join me on the 33c3? tomorrow starts the ticket sales
22:13mwk: karolherbst: hm, I'm going to try pestering my manager about it
22:33imirkin: skeggsb: could there be an issue on g80 with parallel context switches?
22:34skeggsb: there *could* be, but i don't know
22:34imirkin: skeggsb: there's been an issue since forever that reads like things got "desyncrhonized"
22:35imirkin: (on nv50-era gpu's)
22:35imirkin: cache errors, etc
22:43karolherbst: mwk: awesome !
22:48mupuf: ok, so, WTF is going on with this UNK18 table? It obviously is related to how to scale the PWM value for the fan
22:48mupuf: I found 2 16-bit fields that affect the value
22:48mupuf: but linearity is not exactly what I get out of these
22:49mupuf: most of the time they are though
22:49mupuf: if a = 1000 and b = 0, I get c
22:49mupuf: if b = 1000 then I get 2c
22:49mupuf: err, both a and b = 1000
22:50mupuf: that's the only nice property I found about them
22:50mupuf: but it is not true for all the values
22:51mupuf: I failed to identify other variables at play
22:52karolherbst: maybe those values are defined up to 1000 and then it gets undefined?
22:52karolherbst: did you scan over all vbios to get the range?
22:54mupuf: when I fix b and just sweep through a, I get:
22:54mupuf: 1) a plateau to $max_pwm whose length depends on b
22:54mupuf: 2) a linear increase after that, with the exception of 3)
22:54mupuf: 3) a discontinuity in the increase: the value suddenly reset to 0 and then goes from 0 to 10, then 100, ... until the value cannot fit 32 bits ... and then we are back to the linear part of 2)
22:55mupuf: the position of 3) also depends on a and b
22:55mupuf: karolherbst: I did, 2 weeks ago, but I don't see the point
22:55mupuf: we have to reproduce the behaviour anyway
22:56mupuf: hmm, I wonder if ...
22:56mupuf: maybe there are two values, one for 0% of powe
22:56mupuf: and one for 100% of power
22:57mupuf: that could explain some of this insanity
22:57mupuf: I always test at 99% of the power(the blob ignores everything when setting to 100%, that's a bug of nvidia)
23:02mupuf: ok, can I set the fan speed with nvidia-smi :)
23:22mwk: the algorithm nv4 uses to select rop formats seems freakishly complex
23:22mupuf: value a does not affect the output of the fan speed when it is set to 0%
23:22mupuf: b does
23:22mwk: good thing they expose the result via mmio, I'd go crazy trying to determine it experimentally from rop results
23:22mupuf: let's reverse b now, I am sure it will make it clear what is going on
23:22mwk: well, crazier
23:23mupuf: ah ah
23:27karolherbst: mupuf: maybe a is a factor and b something non factor like?
23:27karolherbst: but I guess this would be too sane
23:28karolherbst: so it is something odd
23:29mupuf: nope, it seems like b is the factor for 0% and a is for 100%
23:35mupuf: Now, I see a square signal going up :D
23:36karolherbst: I think somebody just had some fun at nvidias
23:36mwk: alright, NV4 craziness understood
23:36mwk: now... NV5
23:37airlied: skeggsb: backmerged v4.9-rc4 into drm-next
23:38mupuf: Well, that or the 16-bit value is also a bitfield
23:38karolherbst: why not both!
23:39karolherbst: maybe it is a ... 9 bit value with 4 high bits as a bitfield
23:39karolherbst: and the other low bits as well!
23:39imirkin: mupuf: could this cause non-working fan control on my GM107? https://github.com/skeggsb/nouveau/commit/c48346e5fa2c996f4d2dc409d902314f18c19516
23:39imirkin: [or rather, lack of this patch]
23:39karolherbst: imirkin: seems plausible to me
23:40mupuf: i2c fans are long gone, AFAIK
23:40karolherbst: mupuf: you would be surprised
23:40mupuf: especially on maxwell where they went into a lockdown mode
23:40mupuf: imirkin: I am quite positive that the issue you have with fan management is what I am working on
23:41karolherbst: mupuf: nope
23:41karolherbst: mupuf: and you know why?
23:41karolherbst: he has no table 0x18
23:42mupuf: then I checked the wrong vbios last time
23:42karolherbst: I could have his old gm107 one?
23:42karolherbst: no clue
23:43karolherbst: pwm fan
23:43imirkin: mupuf: excellent
23:44imirkin: i only have one GM107
23:44mupuf: imirkin: if karolherbst is right, then it is not
23:44karolherbst: mupuf: I guess for his GPU we might need to parse 0x58 and 0x5c
23:44imirkin: look at the -vbios.rom files there for details
23:45karolherbst: that's the one I have
23:45karolherbst: table 0x58 and 0x5c it is
23:45mupuf: karolherbst: quite likely, yeah
23:45mupuf: but it is the same problem IMO
23:46karolherbst: just different table
23:46mupuf: quite likely
23:46karolherbst: imirkin: you could try and verify it with the blob
23:47karolherbst: and see if the fan starts to turn up between 86 and 90 °C
23:47mupuf: karolherbst: a mmiotrace is enough
23:47karolherbst: ohh for the value
23:47karolherbst: yeah, k might be
23:47mupuf: you should see an unually low value for the duty
23:48karolherbst: let me check something
23:48imirkin: i could... but ... i think my mmiotracing days are over
23:49karolherbst: huh, that's obvious... wait
23:49mupuf: imirkin: ahaha
23:50karolherbst: okay, another table fan related as it seems
23:50skeggsb: airlied: thanks!
23:50karolherbst: mupuf: fan div: 135000 vs 25000
23:50karolherbst: this is quite a big of a difference
23:50skeggsb: i've fixed karol's passive adapter regression, just hunting down the mst issue on my laptop with that dell monitor and i'll get you a -next
23:50mupuf: karolherbst: sure, and?
23:51karolherbst: that doesn't explain the super low duty
23:53karolherbst: guess: 0x54 table
23:54karolherbst: ... nope, nvm
23:57mupuf: I mean, what the flying fuck?
23:58imirkin: mupuf: at what values does it invert?
23:58imirkin: looks like 128 for getting "back"
23:58imirkin: what is it on the low end?
23:59mupuf: first column = value for 6b13
23:59mupuf: the second one is PWM in hex
23:59karolherbst: mupuf: okay, I think I have a guess