05:27 mupuf: karolherbst: nice!
16:55 marmistrz: I'm wondering: will such a thing work:
16:55 marmistrz: have both nvidia and nouveau installed on my system, nvidia blacklisted
16:55 marmistrz: whenever I need to compute something on my graphics, I modprobe -r the nouveau
16:55 marmistrz: modprobe nvidia
16:56 marmistrz: calculate, calculate
16:56 marmistrz: finished: modprobe -r nvidia, modprobe nouveau
16:56 marmistrz: can something go wrong?
16:56 towo`: modprobe -r the nouveau would not work
16:57 towo`: on debian it would work, but only with the alternatives system and a reboot
17:00 mupuf: towo`: you don't need a reboot
17:00 mupuf: I think nvidia leaves the gpu in a certain state that nouveau can't pick up after though
17:02 Tom^: mupuf: it sadly does so after a certain blob 3xx series
17:02 Tom^: perhaps its no longer the case, but yeah
17:02 mupuf: yeah, that's what I was refering to
17:02 mupuf: would be nice to figure out what the problem is though
17:09 marmistrz: ok, and one direction: is it possible to switch nouveau -> nvidia during runtime?
17:09 marmistrz: why won't modprobe -r nouveau work?
17:10 mupuf: you will have to kill your x server, at the very least
17:10 Tom^: yeah from nouveau to nvidia works
17:10 imirkin_: https://nouveau.freedesktop.org/wiki/KernelModeSetting/
17:10 imirkin_: take a look at the "unloading nouveau" portion of it
17:10 Tom^: damnit you were 3 seconds faster then me
17:10 imirkin_: also if you're driving displays, nvidia does something to display that nouveau can't properly undo, so displays won't work if you switch
17:10 Tom^: :P
17:16 marmistrz: driving displays?
17:16 imirkin_: driving displays.
17:17 imirkin_: like when you go to the store
17:17 imirkin_: in your truck
17:17 imirkin_: and buy a bunch of TV's
17:17 imirkin_: and then drive them home
17:18 Tom^: what i think he just said is that optimus works, but driving one of those displays bought with a truck and brought them home and plugging them in to a nvidia gpu wont properly undo.
17:19 imirkin_: ;)
17:52 marmistrz: and what would happen if I simply modprobed -r nouveau? I have the Intel graphics card as my main one
17:52 marmistrz: (would try myself but I'm afraid of damaging my hw ;) )
17:57 karolherbst: marmistrz: i do it all the time
18:06 marmistrz: modprobe -r nouveau doesn't work: modprobe: FATAL: Module nouveau is in use.
18:07 marmistrz: It seems that nouveau is used by many other modules: https://zerobin.net/?6a800a51cb90808d#9FdHwPNAvUaRimsg1yrTE+iR0JZIz/vdfmSUzJiCylk=
18:07 marmistrz: (but basically the intel modesetting driver should be the main one)
18:07 karolherbst: nonpe
18:08 karolherbst: nouveau uses those
18:08 karolherbst: the Xorg server is using Nouveau
18:09 marmistrz: a, ok
18:11 marmistrz: is it possible to unload that from Xorg? `echo 0 > /sys/class/vtconsole/vtcon1/bind` doesn't do the trick
18:11 marmistrz: or do I have to kill the X?
18:11 karolherbst: mhh
18:11 karolherbst: there is one hack you can use
18:12 karolherbst: https://gist.githubusercontent.com/karolherbst/4341e3c33b85640eaaa56ff69a094713/raw/c976daa9e406d37e01351357ea9d8c20d5097d66/xorg.conf.d.nouveau.conf
18:12 karolherbst: as the X config file
18:14 marmistrz: what's the main point here? As far as I understand it makes Xorg not to autodetect GPUs, we manually add the Intel Graphics.
18:14 karolherbst: dummy driver for the nouveau gpu
18:14 marmistrz: But the nv card is using neither nouveau nor nvidia
18:15 marmistrz: will it make the nv card powered off?
18:15 karolherbst: except you have display connectors on the nvidia GPU you want to use
18:15 karolherbst: no
18:15 karolherbst: X will just load no driver for the nvidia gpu
18:15 karolherbst: which doesn't matter if you only do prime offloading
18:15 karolherbst: also the X server is less affected by nouveau messing up
18:15 marmistrz: and in kernel space the nouveau will do it's power saving as usual
18:16 karolherbst: yes
18:16 marmistrz: and DRI_PRIME will work as usual, since it's kernel doing work here?
18:16 karolherbst: on a prime setup you really only need the nouveau DDX if you want to do video accel on it, but you have intel for this and to use displays connected with the nvidia GPU, which some laptops have
18:16 karolherbst: marmistrz: exactly
18:16 marmistrz: And would it be enough just to add the NvidiaCard section to my Xorg.conf?
18:17 karolherbst: doubt it, but maybe
18:17 karolherbst: I think it will only use the nvidia gpu then
18:17 karolherbst: which won't work
18:18 karolherbst: anyway, with this setting I can switch between nvidia+bumblebee and nouveau without needing to restart X, which is nice
18:18 karolherbst: I turn off/on the GPU manually with bbswitch though between switches
18:18 karolherbst: sometimes nvidia doesn't like the state nouveau leaves the card at
18:18 marmistrz: And for modesetting driver I'd use `Driver "modesetting"` instead of `Driver "intel"`?
18:19 karolherbst: well yeah, but then you need to specify the BusID for the intel GPU as well
18:19 karolherbst: which is usually PCI:00:02:0
18:19 karolherbst: lspci will tell
18:19 marmistrz: in my case nvidia is 04:00.0, intel - 00:02.0
18:19 marmistrz: does the dot matter?
18:19 karolherbst: yeah
18:20 karolherbst: you need to adjust the BusIDs
18:20 karolherbst: intel is PCI:00:02:0 and nvidia is PCI:04:00:0
18:20 marmistrz: I meant: PCI:04:00.0 or PCI:04:00:0?
18:20 karolherbst: not quite sure
18:20 karolherbst: the latter works
18:20 karolherbst: never tried the former
18:22 marmistrz: are the serverflags important?
18:22 karolherbst: I think yes
18:22 karolherbst: the trap signal one is not
18:22 karolherbst: but the autoadd thing I think is
18:58 imirkin_: oh nice, looks like VK-GL-CTS got a bunch of opengl test fixes
18:58 imirkin_: e.g. https://github.com/KhronosGroup/VK-GL-CTS/commit/79df5799eb0b77e3f1a335f92a0a961b5db0461c
18:58 imirkin_: i was wondering what was going on with that...
19:00 karolherbst: nice
19:01 imirkin_: gotta love this type of change: https://github.com/KhronosGroup/VK-GL-CTS/commit/9d9cc029ff110ad14dbae566f5d0d5764b8d4472
19:01 karolherbst: best ones
19:01 imirkin_: oh - well at least this one is "spec issues"
19:01 imirkin_: they also have a "driver issues" file
19:02 karolherbst: "driver issues"? why is that
19:02 imirkin_: coz some khr member didn't feel like fixing their driver?
19:02 karolherbst: isn't like everything a driver doesn't pass a driver issue the driver should fix?
19:02 karolherbst: ohhhh I see
19:02 karolherbst: I guess too many applications depending on that error?
19:02 imirkin_: one way to fix such an issue is to remove the test from the must-pass list ;)
19:04 imirkin_: https://github.com/KhronosGroup/VK-GL-CTS/commit/6e1b81eef515fdd8e61fc7b53c7d6d2e8f3dc9c4
19:04 imirkin_: well that's just super.
19:04 karolherbst: I like the commit message
19:04 karolherbst: was this even public information that there might be an OpenGL 4.6 spec?
19:05 imirkin_: dunno. cat's out of the bag now anyways.
19:05 karolherbst: true
19:05 karolherbst: but usually (as with our politics here) everything marked as secret, but publicly known is still a secret and nobody is allowed to use that information :O
19:19 deego: When trying to boot with new debian stable (4.9), I get a kernel oops: http://imgur.com/a/CybMP It seems probably related to nouveau, as you see in the backtrace. (I end up booting from oldstable). I have purge xserver.*nvou .. but the oops still happens.
19:22 imirkin_: that's a familiar issue
19:22 imirkin_: it should be fixed in ... 4.12 or so?
19:23 deego: imirkin_ it is? phew. I have been tearing my hair out for 2 months. What should I do? is it related to nv ?
19:23 imirkin_: yeah... the fan logic gets all upset
19:23 imirkin_: update your kernel to 4.12 and you'll be all set
19:24 deego: ah, excellent. many thanks.
19:25 karolherbst: imirkin_: you are forgetting about me :(
19:25 imirkin_: karolherbst: not forgetting...
19:25 imirkin_: i read a book last night instead of doing computer things
19:26 karolherbst: good thing
19:26 karolherbst: I approve of that
19:53 marmistrz: karolherbst: thanks a lot!
19:55 karolherbst: marmistrz: I assume it works now as expected?
19:55 marmistrz: Yep, perfectly
19:55 marmistrz: TBH, I didn't test prime offloading, but OpenCL/CUDA works
20:09 imirkin_: er ... opencl/cuda don't work with nouveau...
21:32 imirkin_: skeggsb: good morning :)
22:19 skeggsb: imirkin_:
22:19 skeggsb: hey
22:20 imirkin_: how's progress on mesa?
22:20 skeggsb: slow, but steady
22:21 imirkin_: are you like fixing fallout, or still figuring out how to handle various cases?
22:22 skeggsb: fixing up stuff i hand-waved away, going through a medium-sized "go back to this commit" todo list
22:22 imirkin_: cool. sounds like the end may be in sight
22:23 skeggsb: fingers crossed, i'm pretty over it :P
22:23 imirkin_: hehe
22:24 imirkin_: you might want to peel yourself away from it to address some of the recent issues identified in the kernel - not sure if you've been looking along
22:24 skeggsb: i've been reading emails, but yeah, thought today i might start with some of that
22:27 rhyskidd_: skeggsb/imirkin: Going through my GP107 mmiotrace, I've seen undocumented registers that I've been able to match to Tegra X1 out-of-tree code #defines
22:27 rhyskidd_: what is the confidence level we need before I can get them into rnndb?
22:28 mwk: rhyskidd_: as much as you have time for
22:28 mwk: speculation is OK if you mark is as such
22:29 rhyskidd_: Ok, that's helpful guidance. I can tie some back to usage on earlier families in nvidia_bios repo, but not going to be 100% sure when a register was first introduced for example
22:29 reepca: slightly off-topic question, but how difficult is it to reverse-engineer microcode/firmware (and is there a difference between the two? I hear them used interchangeably...)
22:30 mwk: reepca: it's quite doable
22:30 mwk: mostly depends on the size of the firmware in question
22:30 imirkin_: rhyskidd_: low confidence :) like mwk said, indicate the source, and it's fine.
22:30 mwk: and the amount of control you have over whatever processor is executing it
22:31 mwk: eg. if it involves custom ISA and you can't run shit on it because it has crypto signatures, it's quite hard
22:31 rhyskidd_: imirkin_: sounds good
22:31 mwk: microcode and firmware are sorta different things, but it's really more of a continuum
22:33 reepca: any idea where on the continuum AMD gpu microcode falls?
22:33 mwk: microcode is something very tied to the specific hardware, running on a custom µc with a custom ISA, etc; firmware is something where you could reasonably use eg. a C compiler because the hardware is general-purpose enough
22:33 mwk: reepca: sorry, but I don't know much about AMD gpus
22:33 mwk: but if it's anything like nvidia, there's no such single thing as "AMD gpu microcode"
22:34 mwk: nv has a *lot* of processors and processor-ish things on the GPU
22:34 mwk: some of them are quite low-level, others are practically general-purpose
22:36 reepca: mwk: thanks for the info. I've been wondering how feasible it would be to try reversing the blobs that keep some of my AMD hardware unsupported by linux-libre, and figured this was as good a place as any to ask since I happened to be here
22:36 imirkin_: skeggsb: ok good. i think there are like 4-5 issues by now that need tending to
22:36 mwk: reepca: most likely very feasible
22:36 mwk: unless there's a crypto sig involved, and even these can be crackable
22:36 mwk: mostly you just need a knowledgable and motivated individual
22:37 airlied: reepca: there was some work on re amd fw by ps4 folks
22:38 reepca: airlied: could I read about it somewhere?
22:38 airlied: though i think newer gpus are allsigbed
22:38 airlied: signed
22:40 imirkin_: for amd too?
22:40 airlied: yup
22:40 imirkin_: sadness
22:40 airlied: https://fail0verflow.com/blog/2016/console-hacking-2016-postscript/
22:40 airlied: go from there i suspect i dont have exact links in front of me
22:41 karolherbst: I thought AMD wouldn't care, because nobody REs those anyway...
22:41 airlied: imirkin_: well we never had any ooen fw to start with
22:41 imirkin_: that doesn't make me less sad.
22:41 airlied: karolherbst: nvidia didnt do it because of nouveau
22:41 karolherbst: I know, I was just joking
22:42 airlied: i suspect "security" is to blame
22:42 karolherbst: the only reason coming into my mind would be DRM stuff, but I can't really say how close this is to the truth
22:42 airlied: yeah drm and windows
22:43 karolherbst: why windows?
22:43 airlied: they dont want someone using a hacked fw to dma out complete frames
22:43 karolherbst: ohh, I see
22:43 airlied: karolherbst: its nearly always driven by windows and media companies
22:43 karolherbst: so, in the end it's drm again?
22:44 karolherbst: I don't buy that "security" reason though, because if an attacker is able to upload custom firmware, the target has lost already anyway
22:48 reepca: airlied: thanks for the link.
23:32 airlied: karolherbst: its more about hiding something across os reboots
23:32 airlied: karolherbst: think cloud gpus
23:32 airlied: where if one vm can upload hacked fw, and another vm uses it later
23:36 airlied: but also drm ppl worry about subverting a processor the driver isnt actively using to dma decoded frames
23:45 imirkin_: i think "but also drm ppl worry" is sufficient :)