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