01:19gdk: hello, I started looking into the tex maxwell instruction again
01:20gdk: it seems to have two input registers
01:20gdk: on a 2D textures, are those two inputs register X/Y of the texture coord?
01:20gdk: it seems that only one is used
01:24imirkin_: that's surprising
01:24imirkin_: for tex or texs?
01:24imirkin_: for tex, each argument is a quad-arg
01:25imirkin_: here's the saga of how it all works: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#n841
01:25gdk: for tex
01:25imirkin_: those values are partitioned like this: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp#n2143
01:25imirkin_: into the 2 up-to-quad args
01:36imirkin_: with texs, the args are single values
01:43gdk: tex nodep $r4 $r4 0x0 0x8 t2d 0x6
01:43gdk: this is the instruction, second reg is 0x0
01:43gdk: so I believe that r4/r5 are X/Y
01:44gdk: for the tex coord
01:46imirkin_: and the .ba texture colors end up in $r4/r5 as a destination
01:47gdk: so 0x6 is "ba"?
01:47imirkin_: er, no. it's gb
01:47gdk: ah, thanks
01:48gdk: I guess that those names are missing from envydis and it just printed the raw value
01:48imirkin_: more like ... why bother having the 16 different values when you can just show the mask
01:48gdk: oh yea that is a mask heh
01:48imirkin_: it's also what nvdisasm does, fwiw
01:48gdk: I noticed a bit after I said that
01:49imirkin_: for some targets we actually print it was like tex nodep #:$r4:$r5:# ...
01:49gdk: I just assumed because for texs it shows it (althrough I think this one isn't using a mask)
01:49imirkin_: but we didn't do it for maxwell i guess
01:49imirkin_: for texs it stores rg in one dest, and ba in another dest
01:50imirkin_: although iirc there IS a mask to control it
01:50imirkin_: so more like values 1,2 in first dest, and 3,4 in second dest
01:50imirkin_: in this case, it could use just one dest
02:23gdk: what about this one: texs nodep 0x0 $r6 $r6 $r7 0x8 t2d rgb
02:23gdk: r is written to r6, right?
02:28imirkin_: i'm ... not sure.
02:28imirkin_: rgb means there are 3 outputs
02:28imirkin_: but there are only 2 registers worth there
02:28imirkin_: so... dunno.
02:28imirkin_: i've never played with texs before
02:29gdk: r being written to r6 is the only thing that makes sense for this shader tbh
02:29imirkin_: yeah. i'm guessing that "rgb" is actually wrong
02:29gdk: althrough I would expect rg being written to r6/r7
02:29imirkin_: try decoding that op with nvdisasm
02:30gdk: does nvdisasm support the raw maxwell machine code?
02:32HdkR: nvdisasm -b
02:33HdkR: `nvdisasm -b SM53 <raw file>` specifically
02:34imirkin_: it's picky, sadly
02:34imirkin_: you can't just feed it a single instruction
02:34imirkin_: it wants a block with sched info
02:34HdkR: ah right. Need a full block
02:34gdk: I have the full shader file so I think its fine
02:36gdk: does anyone know the min version of the cuda toolkit with maxwell support?
02:36imirkin_: like 6.0?
02:36imirkin_: or 5.x
02:36imirkin_: -b SM50 is probably what you want
02:37HdkR: Wikipedia claims 5.0
02:37imirkin_: HdkR was just being all fancy -- SM53 == Tegra X1 iirc
02:37HdkR: I try to be as fancy as possible
02:38gdk: ah thanks
02:38gdk: would be nice if they had a standalone download for this tool as I need to dl 1gb for a single tool :P
02:38HdkR: imirkin_: Don't you want to also look at all the FP16 instructions that aren't available on desktop? :P
02:39imirkin_: i think you know the answer to that question
03:04HdkR: imirkin_: "Yes I would love to beat my head in to a wall" ?
03:04imirkin_: you know me too well
08:28amitprakash: What firmware do I need for nouveau for Kepler family cards?
08:31amitprakash: Currently, I am getting a nouveau 0000:41:00.0: DRM: GPU lockup - switching to software fbcon
08:31amitprakash: nouveau 0000:41:00.0: fifo: read fault at b59418e000 engine 0b [HOST4] client 06 [HOST] reason 00 [PDE] on channel 0 [007fbd4000 DRM prior tot hat
11:31imirkin: amitprakash: everything you need should be in the kernel
11:32amitprakash: imirkin, welp.. no idea why nouveau is crashing then
11:32imirkin: is this a GTX 660 by any chance?
11:33amitprakash: GT 710
11:34amitprakash: This happens
11:35imirkin: is there something odd about your setup?
11:36imirkin: i.e. something different than "plain ol' desktop just like everyone else has"
11:36amitprakash: Hardware wise.. Amd TR box with a pansy GT 710
11:36amitprakash: Software wise, gentoo
11:37imirkin: yeah ok. so not like a VAX with a PCI bus plugged into USB and then converted to a serial bus.
11:37imirkin: sorry, not sure =/
11:39karolherbst: amitprakash: try to reclock to some pstate
11:39karolherbst: allthough I don't think this is due to instability of anything
11:39karolherbst: but if we are out od idea, anything might help
11:40karolherbst: imirkin: any clue what that UNSUPPORTED_KIND might be about?
11:41imirkin: but i don't think he's getting those specific errors
11:41imirkin: people just like to point to random bugs saying "mine's just like this one"
11:41amitprakash: fifo: write fault at 0003228000 engine 1b [CE2] client 18 [GR_CE] reason 0c
11:41amitprakash: This happens
11:42imirkin: karolherbst: unsupported_kind is when you try to use a PTE with a kind set which is not supported by whatever operation
11:42karolherbst: ahh, okay
11:42amitprakash: May 31 17:12:29 godam.malana kernel: nouveau 0000:41:00.0: X: failed to idle channel 3 [X]
11:42imirkin: e.g. if you try to use the copy engine, but the kind set in the cmdstream doesn't match up to the one in the PTE
11:42amitprakash: nouveau 0000:41:00.0: X: failed to idle channel 3 [X]
11:43karolherbst: amitprakash: mind sharing your dmesg with us? (pastebin it somewhere)
11:43amitprakash: And finally, read fault at bc6ea84000 engine 07 [HOST0] client 06 [HOST] reason 00 [PDE] on channel 2 [007fb3a000 X]
11:43imirkin: (kind = memory kind)
11:44karolherbst: imirkin: okay so basically if you want to copy from sys to sys, but you get an address in vram?
11:44imirkin: nouveau 0000:41:00.0: SME is active, device will require DMA bounce buffers
11:44imirkin: karolherbst: kind is the memory type...
11:44imirkin: wtf is SME
11:44amitprakash: Oddly enough, the device works fine on ubuntu live cd using nouveau itself
11:45karolherbst: imirkin: amd memory encryption
11:45imirkin: amitprakash: fifo: read fault at bc6ea84000 engine 0b [HOST4] client 06 [HOST] reason 00 [PDE] on channel 0 [007fbd4000 DRM]
11:45amitprakash: However, the device is detected differently on the live cd.. GK208 on live cd vs GK208B on install
11:45imirkin: i think that means that the GPU is unable to dma to/from sysram
11:45karolherbst: imirkin: basically the memory is encrypted by the MMU or something
11:46imirkin: can you disable this SME thing?
11:46amitprakash: Let me try :)
11:47karolherbst: mhh, I kind of hoped that thing should work transparently, but maybe we dont set things up correctly? or the GPU just doesnt care?
11:47mwk: karolherbst: memory kind is basically tiled vs non-tiled
11:47karolherbst: mwk: ahh, got it
11:47mwk: well, actually it's way more detailed for tiled types, since it includes compression and whatnot
11:47mwk: but simple engines like CE only really make a tiled/non-tiled distinction
11:47imirkin: and it doesn't strictly have to do with tiling
11:48imirkin: well, micro-tiling yes. but not macro-tiling
11:48mwk: it's not like you can have one without the other though
11:49imirkin: you can have macro tiling without micro ;)
11:49imirkin: [i think]
11:49mwk: that should blow up with an error on most clients
11:49mwk: though not all
11:50imirkin: perhaps. i can't say i've tried it
11:50mwk: ohh wait
11:50mwk: I forgot
11:50mwk: UNSUPPORTED_KIND happened when you specify a memory kind with compression and set the aperture to system RAM
11:50mwk: which is not allowed
11:51imirkin: oh duh. no compression in sysram.
11:51imirkin: i wonder if that can happen to us...
11:51mwk: or hm
11:51imirkin: where we allocate a buffer in sysram but forget to clear out compression
11:52mwk: wait, that's a different error
11:52mwk: I fucked up completely
11:52imirkin: yeah. i'm pretty sure that's quite impossible with nouveau
11:52mwk: it seems UNSUPPORTED_KIND is just... "invalid enum" for the kind
11:53amitprakash: imirkin, wow.. that fixed it!
11:53amitprakash: Thank you!!
11:54imirkin: ok, so now the question is... how does one get this stuff to work with SME
11:54imirkin: this is the first i'm hearing of it
11:54imirkin: skeggsb_: --^
11:59karolherbst: imirkin: well, it is kind of new
11:59karolherbst: like 2017/2018 new
12:00karolherbst: imirkin: https://en.wikipedia.org/wiki/Zen_(microarchitecture)#Enhanced_security_and_virtualization_support
12:01mwk: yea, it's one of these hilarious ideas to make someone with physical hw access unable to access its memories
12:01imirkin: but it shouldn't affect device DMA, right?
12:01karolherbst: well dmesg says this: "SME is active and system is using DMA bounce buffers"
12:01mwk: DMA to an encrypted memory page doesn't end well
12:02imirkin: ok, so the encryption/decryption is only for CPU access of memory?
12:02imirkin: everyone else just gets what's in ram?
12:02imirkin: i guess that makes sense.
12:02karolherbst: well you have to be part of that VM "domain"
12:02imirkin: so we have to be careful to make sure our sysram buffers are allocated without this "encrypt me" bit set
12:02imirkin: and when i say "we", i mean "ttm"
12:03karolherbst: well, ttm could just open up a new VM
12:03karolherbst: but that won't end well in regards to stuff like HMM, because then we end up with 2 VMs
12:04karolherbst: imirkin: but I am not sure if you can do that at all anyway
12:04karolherbst: I think this is a all or nothing kind of thing
12:04imirkin: the encryption is set on a per-page level
12:04imirkin: should work
12:04imirkin: at least in theory
12:04mwk: well, DMA *is* possible with a bounce buffer
12:04mwk: which means it's somehow possible to allocate a non-encrypted bounce buffer, right?
12:05karolherbst: mwk: it seems like there is support for this in the kernel in theory
12:05karolherbst: maybe we just don't set things up correctly
12:06karolherbst: imirkin: anyway, intel also has a feature lik this
12:06imirkin: ... or we can just not encrypt the pages that need to be accessed by the gpu
12:06imirkin: which would avoid the need for a bounce buffer
12:06imirkin: which feels like a win
12:07karolherbst: called TME
12:07imirkin: coz it's one letter better than SME?
12:07karolherbst: it was anounced after the AMD thing :)
12:07karolherbst: and it is called "Total Memory Encryption"
12:08karolherbst: imirkin: but I think storing stuff unencrypted is the less prefered way if the system already enables that system
12:09imirkin: i think using bounce buffers is the less preferred way
12:09karolherbst: depends on your thread model
12:09imirkin: threat, presumably? :p
12:09mwk: well, it's not like GPU can do anything with encrypted data
12:10mwk: so storing that stuff unencrypted is necessary anyway
12:10karolherbst: anyway, we have to be able to deal with that regarding HMM anyway...
12:10karolherbst: this is gonna be painful
12:10mwk: might as well avoid the bounce buffer
12:10mwk: what the fuck is hmm
12:10karolherbst: mwk: sharing a VM between CPU and GPU
12:10karolherbst: and accessing sysmam thorugh g with a CPU VM address
12:11karolherbst: so you do malloc in your C app and push that pointer into a compute kernel and the GPU can just read that memory though ld g
12:11imirkin: mwk: sync'd up mmu settings between cpu and gpu
12:11karolherbst: there is page table migration going on though
12:11imirkin: mwk: so you can pointer-chase on either gpu or cpu
12:11karolherbst: so maybe it would just work because the GPU page faults, we move the page from host to VRAM and resume the shader/kernel
12:12karolherbst: which only works with pascal+ anyway
12:13karolherbst: mwk: it can be used to implement fine grained system SVM, an optional OpenCL 2.0 feature
12:13karolherbst: and apparently intel wants to use HMM as well
12:13karolherbst: maybe AMD as well
15:24RSpliet: karolherbst: H stands for... heterogeneous?
15:31karolherbst: RSpliet: yes
15:31karolherbst: RSpliet: we are working on getting that into nouveau for pascal+
15:31karolherbst: prior gens might be not able to use that at all sadly
15:32karolherbst: we could even make use of it in opengl or vulkan where it might be useful, but I guess this makes vram management more difficult
15:32imirkin_: you need faulting that desperately?
15:32karolherbst: imirkin_: recovery
15:32imirkin_: or rather, fault recovery
15:32karolherbst: we don't migrate pages before access
15:32karolherbst: so we only know on access what has to be migrated to vram
15:33karolherbst: I think we could also just read from sysmem where possible, but...
15:33imirkin_: ah, so you want to migrate things to vram? hm
15:33karolherbst: yeah, thats what hmm does currently
15:33karolherbst: we just populate the GPU MMU with all vm entries from the application
15:33imirkin_: well, for gpu's without fault recovery, you could Not Do That (tm)
15:33karolherbst: and if the page accessed isn't in VRAM we migrate it over
15:33karolherbst: imirkin_: right, that's why pascal+
15:34imirkin_: i mean you can still have HMM without the page migration. but i guess the theory is that it'd be way too slow.
15:34karolherbst: maybe there are other ways to implement fine grained system SVM without HMM or with a slightly modified HMM
15:34imirkin_: wait, so if the CPU tries to access the page, you migrate it back?
15:34karolherbst: imirkin_: well, with fine grained system SVM you pass application vm pointers into the GPU
15:34karolherbst: imirkin_: I think so, yes
15:34imirkin_: yes, i understand all that.
15:34karolherbst: glisse knows more about the details though
15:35karolherbst: but the point is that only one user accesses the page and doing page faults seems like a clever way to achieve that
15:35karolherbst: but anyhow
15:35karolherbst: concurrent access to pages shared by the GPU and CPU might be a stupid thing to do in the first place
15:36karolherbst: fun things happen if you access a hugepage
15:36karolherbst: like a 1G page
15:37karolherbst: no idea what the status here is though
15:50gruetzkopf: cache coherent accellerators are more fun
16:26mercury^: Hi. I want to see something before the pivot on a Macbook Pro 5,3, so I added nouveau and fbcon to the initrd. Nevertheless nothing is displayed so far. What else do I need to do?
16:57imirkin_: mercury^: "before the pivot"?
16:59pendingchaos: imirkin_: diffing between two traces, one calling EvaluateDepthValuesARB() and one not, it seems the only difference in the push buffer's is that the one with EvaluateDepthValuesARB() has "GP104_3D.0x11fc = 0x1"
16:59imirkin_: and we all know what that means ;)
17:00imirkin_: according to the switchbrew folk, http://switchbrew.org/index.php?title=GPU, that's DepthBufferResolve
17:01imirkin_: sounds like a legit thing.
17:01pendingchaos: that's convenient
17:01imirkin_: note that a lot of stuff on there is wrong, so ... watch out
17:01imirkin_: i think they got some symbols from ... somewhere
17:01imirkin_: and they denote method id's with a stride of 1 instead of 4
17:02Kevlar_Noir: what packages are usefull for a dual screen config ?
17:03imirkin_: same ones that are useful for a single screen config
17:03pendingchaos: I guess I'll throw in a resolve_depth_buffer() method or something for pipe_context
17:04Kevlar_Noir: yeah but
17:04imirkin_: pendingchaos: sounds right
17:04Kevlar_Noir: It's great nouveau is working better than nvidia
17:05Kevlar_Noir: when I watch my two screens I can FEEL it
17:05imirkin_: you can feel the blob code leaving your body?
17:05imirkin_: if so, might want to see a doctor about that :p
17:07Kevlar_Noir: about my mydriase ?
17:08Kevlar_Noir: ok I will talk about that. I will also talk about the risky echo 0f >
17:12Kevlar_Noir: the compton dilemna
17:21mercury^: imirkin_: before the actual root filesystem is mounted and the initrd init executes the actual init.
17:22imirkin_: mercury^: oh. then you have to build it in.
17:22mercury^: imirkin_: yeah, I included nouveau and fbcon in the initrd.
17:22imirkin_: so ... not built in.
17:22imirkin_: you need to build it in.
17:23mercury^: imirkin_: why do I need to build them in when they work as they should when they are loaded later on?
17:23imirkin_: if you want nouveau to load before modules are available, then it can't be a module
17:23imirkin_: perhaps i'm not understanding what you're going for.
17:24mercury^: imirkin_: there are modules available!
17:24mercury^: imirkin_: I just want to have video output before the root filesystem is mounted. The initrd should already be available.
17:24imirkin_: oh. so then that should be fine.
17:24imirkin_: what's the problem?
17:24imirkin_: initrd normally takes zero time though
17:25imirkin_: so the delta would be low
17:25imirkin_: between it being loaded by initrd and loaded off root fs
17:25imirkin_: unless you have some kind of crazy going on
17:25mercury^: imirkin_: it's so that I can type in the password for the root partition.
17:25imirkin_: and does your init(rd) script load nouveau?
17:26imirkin_: modules don't just load themselves
17:26imirkin_: they have to be loaded
17:26mercury^: I think that it does. I did not write the script myself, but I have studied it in response to my problem, and as far as I understand it should load them.
17:26imirkin_: well ... like i said. it should work.
17:26mercury^: So, once fbcon and nouveau are loaded everything should work? Is there anything else that needs to be in place?
17:26imirkin_: so my guess is that you didn't add enough modules
17:26imirkin_: nouveau depends on like 20 other things
17:26imirkin_: which in turn depend on 20 other things
17:27mercury^: Well, the script that compiles the initrd should take care of that.
17:27mercury^: Maybe it doesn't properly..
17:27imirkin_: when nouveau loads, it takes over fbcon
17:27imirkin_: assuming it's the primary video device, maybe?
17:27imirkin_: i.e. that vga io is routed to it
17:29mercury^: imirkin_: well, everything works when nouveau and fbcon are loaded "later".
17:29imirkin_: i don't think fbcon can be a module btw
17:29mercury^: I was wondering if they need something in /dev or so.
17:30imirkin_: it's a kernel driver, it doesn't care about what's in userspace
17:30imirkin_: my guess is that it's not being loaded
17:30mercury^: Hmm, I see it in lsmod on that machine when I boot into the installation medium. (I did not yet boot into the actual installation because I do not want to type the password in the blind.)
17:30imirkin_: right before you type your password in
17:30imirkin_: have it run dmesg
17:30imirkin_: and see if nouveau actually loads
17:31imirkin_: or have it run lsmod
17:31imirkin_: oh - right. you're running blind. super.
17:31imirkin_: tbh i'd just throw in an explicit "modprobe nouveau"
17:31imirkin_: and be done with it
17:31mercury^: Well, I can rebuild my initrd to be able to boot into the installation medium. Then I can check if it loads.
17:31imirkin_: worst thing it can do is fail :)
17:32mercury^: imirkin_: as far as I can see that is what I have done. The initrd-init eats a "modules" parameter in which I supply nouveau.
17:32imirkin_: but there's like a 99% chance it's not working properly
17:32imirkin_: why not just add the command into the init script directly?
17:32mercury^: I can try that, sure.
18:28mercury^: imirkin_: turns out the initrd was not built properly. I should have checked that first. >_>
18:34mercury^: Another thing: I have the impression that the video card is running a bit hotter than it should. Is that because of gmux or are there some deficiencies with nv50 power saving?
18:46mercury^: https://help.ubuntu.com/community/UEFIBooting#Selecting_the_graphic_card says that I can disable the dgpu with grub – would I still use nouveau as driver?
19:59imirkin_: mercury^: sorry, i know almsot nothing about the specifics of macs
19:59imirkin_: pmoreau: perhaps you can answer --^
20:00pmoreau:is still catching on the logs
20:01pmoreau: mercury^: I don’t remember, but does that MBP have one or two GPUs? i.e. just the G96, or also an MCP79?
20:03pmoreau: If you have both, I should be able to give you some patches to automatically suspend/resume the discrete.
20:48mercury^: pmoreau: looking at the model description it should have two, but I have found no indication of the second one so far.
20:48pmoreau: If you run `lspci -d 10de:` how many do you get?
20:49imirkin_: oh, it's the MCP79/G96 combo one?
20:49imirkin_: [or might be]
20:49pmoreau: I think so
20:49pmoreau: I think mine is a 5,3 as well
20:50mercury^: pmoreau: yeah, I find MCP79 in the dmesg. (busybox lspci..)
20:51pmoreau: And which one is the main one? (If you just run `glxinfo | grep OpenGL` for example?)
20:51mercury^: But I am not just imagining things and the dgpu is running hotter than it should, yes? Is that just because it is not turned off?
20:51pmoreau: 1) It’s not off, 2) there is no power gating, and 3) it’s running at almost max clock
20:52pmoreau: But you can reclock both cards! \o/
20:52mercury^: Cool. :)
20:52mercury^: No glxinfo yet, so far it's basically just busybox.
20:53mercury^: Can I read that info somewhere in /sys?
20:54pmoreau: In /sys/kernel/debug/vgaswitcheroo/switch, you will see the status of the different cards, and I think it tells which is the one driving the X session.
20:54mercury^: Otherwise it may have to wait a bit.
20:54mercury^: pmoreau: well, no X yet.
20:54pmoreau: Then, in dmesg maybe: look which card is allocating a 1440x900 fb
20:55mercury^: 0000:03:00.0, does that make sense?
20:56pmoreau: That should be the MCP79 IIRC, and 0000:02:00.0 is the G96 one.
20:56pmoreau: If you look a bit earlier, you should have messages like "nouveau 00003:00.0: MCP79"
20:56mercury^: So I could just switch that one off and turn the MCP79 to the minimal frequency for now?
20:57mercury^: Yep, it's the MCP79.
20:57pmoreau: Let’s see, how does one reclock again.
21:00pmoreau: mercury^: Run `echo 07 > /sys/kernel/debug/dri/0/pstate` and `echo 07 > /sys/kernel/debug/dri/1/pstate`
21:00pmoreau: That should make the laptop run cooler.
21:01mercury^: I don't have /sys/kernel/debug, probably some grsec stuff. Is there another path to those?
21:01pmoreau: I don’t think so
21:02mercury^: Can I do it in C?
21:03pmoreau: Absolutely no idea
21:03pmoreau: karolherbst: ^
21:07mercury^: I have /sys/class/drm/card0/power, is that any good?
21:08pmoreau: That’s something different
21:08imirkin_: debugfs is probably not mounted
21:08imirkin_: mount -t debugfs none /sys/kernel/debug
21:09mercury^: imirkin_: /sys/kernel/debug does not exist yet, and I do not have permissions to create it.
21:09mercury^: Can I create it outside of /sys?
21:10imirkin_: is /sys mounted?
21:10imirkin_: /sys should have a kernel/debug directory in it
21:10imirkin_: which is empty
21:10imirkin_: and then you mount debugfs over it
21:10imirkin_: but yeah, you can mount it whereever
21:10mercury^: No, that directory does not exist. I suspect that is because of grsec.
21:10imirkin_: vfs doesn't care
21:10mercury^: I will just try to mount it elsewhere.
21:10imirkin_: cat /proc/filesystems
21:10imirkin_: is debugfs in there?
21:11mercury^: Now it says ‘no such device’
21:12mercury^: Yeah, it's not there.
21:12mercury^: Do I have to load a module?
21:12imirkin_: ok, so then you won't have it
21:12imirkin_: it's either built or not
21:12imirkin_: sounds like 'not'
21:13mercury^: Hmm. Controlling the power state of the cards should not really be a debug feature though. Is there not some other interface that I can use?
21:14pmoreau: There is the Nouveau option, but I don’t know how it works with multiple cards.
21:15mercury^: ‘Nouveau option’ – do you mean the X driver here?
21:17pmoreau: No, I mean the kernel module, like "nouveau.debug=PDISP=trace", which you can specify on the kernel command line, or when loading nouveau manually via modprobe.
21:17mercury^: What would be the option to turn down the power consumption?
21:18pmoreau: There should be one to change the default clock, but that’s about it.
21:18pmoreau: Do you remember which one it is, imirkin_ ?
21:18pmoreau: That one, thanks
21:18mercury^: But if debugfs is the best way I will see if I can build another kernel.
21:19mercury^: What would the debugfs command do?
21:19pmoreau: The debugfs file lists the different performance level available, and if you write a level to it, it will change to that level.
21:20pmoreau: For example, if I can the pstate of my GK107, I get this: https://hastebin.com/olowobotep.pl
21:21pmoreau: (Current clock is slightly below the level 07) If I want more perf, I just do `echo 0f > /the/pstate/file` to reclock to that level.
21:22pmoreau: mercury^: BTW, if you are going to rebuild a kernel, I should give you some patches to automatically suspend and resume the discrete GPU.
21:22karolherbst: you can set it on module load
21:23karolherbst: I think NvClkMode=15 works, maybe even NvClkMode=0xf
21:23karolherbst: mercury^: ^^
21:23mercury^: So NvClkMode=07 for minimal power consumption?
21:23karolherbst: kind of
21:23karolherbst: usually the GPU boots in a kind of lower power state
21:23karolherbst: allthough the voltage might be not set up correctly
21:23karolherbst: Lyude: can you document your power gating options on https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ ?
21:26pmoreau: mercury^: 07 doesn’t exist on those; 03 is the lowest (I just checked)
21:27mercury^: “usually the GPU boots in a kind of lower power state“ – so it will not get much cooler?
21:27Lyude: karolherbst: sure thing; I'll try to do it on my way home from the office but if I forget ping me
21:27Lyude: also: unless someone pushed them I'm pretty sure I still hve powergating fixes on the nouveau mailing list that need review :s
21:27pmoreau: mercury^: That wasn’t the case on pre-Kepler; my G96/MCP79 boots on mid-/high-clocks.
21:28mercury^: And NvClkMode will set the option for both cards simultaneously?
21:30pmoreau: mercury^: I have the following patches locally (I haven’t tried them on my G96/MCP79 laptop, but they do work on a more recent MBP, which still has the apple-gmux): https://hastebin.com/usegetodot.cs https://hastebin.com/ovoxewusay.m and https://hastebin.com/vuruyikesa.cpp
21:30pmoreau: (Those patches are from l1k)
21:30karolherbst: Lyude: awesome, thanks!
21:31pmoreau: I don’t know whether that option will set it for both, but with the patches, hopefully the discrete should go to sleep if not used.
21:31imirkin_: mercury^: karol was talking about later GPU's
21:31imirkin_: yours boot into middle or high clocks, depending
21:34mercury^: Can I see which pstate is currently selected on a system with debugfs?
21:35imirkin_: cat the file
21:35imirkin_: the last entry is the current settings
21:36mercury^: On a different system I have another NV50, which gives me:
21:36mercury^: 20: core 513 MHz shader 1188 MHz memory 792 MHz
21:36mercury^: AC: core 198 MHz shader 1188 MHz memory 396 MHz
21:36mercury^: So that one is already in "power saving" mode?
21:36imirkin_: the last line is the current clocks
21:37imirkin_: it boots to whatever it boots to
21:37imirkin_: esp earlier boards might only even have one pstate
21:55mercury^: pmoreau: why are those patches not part of nouveau proper?
21:58pmoreau: mercury^: There are still issues on the MBP retina models, where you have a chance to hang the laptop, IIRC.
22:46Lyude: karolherbst: what is the git repo for the nouveau wiki on fdo?
23:18karolherbst: Lyude: "git://anongit.freedesktop.org/wiki/nouveau"
23:33pendingchaos: imirkin_: are these comments good: https://hastebin.com/noripupeho.cpp?
23:33imirkin_: extremely good
23:33imirkin_: thank you very much