00:33 nyef: ... why is nvkm supposedly trying to avoid drm dependencies?
00:34 imirkin_: skeggsb can probably best field that question
00:35 imirkin_: however there's some desire to make it easily portable to other platforms
00:35 nyef: Ah, okay. That makes a certain amount of sense.
00:35 imirkin_: and also there was a desire at some point to create a virt layer where the nvkm uapi calls would get passed through the vm layer to the underlying hw
00:35 imirkin_: i don't know if such desires persist
00:36 skeggsb: nyef: what imirkin said, plus, it's also built into a userspace library, where i do most of the development and hw bring-up stuff (much much easier to deal with), also because it'll eventually be a separate module where the drm part can run inside a vm and talk to nvkm on the host
00:36 skeggsb: there's some crucial bits missing for the last part, but, i'm slowly getting there
00:37 nyef: Okay, and since I have your attention, where's the appropriate place to put the logic for powering the LCD panel back on post-resume? (-:
00:37 skeggsb: the hw also has a very decent abstraction between priviledged/user, nvkm generally handles the former parts
00:38 skeggsb: depends what that logic is exactly
00:38 nyef: It looks like NONE of the logic for dealing with LCD GPIOs is correctly handled at this point.
00:39 skeggsb: *generally* speaking, the devinit scripts do that automagically, but, it wouldn't shock me if that's not universal
00:39 nyef: There's a bit of magic in nouveau_connector.c nouveau_connector_ddc_detect() that powers up an eDP panel.
00:40 skeggsb: yep
00:40 nyef: It doesn't happen on resume-from-suspend, and AFAICT it should honor the LCD GPIO bits in the DCB to look up which GPIO to use.
00:41 skeggsb: it *should* happen the next time someone tries to poll the status, but you're correct, it's not the ideal place
00:41 skeggsb: and you're also correct about the latter, that's new info we didn't previously have prior to dcb specs, but no-one's implemented it yet
00:42 skeggsb: i'd meant to deal with that, and a few other things, prior to implementing atomic/mst, but it was a larger project and i didn't have time
00:42 nyef: I'm willing to do at least some of the work, given a bit of guidance, since it affects hardware that I'm trying to get running properly. (-:
00:44 nyef: But I'm also thinking that it probably belongs in the nvkm code, since if the bit isn't set then the HPD signal never happens, so it's part of AUXCH management for eDP connections.
00:44 skeggsb: i'd hack it into nvkm_connector_init() for the moment
00:45 skeggsb: conditional on (conn->info.type == DCB_CONNECTOR_eDP)
00:46 nyef: I'm also not likely to be in any kind of a hurry for this for until I get the steroscopic stuff figured out, so as far as I'm concerned there's time to do a proper job instead of a hack.
00:51 orbea: skeggsb: I'm not sure if you saw in the log, but I've had an interesting issue with 4.10.0-rc2. When xscreensaver activates the monitor's suspend xorg's video input will freeze when trying to resume. The mouse cursor and keyboard still work as does switching to a tty, but switching back to the xorg session will still be frozen until my wm is closed and then restarted. I can reproduce it with: sleep 10 &&
00:51 orbea: xset dpms force suspend (Activate xscreensaver now)
00:56 skeggsb: orbea: thanks, i'll take a look into that
00:59 orbea: i have a GK110B btw
01:35 imirkin: drathir: there's no support for x265 decoding accel on nouveau.
01:40 nyef: Is HDMI audio not expected to work on an MCP89?
01:40 imirkin: it is expected to work.
01:41 imirkin: you have to direct audio output to the hda device attached to the nvidia chip though
01:41 imirkin: not your regular system audio output
01:42 imirkin: are you seeing the eld coming in properly?
01:42 nyef: I don't know. Right now all I know is that Mate's "Sound" control panel only shows the system output, not the HDMI output.
01:43 imirkin: nyef: lspci -nn -d 10de:
01:43 imirkin: does that show an audio device?
01:44 nyef: 00:08.0, an MCP89 HDA, 10de:0d94.
01:44 imirkin: ok. is there a driver bound to it?
01:45 imirkin: do you have a file along the lines of /proc/asound/card0/eld#0.0 ?
01:45 nyef: Driver is bound as snd_hda_intel, checking for the asound file.
01:46 nyef: eld#3.0 eld#4.0 and eld#5.0 ?
01:47 imirkin: aplay -L -- does that output hdmi-related items?
01:47 nyef: command not found.
01:47 nyef: Also don't have alsamixer, so I'm installing some more stuff.
01:48 imirkin: can you cat those files
01:48 imirkin: and see if any of them are filled in?
01:51 mwk: well, here goes
01:51 nyef: eld#5.0 has something, but it feels a little sketchy to me.
01:51 mwk:has plugged in the NV40
01:51 mwk: shit is going down
01:51 imirkin: mwk: it ... begins!
01:52 nyef: A lot of 0x10 in various places.
01:52 imirkin: nyef: it should show your monitor's info in there
01:52 imirkin: pastebin it?
01:52 nyef: The monitor_name is all \u0010, the manufacture_id is 0x1010, the product_id is 0x1010, the port_id is 0x1010101010101010...
01:52 mwk: aaaand
01:52 mwk: my suspicions have been verified
01:53 imirkin: nyef: heh, yeah, that's pretty clearly wrong
01:55 mwk: so the original NV40 is even more of a weirdo than I thought.
01:55 nyef: http://paste.lisp.org/display/335745
01:57 imirkin: mwk: whoa. that's surprising!
01:57 mwk: so it is.
01:57 imirkin: mwk: what about NV25?
01:57 imirkin: nyef: yeah that's clearly bogus
01:58 mwk: imirkin: only NV35_3D
01:58 mwk: and only on NV40 itself
01:58 mwk: anyhow
01:58 mwk: I'm probably crazy by now
01:59 mwk: I figured it out by merely looking at PGRAPH bitscans
01:59 mwk: but submitting things on the class confirms that
02:00 mwk: that's going to be one crazy emulation, too... I mean, they'd have to translate the fragment program ISA somehow
02:00 nyef: Okay, it doesn't work, the eld is bogus, and getting it working is well down on my list of priorities.
02:02 mwk: and vertex program ISA too, but then I've seen them already do it for NV20-on-NV30 emulation
02:02 mwk: and it's simpler
02:02 imirkin: nyef: the eld is written by that hdmigt215.c method
02:03 imirkin: mwk: emulating the fixed function stuff seems like the more annoying part.
02:03 mwk: also, this means the NV40 has all sorts of fixed-function hardware it's not supposed to have
02:03 mwk: right
02:03 mwk: and I'm quite positive that's supported
02:03 nyef: imirkin: gt255_hdmi_ctrl() ?
02:03 nyef: Err... gt215_hdmi_ctrl()?
02:04 mwk: the thing that tipped me of was RC_FINAL_* registers still existing in NV40 scans
02:04 nyef: Or is there another hdmigt215.c somewhere around?
02:04 imirkin: nyef: wait, that's not it.
02:04 imirkin: it used to be organized differently, give me a few
02:04 imirkin: ah there ya go. hdagt215.c
02:05 mwk: but, ain't it fun
02:05 mwk: an unbroken line of emulated 3d classes from NV3 up to NV4x
02:05 nyef: I'm in no rush. I figure that if I get the HDMI stuff sorted in time to land in 4.12, I'm doing well.
02:05 mwk: too bad G80 broke everythin
02:06 nyef:alternates between impressed and frustrated at the nvkm code.
02:08 mwk: ... OR DID IT?
02:16 imirkin: nyef: you could trace it to see what hda is getting written in there. or it could be that the nvaf has a different place where it needs to get written.
02:16 imirkin: nyef: that code works for gt215/6/8 and gf100-gf116, so ... dunno.
02:17 imirkin: nyef: btw, i'm not sure that the nvaf hw can doe hdmi 3d - it's possible you needed a later hdmi spec. should check on that.
02:17 nyef: I pushed it to a list of loose ends. It's really not important to me at this point, the system has a built-in speaker that works, and I'm more focused on the 3D stuff right now.
02:19 imirkin: looks like the hdmi 3d stuff only came in with hdmi 1.4
02:19 nyef: The important bit is generating the vendor infoframe and the particular display modes.
02:21 imirkin: well - also bandwidth. i'm not sure those things can do more than a 165mhz dot clock over hdmi.
02:21 nyef: That would count as a particular display mode, yes.
02:22 nyef: But even if it can't do the frame-sequential mode, it should still be able to do side-by-side or top-and-bottom.
02:22 nyef: Since they "just" need the infoframe.
02:22 imirkin: are those compressed?
02:22 imirkin: or are they double-wide?
02:22 nyef: Compressed, I think.
02:22 nyef: If it were double-wide, we'd be at the same place as the frame-sequential mode in terms of dot-clock.
02:23 imirkin: (/double-tall)
02:23 imirkin: right
02:24 nyef: Anyway, my first goals in terms of HDMI 3D are to generate infoframes for side-by-side and top-and-bottom.
02:24 nyef: That should demonstrate working infoframe generation, at least.
02:25 imirkin: skeggsb: don't forget about mupuf's fix for LED_CLASS selection. looks like danvet is trying to merge something else via drm-misc or something?
02:28 nyef: Hrm. The gf114 uses hdmigt215, and it works with a 120Hz eDP panel, so it's at least semi-plausible that the mcp89 might also have that kind of output bandwidth.
02:29 imirkin: well, heh. those things aren't quite as correlated as you like.
02:29 nyef: ... And the PS3 uses something even older, doesn't it?
02:29 imirkin: we default the max hdmi to 225mhz on fermi, 165mhz on tesla
02:29 imirkin: and hdmi != DP
02:30 nyef: Well, if it works, it works. If it doesn't, then it should just mean that the frame-packing mode isn't available even if the other two are.
02:30 imirkin: PS3 has a G71-style gpu. however i'm sure it has an external hdmi encoder
02:30 nyef: Okay then.
02:30 imirkin: since G71 didn't support anything HDMI directly at all.
02:31 imirkin: yea
02:32 nyef: And I have (semi-broken) fermi and (mostly-working) kepler hardware, so I should be able to get the frame-packing working anyway, even if not for the mcp89.
02:34 imirkin: sounds right
02:34 imirkin: on kepler we bump it up to 297mhz
02:35 imirkin: although i have no idea if that's right - could well be 340mhz
04:43 nyef: Running w3m in a terminal window in X on the nvaf causes some graphical corruption, but quitting w3m and forcing a redraw of affected areas seems to clear it up. No obvious messages, and I don't know if it's a w3m thing or a nouveau thing.
04:44 nyef: Okay, it also happens on the blob on my kepler. Must be a w3m thing.
04:47 nyef: ... And, suddenly, a moment of *duh*. I should dig into that audio thing, because it's affecting a -rc kernel.
04:47 nyef: But not tonight.
04:56 imirkin: nyef: you're spreading yourself too thin... pick something concrete and figure it out and send patches
05:04 nyef: Heh. Probably. I've got, what, four or five things going on right now just with the nouveau stuff?
05:05 imirkin: my guess is that the nvaf hdmi audio thing should be pretty easy, if you trace the blob
11:51 lacesoutin: this is shicking to me what has happened on irc's, it is one of the two. 1. you entirely lack confidence 2. or you are just being stupid , second one would be lot worse, but lacking confidence to perform tasks is also quite serious trouble
11:52 lacesoutin: *shocking
11:53 lacesoutin: that is why the conversations, it should make you more current to handle things
11:54 lacesoutin: having conversation should boost the confidence levels, having a convo is not spamming but finding the truth, and excersizing to readjust to the topic
12:03 lacesoutin: just to be honest i never troll around, having some conversations and arguements with others, have boosted my self-beliefs, i should mention, that those arguments have been overly too stupid to me even, maybe if possible then readjust to my braindump instead, before it goes to embarrassing
12:07 lacesoutin: it seems that Roy and mupuf were the first pioneers having some clues what i talk about, ok i go now, as i do not troll around it's totally ok to be thinking together and following my thoughts imo
12:11 pmoreau: …
12:12 pmoreau: > having some conversations and arguements with others
12:13 pmoreau: I would substitute "myself" to "others" in that sentence, >=90% of the time.
12:32 funfunctor: this guy is so f*cking annoying
12:32 funfunctor: #radeon's backlog was filling up with his raving a number of hours ago with a different nick
12:34 funfunctor: mwk: hi
12:34 pmoreau: :-/
12:34 funfunctor: I am studying the dump of the entire BAR and there are some interesting patterns forming
12:34 karolherbst_work: I just feel sad with this situation
12:35 pmoreau: And he loves coming back for some reason… Not sure why
12:35 karolherbst_work: funfunctor: you mean besides the normal structure?
12:35 funfunctor: He wants someone to talk to about technical nothing
12:35 funfunctor: karolherbst_work: which 'normal' structure?
12:35 karolherbst_work: yeah, he is mainly very lonely
12:35 funfunctor: well I don't know him
12:36 funfunctor: I just noticed he talks a lot with himself essentially with lots of stuff he is googling
12:36 karolherbst_work: isn't the bar the configuration space with all the "registers"? or did I mix something up
12:36 funfunctor: I needs to find a local computer club meetup thing
12:36 funfunctor: karolherbst_work: the BAR itself is a pointer into a window of mapped memory
12:36 funfunctor: MMIO
12:37 funfunctor: Maybe you are thinking of the structure of PCI config space?
12:37 karolherbst_work: no, I meant the mmio regs
12:37 karolherbst_work: what you read out with nvapeek
12:37 funfunctor: I mean if you dereference BAR0 and dump the whole window..
12:38 karolherbst_work: it's a 0x1000000 big thing, isn't it?
12:38 funfunctor: karolherbst_work: well I used ./iotools mmio_dump 0xfea00000 0x10000
12:38 funfunctor: 64K
12:38 karolherbst_work: mhh
12:38 karolherbst_work: then I am talking about bar1
12:38 karolherbst_work: what's in bar0?
12:39 funfunctor: but I am looking at some decklink hardware, maybe you think I am talking about nv specific things
12:39 karolherbst_work: yeah, I thought so
12:39 funfunctor: I was discussing with mwk RE more broadly
12:39 karolherbst_work: I see
12:39 karolherbst_work: well
12:39 karolherbst_work: engineers try to be smart
12:39 karolherbst_work: so there are usually structures within the bars
12:39 karolherbst_work: like 0x0 - 0x1000 is general stuff, 0x1000 - 0x2000 is for configuring something… etc..
12:40 funfunctor: sure, have a look at this: https://paste.fedoraproject.org/520223/62001914/ its when A is non-zero
12:41 funfunctor: Just to cut out all the 0x00000 state and narrow down where stuff is happening
12:41 karolherbst_work: please use hex representation
12:42 karolherbst_work: 128 == 0x80 as one example
12:42 funfunctor: karolherbst_work: yea thats just because of my crappy python
12:42 karolherbst_work: 1077952576 == 0x40404040
12:43 karolherbst_work: hex()
12:43 funfunctor: https://paste.fedoraproject.org/520225/48362019/
12:43 funfunctor: karolherbst_work: I know, its just hex() gives you a string type and a bunch of math ops stop working and I get exceptions
12:44 funfunctor: its super annoying they don't have typed hex in the language
12:44 karolherbst_work: in the print
12:45 karolherbst_work: print(hex(ret[ret.A > 0])
12:45 funfunctor: karolherbst_work: nar I need to map it somehow over a pandas structure
12:45 karolherbst_work: mhh
12:45 karolherbst_work: I see
12:46 funfunctor: If your good with python I can give you a trace you can try it with
12:46 karolherbst_work: I am terrible with python
12:46 funfunctor: https://paste.fedoraproject.org/520227/36204031/
12:47 funfunctor: karolherbst_work: I never spend enough time with it to become good enough that I stop forgetting shit each time..
12:47 funfunctor: I more or less use python as slightly-less-insane shell script
12:48 karolherbst_work: okay
12:48 karolherbst_work: basically you have 0x200 big blocks there
12:48 karolherbst_work: what kind of device are we talking about here anyway?
12:48 funfunctor: 0x200 or 0x2000 you mean?
12:48 karolherbst_work: 0x200
12:48 funfunctor: oh,
12:48 karolherbst_work: makes sense, doesn't it? :D
12:49 funfunctor: interesting.. Its a Blackmagic Decklink Duo2, it has four SDI video input/outputs
12:49 funfunctor: each of the four i/o ports are assigned to a "subdevice"
12:49 funfunctor: those are 0x2000 apart
12:49 funfunctor: as for what is 0x200 apart I don't know?
12:49 karolherbst_work: well
12:49 karolherbst_work: there can be block within blocks
12:49 funfunctor: yes sure
12:50 karolherbst_work: well
12:50 funfunctor: what made you identify that 0x200 pattern?
12:50 karolherbst_work: you can modify nva in a way, that you can use the nva tools for your device as well
12:50 karolherbst_work: funfunctor: it's kind of obvious
12:50 funfunctor: nva hmm?
12:50 karolherbst_work: 0x8dd61000
12:50 karolherbst_work: search for it
12:50 pmoreau: funfunctor: in envytools
12:51 karolherbst_work: you have more numbers which match to m[a] == m[a + 0x200]
12:51 pmoreau: https://github.com/envytools/envytools/tree/master/nva
12:51 karolherbst_work: 0xfa871000 is another one
12:51 funfunctor: thx
12:52 funfunctor: your eye is fresher than mine, i've noticed some of my own patterns and now my brain stopped looking in a haze of confusion
12:52 karolherbst_work: funfunctor: https://github.com/envytools/envytools/commit/8809717a2934aa7850c0b9c19bc1e196a17e8eb3
12:52 karolherbst_work: something like that
12:52 karolherbst_work: but different
12:53 funfunctor: thx!
12:53 karolherbst_work: and if you got it right, nvalist should also list your device
12:53 funfunctor: and what sort of output will I see?
12:53 karolherbst_work: and then you can select the dvice with -d
12:54 karolherbst_work: funfunctor: nvapeek -d x 0x0 would print 0x1
12:54 funfunctor: yep I can see the vid/pid logic there
12:54 karolherbst_work: ohh wait
12:54 karolherbst_work: not 1
12:54 karolherbst_work: nvapeek -d x 0xc would print "0x8dd61000"
12:55 karolherbst_work: and with nvapoke you can modify those
12:57 funfunctor: 0xc ?
12:57 funfunctor: I can't see -d
12:57 funfunctor: nvapeek [-ibt <regspace_opt>] <address> [<byte count>]
13:03 pmoreau: karolherbst_work: did you meant -c instead of -d?
13:03 pmoreau: All programs except nvalist take an optional -c <card number> parameter.
13:03 pmoreau: The valid card numbers are 0 .. (card count in system - 1). If -c is not
13:03 pmoreau: specified, it defaults to 0. A list of cards with their numbers is given
13:03 pmoreau: by the nvalist program.
13:04 pmoreau: funfunctor: -^
13:05 funfunctor: I'll have to read the source to get familiar, thanks for the suggestions about this instead of me reinventing the wheel on it
13:05 funfunctor: though I think half of the functionality I can already do with some of our coreboot tools like iotools
13:06 lacesinout: listen pmoreau you'd be shitting the corner in all events with funfunctor which there will be offered to compete with me, just get over with and do not scare the shit out of people here with imirkin
13:07 pmoreau:
13:07 lacesinout: i would dominate every event against you from start to finnish, it just the levels you are at
13:08 lacesinout: that is too weak
13:08 karolherbst_work: funfunctor: the advantage of the nva tools are, that you don't care about the actual address, because it does everything for you
13:08 karolherbst_work: funfunctor: there is also something like nvascan, which checks which bits are actually changeable on a reg
13:09 karolherbst_work: ohh right -c is the device selection
13:10 lacesinout: please for once cut it off, everything is written in google, yeah of course, cuda has so much code snippets, and how shuffle works everything is described
13:10 funfunctor: karolherbst_work: how does nvascan work? just attempt to toggle them to figure it out?
13:11 karolherbst_work: yes
13:12 lacesinout: the thing is with that shuffle method you can detect a cache miss, but though nvidia has other methods too
13:13 funfunctor: karolherbst_work: I suppose its plausible that could brick the hw
13:15 karolherbst_work: funfunctor: it might
13:15 karolherbst_work: funfunctor: it basically does this: save current value, set 0x0 and read result, set 0xffffffff and read result, set stored value again
13:16 funfunctor: ok
13:16 karolherbst_work: funfunctor: but if you want to figure out what a register does, you usually have to mess with it somehow
13:16 funfunctor: well I suppose I have to do it any way to cut down the state space into something more narrow that I can focus on. I don't really have a choice
13:16 funfunctor: yes your right
13:17 karolherbst_work: do you have a driver?
13:17 karolherbst_work: because then you could do mmiotraces
13:18 karolherbst_work: with Vt-d you may be actually able to even trace the windows driver, but I have no idea if that would even work
13:18 funfunctor: I do yes
13:18 funfunctor: I have traces already using mmiotrace
13:18 karolherbst_work: k
13:18 funfunctor: yes indeed
13:18 karolherbst_work: it's a shame that envytools is so much nvidia specific
13:18 funfunctor: yes :/
13:18 lacesinout: it works how i said , you point a current wave against some contiguous space with relative aadressing, and just too a test, if the lanes are occupied , and free them , ok?
13:18 karolherbst_work: in most places there is no valid reason for this
13:19 karolherbst_work: etnaviv just forked it and modified it as they want it to be
13:19 karolherbst_work: which is bad….
13:19 funfunctor: maybe we should collaborate on that front because we provide similar sorts of tools as part of librecore
13:19 karolherbst_work: there should be one envytools project + several repositories for each kind of hardware or projects or whatever
13:19 karolherbst_work: yes
13:20 funfunctor: http://librecore.info/
13:20 funfunctor: https://github.com/librecore-org/librecore-utils
13:24 lacesinout: right away when the lanes change their state, the poller on shared memory area will capture it, and adjust the mask
13:26 lacesinout: why would you need to do that, is written by david tarjan, because 90percent of the threads would be otherwise idling the alus
13:29 lacesinout: remember if the lanes have unitialized value, which is the case where insutruction is done, the hw circuit treats this as nop and it will skip over it, once it has content, it will capture it
13:30 lacesinout: there is a certain vision you need to have how instruction queue fifos and simd works in parallel with given shader, i see it right away
13:34 lacesinout: for instance if the major amount of threads on shared memory i.e LDS, have skipped, it will schedule the next instruction on the shader in hw
13:34 lacesinout: once couple of them have returned to shared memory only couple waves it absolutely momentarily will capture the lanes changed
13:40 lacesinout: and as i said, there is a point why it is designed to be software controllable, not done in hw the scheduling part, because during the cases like cache trashing with software controlled version you can trim right
13:41 funfunctor: karolherbst_work: pmoreau thx for all the excellent advice
13:41 lacesinout: you see david did hw based microarchidecture, and basically such solution was failing in this scenario
13:43 pmoreau: funfunctor: Np! You’d almost motivate me to look back at Nouveau issues in the kernel module. :-)
13:43 funfunctor: :)
13:43 pmoreau: And do some RE there
13:46 lacesinout: so someone might possibly understand what i say, those are golden words, this performance stuff is very easy, the multithreading stuff in current state is also very easy
13:46 lacesinout: i am just wondering how the hell are you getting so far, if not understanding how things behave
13:49 chillfan: Having a little trouble with DPI settings, as far as I can tell the screen size is detected properly but the dpi insists on being 96 x 96 (nvidia uses 81 x 80 from the EDID)
13:49 chillfan: other information seems to be picked up correctly
13:50 chillfan: is there a way to override the DPI settings maybe?
13:51 chillfan: hopefully via xorg.conf, not all programs seem to honour ~/.Xdefaults so that way is problematic
13:52 lacesinout: yeah well some x program just was capable of chaning dpi settings
13:53 lacesinout: *changing, i bet you tried it?
13:53 chillfan: I can do it via xrandr, but the new setting only applies to newly created clients
13:53 chillfan: e.g xrandr --output <outputname> --dpi 81 80
13:54 lacesinout: righ i see
13:54 lacesinout: how about doing it in xorg.conf?
13:55 lacesinout: https://wiki.archlinux.org/index.php/xorg
13:57 chillfan: well usually DPI is decided by display size in xorg.conf, e.g I have DisplaySize set correctly, but the EDID reports DPI is 81 x 80, which is probably ignored by xorg, so I need a way to override
13:57 lacesinout: well i dunno what is the option for nouveau
13:58 lacesinout: yeah seems so
13:58 chillfan: perhaps it just doesn't honour DPI like nvidia does, I can't find the correct way to override via xorg though (much searching / testing yesterday)
13:59 lacesinout: chillfan: yep, i have not yet been able to find it either
14:00 lacesinout: though for what reason the Xdefaults and those other .xinitrc or something are cumbersome though?
14:02 chillfan: well I have it set, it just doesn't change anything
14:04 chillfan: maybe I should investigate a little more about Xft
14:04 chillfan: brb gotta boot to the nouveau kernel
14:09 lacesinout: i gotta head off too, before the devil wakes up:D:D, i no my destiny and the culmination for the day
14:09 lacesinout: perhaps if i quickly quit, i'd be able to chat tomorrow too
14:12 chillfan: ok I have found the answer, thanks.
14:12 chillfan: It turns out it should be set in ~/.Xresources
14:12 chillfan: but not in ~/.Xdefaults
14:13 chillfan: sounds simple when you know the answer as usual heh
15:49 chillfan: I'm having some trouble adding a new modeline via xorg.conf, has anyone experienced this? The modeline works OK, I just can't use it via xorg.conf
15:50 chillfan: have read the docs listed at https://www.x.org/wiki/Projects/XRandR/
15:50 chillfan: no help there
15:51 imirkin: just add it to the monitor...
15:51 chillfan: http://pastebin.com/muAydsYx
15:52 chillfan: that's what I'm using, the modeline there works OK if fed to xrandr but not that way
15:53 imirkin: pastebin xorg log
15:55 chillfan: http://pastebin.com/p7b64Bez
15:57 chillfan: it seems already aware of that modeline as it happens, e.g "1920x1080"x144.0 325.08 etc, which is what I'd like to use
16:00 imirkin: right... so you don't need to add it - it's already there
16:02 chillfan: yeah I'd like to use as default though, e.g xrandr --rate 144 will set that mode
16:03 imirkin: so why not set that in the xorg config?
16:04 imirkin: i think you can just write VertRefresh 144
16:04 chillfan: well modeline name is "1920x1080" regardless of refresh rate
16:05 chillfan: ah I'll try that thanks
16:05 imirkin: that's not a problem
16:05 chillfan: thanks brb whilst I tinker :)
16:06 imirkin: someone really needs to update the xorg.conf man page for the reality of the 1990's...
16:22 chillfan: no it turns out it won't accept that
16:24 chillfan: although the log did throw this.. [ 7066.522] (WW) NOUVEAU(0): Option "PreferredMode" is not used
16:24 chillfan: http://pastebin.com/9THubSdV (from there)
16:25 chillfan: not sure if that's relevant though, as xrandr -q doesn't show the mode I tried to set
16:27 chillfan: brb trying something else
16:27 karolherbst_work: usually a normal user don't do it over the X config anymore
16:27 karolherbst_work: *doesn't
16:45 chillfan: ok it looks like no joy that way, possibly randr docs need updating
16:45 chillfan: ?
16:46 chillfan: http://pastebin.com/mDz5NkzQ
16:47 karolherbst_work: "normal" user have display managers running in their desktop session which take care of stuff like that
16:48 chillfan: hm i use wdm with openbox
16:49 karolherbst_work: I am sure you can simply invoke xrandr inside your x session to the thing you want to have. Modifying the X file has the big disadvantage of not respecting the real hardware, this is especially bad with laptops if you unplug/plug your display a lot
16:49 karolherbst_work: chillfan: I never used any standalone though
16:50 chillfan: yeah I can do it that way, I guess either nouveau or xrandr won't use the information provided by xorg.conf?
16:51 karolherbst_work: depends
16:51 karolherbst_work: you can add new modelines with the xorg.conf which are picked up by xrandr
16:52 chillfan: well I added the modelines, I think it's just refusing to use them (I chose modelines from the list it generated from DDC)
16:52 karolherbst_work: does xrandr list the modeline?
16:53 chillfan: no
16:53 karolherbst_work: not even unattached?
16:53 imirkin: chillfan: check with #xorg-users or #xorg-devel
16:53 chillfan: well I gave the modeline the name 1920x1080_144 and it's not listed
16:54 imirkin: it's not a nouveau issue, i don't think
16:54 chillfan: ok I will try in there as well thanks
16:54 karolherbst_work: I think this is drm filtering things out it thinks can't be used anyway
16:54 karolherbst_work: chillfan: tried to add it with xrandr?
16:54 chillfan: yeah I can add with xrandr and use the mode that way
16:54 karolherbst_work: k
16:54 karolherbst_work: yeah, it should be a drm issue then rejecting this modeline by default
16:55 chillfan: the thing is, xrandr gets that mode from DDC anyway, but.. it will select only the default mode of 60Hz at the same resolution, e.g I can set that modeline with xrandr --rate 144 or.. add the modeline manually and set it, but not by xorg.conf, and disabling DDC is also refused
16:56 karolherbst_work: I see
16:56 karolherbst_work: ask in the channels imirkin told you then
16:56 karolherbst_work: if X is silly enough to not pick up the highest by default… then well it's X fault
16:56 karolherbst_work: except something prevents X from doing this
16:57 karolherbst_work: chillfan: tried it out without any xorg.conf files?
16:57 chillfan: will do, at least I know its not nouveau then that's a start :)
16:57 chillfan: hm I had no monitor section setup before
16:57 chillfan: but I'll try without xorg.conf too thanks
16:57 karolherbst_work: but won't be surprised if it works without a xorg.conf file :D
16:57 chillfan: brb
17:03 chillfan: Ok same deal there
17:03 chillfan: what were the xorg channels again? :)
17:03 karolherbst_work: irc://chat.freenode.net:6697/#xorg-users or irc://chat.freenode.net:6697/#xorg-devel
17:03 karolherbst_work: ……………
17:03 karolherbst_work: #xorg-devel
17:03 karolherbst_work: irc://chat.freenode.net:6697/#xorg-users
17:03 karolherbst_work: ...asdkasldjasd
17:04 karolherbst_work: what a crappy client I have
17:04 chillfan: aha
17:04 chillfan: ah xorg-user seems to be #xorg
17:04 chillfan: got it thanks
17:04 nyef: Hrm. hdagt215.c is all about writing to the card, that doesn't seem likely to cause problems with the eld available in /proc/asound/card0/eld#5.0.
17:05 imirkin: nyef: yeah, perhaps the eld data being written is bogus to begin with. there are traces for sizes, but not for the data itself.
17:06 imirkin: and btw i'm not 100% sure that there's a correlation between the eld data being right and audio working. i think it's just indicative.
17:07 nyef: Oh, definitely indicative. The question is why it's wrong. (-:
17:08 imirkin: bbl
19:20 chillfan: maybe it's a known problem.. but the witcher2 isn't working properly under nouveau. Once the game starts textures are missing
19:21 pmoreau: I should test that one
19:22 RSpliet: chillfan: without any background knowledge of the problem, do you have support for dxtn_txc?
19:22 RSpliet: or... some similarly vague abbreviation :')
19:23 chillfan: I do but maybe I'm missing the i386 version, I'll retest
19:23 RSpliet: txc_dxtn
19:23 pmoreau: There is https://bugs.freedesktop.org/show_bug.cgi?id=91310
19:23 RSpliet: the s3tc one, bah
19:23 chillfan: aah
19:24 chillfan: I needed the i386 version of the package
19:24 chillfan: nevermind, my mistake
19:24 RSpliet: pmoreau: glitcher 2?
19:24 RSpliet:hits himself with a baseball bat
19:24 pmoreau: RSpliet: :-p
19:24 chillfan: libtxc-dxtn-s2tc0:i386 is the package I needed
19:26 chillfan: it works but slow, obviously that's witcher 2 in general though for the "native" linux build :p
19:29 RSpliet: chillfan: did you manually ramp up the clocks for your GK110B?
19:32 RSpliet: (that /sys/kernel/debug/dri/0/pstate write)
19:33 chillfan: yeah I did echo 0f > /sys/kernel/debug/dri/0/pstate
19:33 RSpliet: okay, then... well, happy hacking :-D
19:34 chillfan: it's not that slow really, good enough I reckon.. can disable bits if need be
19:34 chillfan: oddly I'm not seeing the nouveau sensor exposed but I did before, wonder why that is
19:35 imirkin_: chillfan: afaik witcher 2 doesn't perform super-great on nouveau. perhaps things have improved, dunno. i never had the game.
19:36 imirkin_: chillfan: you should also try to find the s3tc version rather than the s2tc one - the s2tc one's decoding is off.
19:38 chillfan: will do thanks
19:38 imirkin_: oh, otoh that probably won't matter
19:38 imirkin_: since the gpu does the decoding directly in 99.99999% of the real-life situations
19:41 chillfan: happy to see things working without any blobs :)
19:43 pmoreau: I just tested the arena mode of TW2, fully reclocked GK107M on low settings and I had some really interesting rendering artefacts. :-D
19:45 chillfan: I have some artefacts on witcher 2 with nvboost=2
19:45 chillfan: maybe I should try with nvboost=1
19:46 chillfan: brb
19:54 hakzsam: pmoreau: time to test the sched codes series with your gm206? :)
19:59 RSpliet: hakzsam: I was kind of curious: how close are your sched codes to the blob?
19:59 hakzsam: not so far
19:59 hakzsam: except that blob does a global allocation for barriers
19:59 hakzsam: but for simplicity, I allocate them intra-bb
20:00 hakzsam: and I have some TODOs here and there
20:00 hakzsam: dual-issue has to be supported for example
20:01 imirkin_: skeggsb: should probably send https://github.com/skeggsb/nouveau/commit/b3816f34944ad4824d345b98c323a30710f492d4.patch upstream...
20:01 RSpliet: oh that's an interesting todo :-)
20:01 hakzsam: yeah :)
20:01 hakzsam: and the yield flag thing also
20:03 hakzsam: one could try to do a global allocation, but it's hard and I doubt it will improve perf a lot
20:05 Verty: I only seem to be able to get stereo audio out of via HDMI with nouveau (GT218)... i.e. no dobly surround... any suggestions?
20:06 imirkin_: Verty: all i know is that people have gotten it to work
20:06 imirkin_: Verty: you might have to send down DTS directly
20:07 imirkin_: Verty: glance at your eld - does the surround configuration appear supported based on what's in there?
20:07 hakzsam: chillfan: pmoreau: the witcher 2 used to work at some point, it has some glitches in high or ultra settings, but not in low IIRC
20:08 chillfan: ah thanks :)
20:10 Verty: imirkin_: eld#1.0 shows AC-3 but sad0_channels 1... not sure what that means tho :)
20:10 imirkin_: that's ... sad
20:10 nyef: That's better than my eld#5.0. (-:
20:10 imirkin_: (what does that stand for? something audio?)
20:10 nyef: "slow audio descriptor" or something like that?
20:10 nyef: simple?
20:10 nyef: standard?
20:10 chillfan: I think the glitches I'm seeing are tearing, vsync seemed to change it (though vsync == very slow)
20:10 chillfan: still it's only in one part so I can deal with that
20:11 Verty: I vote: shit :)
20:11 Verty: anyway what's that based of?
20:18 Verty: on a side note: the only change (afaik) is swapping the prop nvidia driver with nouveau... before that 6+ channels worked nicely
20:19 imirkin_: Verty: can you pastebin the whole eld file? i'm not necessarily looking for anything in particular...
20:19 imirkin_: but it shouldn't be too difficult
20:20 chillfan_: well just had a full system lockup running the witcher
20:20 nyef: So, I decided to try unplugging and re-plugging the HDMI cable on my MCP89, to see if it would affect eld#5.0 or not.
20:20 nyef: It didn't affect eld#5.0 at all: the same corrupt data appears even if the cable is unplugged.
20:20 Verty: imirkin_: http://pastebin.com/HB5hH1VP
20:21 imirkin_: Verty: oh nice. looks like you have the same corrupt crap that nyef is seeing
20:21 nyef: But then plugging back in shows that I'm not getting any signal at all on the video anymore.
20:21 imirkin_: my guess is that this is the issue
20:21 nyef: Heh!
20:21 imirkin_: or is, at least, correlated with the issue
20:21 nyef: Yeah, that looks promising. (-:
20:21 imirkin_: i'm like ... 99.8% sure this used to work
20:21 chillfan_: though I solved the problem of sensors, just need to build those in as well if nouveau is built in, or vice versa if it's a module
20:21 Verty: that's eld#1.0, the others show monitor_present 0 and eld_valid 0
20:21 imirkin_: how hard would it be for you guys to try some random old kernel versions?
20:22 imirkin_: like, say, 3.12, 3.16, 3.19
20:22 nyef: ... I have to reboot anyway, will 4.4.39 be of use?
20:22 nyef: (Since I have that one handy.)
20:22 imirkin_: i doubt that's old enough, but can always give it a shot
20:23 xen: https://youtu.be/D_JxMb8RLEY
20:23 xen: oh, sorry, wrong chan :\
20:24 Verty: it's my server (yeah it gets abused a lot) so I'd rather not tinker too much with it... that said if you want me to get some old kernel (currently at 4.4.38) that is possible
20:24 imirkin_: unfortunately this stuff doesn't get tested super-often
20:24 imirkin_: so regressions are easy to miss
20:24 imirkin_: esp if they're limited to a series of gpu's, in this case i'm guessing nva3/5/8/f
20:24 Verty: well if I get it to work I'll be testing it for you on a near daily basis :)
20:25 imirkin_: although earlier gpu's could be affected too, their hdmi audio support was questionable at best in the first place
20:25 nyef: Oops. So, the reason that the display didn't come back is that I plugged it into the wrong input on the monitor.
20:25 Verty: I was surprised I had sound at all... untill I realized I had a "newer" 8400
20:25 Verty: lol :)
20:26 imirkin_: ah yeah, those 8400's came in 3 varieties - G84, G98, and GT218
20:26 imirkin_: all equally crap in terms of gpu perf, but pretty different underlying chips
20:26 nyef: Hrm. Okay, 4.4.26 shows the same symptoms with the eld.
20:27 nyef: ... Insert a joke about ELDer gods into the protocol here, please.
20:27 Verty: 1080 video seems to work quite well to be honest... actually I think it's better than with the prop dirver :)
20:27 imirkin_: so basically nouveau went through a few rewrites. it definitely worked at some point in the 3.10-3.19 range.
20:27 imirkin_: Verty: probably using software decoding? or did you get vdpau working well?
20:28 Verty: not sure... kodi... :)
20:28 imirkin_: Verty: also if you're feeling brave, you can adjust perf levels in all likelihood
20:28 nyef: Ah! What this means is that it isn't a recent regression, so fixing it in time for 4.10 isn't critical! (-:
20:29 Verty:wonders if he can still get a 3.10 kernel for slackware from somewhere
20:29 imirkin_: doesn't have to be 3.10 specifically
20:30 Verty: any old kernel :)
20:30 imirkin_: anyways, looks like nyef is rebooting his box every 5 seconds, could just let him do it
20:30 Verty: yeah I'll hold off for a bit :)
20:30 nyef: I don't have any older kernels handy.
20:32 Verty: hmmm seems we maybe in luck... slack 14.1 is carrying 3.10.17 :)
20:38 pmoreau: hakzsam: I should, indeed. :-)
20:40 Verty: I'll reboot in a few... will keep you posted
20:42 nyef: ... Every so often, a system administrator faced with a problem will think "I know, I'll use firewire target disk mode". This is a cue for a frantic search ending in the realization that he has no firewire cables anywhere nearby.
20:47 Verty: that's actually the only bit of firewire kit that I still have left... 1 firewire cable :)
20:54 Verty: right... eld#1.0 now shows monitor_present 1 and eld_valid 0 (the others only have monitor_present 0)
20:54 imirkin_: Verty: hrmph
20:54 imirkin_: does audio work in any capacity?
20:56 Verty: yup... 4 channels! :)
20:56 imirkin_: ok cool
20:56 imirkin_: there was also a period of time when eld was broken
20:56 imirkin_: but everything else worked
20:56 imirkin_: i wouldn't be surprised if 3.10 fit that period of time
20:58 Verty: nice L(
20:58 Verty: :)
20:58 Verty: anyway kodi seems to player nicely with 7.1
21:01 Verty: anything you want me to check while in 3.10?
21:03 imirkin_: not really.
21:03 imirkin_: nyef: --^
21:04 Verty: more than happy to keep this one running for now tho :)
21:05 nyef: So, something broke between 3.10 and 4.4?
21:05 imirkin_: only 14 kernel releases
21:06 nyef: Fun and games.
21:09 karolherbst: wuhu, benchmarks
21:09 Verty: I only have 3.10.17 and 4.4.14 / 4.4.38 atm... I can build a custom one if necessary...
21:09 imirkin_: Verty: it'll take ~20 bisect steps to find the breaking commit, i suspect
21:09 imirkin_: but the kernel versions i suggested weren't picked at random
21:10 imirkin_: they were picked around various reworks that happened in nouveau
21:10 imirkin_: the last rework went into kernel 4.3
21:11 Verty: kinda figured... feel free to send me a patch tho :)
21:12 Verty: anyway given the positive results so far I might give nouveau a spin on my GTX 660... seem how well that plays
21:12 imirkin_: heh
21:13 imirkin_: word of warning - some GTX 660 users have issues with nouveau that are resolved by using blob firmware
21:13 imirkin_: not all GTX 660's though. for example ben's doesn't exhibit the issue (or else it would all have been fixed a long time ago)
21:13 Verty: thanks for the heads up
21:14 nyef: Oh? I'm running the blob on my GTX 660M, but there's a decent chance that I'll be trying to transition to nouveau on it soon.
21:14 imirkin_: nyef: just desktop GTX 660 cards. once you see an M, all bets are off :)
21:14 nyef: ... Of course.
21:15 imirkin_: more generally, it's "some GK106's". but in iirc each instance, those were desktop GTX 660 boards
21:15 imirkin_: maybe a GTX 660 Ti managed to sneak in there
21:15 imirkin_: while no one was looking
21:15 karolherbst: imirkin_: I doubt it is chipset specific though
21:15 nyef: Sounds like we need a failing card and an MMIOtrace?
21:15 imirkin_: nyef: you need a failing card and a skeggsb :)
21:15 nyef: Or that, yes.
21:15 imirkin_: once their minds become one, the solution will present itself
21:16 imirkin_:is still bitter that skeggsb figured out the GT215 GDDR5 issue in like 1h after i had spent 2 days on it
21:18 karolherbst:is thinking if he should push his dynamic reclocking patches to the list
21:20 chillfan: I have an nvidia 940M in my laptop, are there any tests / driver dumps etc someone could make use of?
21:21 karolherbst: chillfan: you can test reclocking with a 4.10 kernel
21:22 chillfan: ok I'll take a look at that :)
21:23 chillfan: have the blob driver on there atm so will have to set that up
21:23 karolherbst: chillfan: you don't use your intel gpu?
21:23 karolherbst: because if your main gpu is intel, you can actually have both installed, nvidia and nouveau
21:23 karolherbst: and just switch on the fly
21:24 chillfan: main gpu is intel, so I can just switch when I want I guess?
21:24 karolherbst: well, mostly yes. With nouveau it is a bit tricky, because a normal X server will claim that card and keep a reference
21:25 karolherbst: but normally you can just load nouveau
21:25 karolherbst: and setup prime offloading
21:25 karolherbst: I assume you use bumblebee?
21:26 chillfan: atm nvidia-prime is installed
21:27 chillfan: but installing bumblebee now
21:27 imirkin_: you don't need bumblebee
21:27 imirkin_: [not for nouveau]
21:27 karolherbst: uhm
21:27 karolherbst: nvidia-prime is that silly nvidia thing where the nvidia gpu renders everything, right?
21:27 karolherbst: in that case you can't switch on the fly
21:28 chillfan: no idea, I'm not familiar with prime offloading atm, first time using an nvidia laptop
21:28 chillfan: I guess that means I can remove that
21:40 Verty: so far GTX 660 seems to work... all be it sloooowwww... :)
21:41 imirkin_: pastebin dmesg
21:42 Verty: lot of fb stuff flying about :)
21:42 imirkin_: is there a "GPU hung, switching to software"?
21:42 imirkin_: (i forget exact wording)
21:43 chillfan: does nouveau offload from intel?
21:43 imirkin_: only if you tell it to
21:43 imirkin_: chillfan: DRI_PRIME=1 glxinfo
21:43 imirkin_: chillfan: more generally, https://nouveau.freedesktop.org/wiki/Optimus/
21:43 imirkin_: you probably want the DRI3 section.
21:43 imirkin_: unless you have outputs attached to the nvidia gpu that you want to use.
21:43 Verty: http://pastebin.com/YUtAevAh << dmesg
21:44 imirkin_: Verty: that looks kosher
21:44 karolherbst: sometimes it helps to increase the clocks
21:44 imirkin_: nothing after those lines?
21:44 chillfan: so default behaviour is just uses nvidia gpu?
21:44 Verty: I take it the FB stuff is for console only?
21:44 imirkin_: chillfan: no, default behavior is to use the primary gpu, which in your case is intel
21:45 imirkin_: Verty: you mean fbcon/nouveaufb? that's a fbdev device that nouveau exposes
21:45 imirkin_: for compatibility with existing systems
21:45 chillfan: so for best performance, which would be the best way? Just leave it as is?
21:45 imirkin_: chillfan: read the page.
21:46 Verty: xorg logs seem fine as well
21:47 imirkin_: Verty: pastebin output of glxinfo?
21:47 Verty: full monty or just first bit?
21:47 imirkin_: full avoids me having to ask follow-up questions
21:48 imirkin_: this is true in general of log requests
21:48 imirkin_: trimming may seem like it's doing a service, but in actuality, it's just removing potentially useful info
21:48 Verty: point taken :)
21:49 Verty: http://pastebin.com/NAJdKnNA << glxinfo
21:53 Verty: not that "slloooww" is in comparison to nvidia prop driver... it's descent performance given the fact I run a composite desktop with 2 screens and 1 cloned.... and mplayer runs smooth...
21:53 Verty: s/not/note/
21:53 imirkin_: ah ok. so then you probably just need to reclock
21:54 imirkin_: you'll want kernel 4.10-rc1 or later to get the full effect
21:54 imirkin_: although with earlier kernels you're likely to be able to get to the middle level successfully
21:55 karolherbst: with bad stability though
21:58 Verty: hmmm it just locked up Xorg.... and it wasnt coming back from it
21:58 karolherbst: Verty: that's why you wanna have 4.10
21:59 imirkin_: Verty: did you try the highest mode?
21:59 imirkin_: Verty: and what kernel are you on?
21:59 Verty: 4.4.38
21:59 karolherbst: imirkin_: it doesn't matter, prior 4.10 even 07 can hang
21:59 imirkin_: oh yeah. 4.4 is missing *tons* of fixes in that area.
21:59 imirkin_: karolherbst: can, but doesn't often.
21:59 karolherbst: especially the gddr5 fix
21:59 imirkin_: yes. esp that one :)
21:59 imirkin_: but others too iirc
21:59 Verty: building a kernel it is than :)
22:00 karolherbst: imirkin_: some cards have just super "tight" voltage entries in the vbios
22:00 karolherbst: so even a slightly lower voltage can have terrible consequences
22:00 karolherbst: Verty: no kernel packages for your distro?
22:01 Verty: not newer than 4.4 unfortunately
22:01 karolherbst: not even in external repositories?
22:02 karolherbst: for ubuntu there are usually ppas, but from the sound of it, you are using debian, right?
22:02 Verty: valid point :)
22:02 karolherbst: ohh wait
22:02 karolherbst: 4.4 was ubuntu 16.04 I think
22:02 Verty: running slack current... nothing so far
22:02 karolherbst: uhh slack
22:11 Verty: yesss..? :)
22:51 Verty: right 4.10-rc2 in itself didn't change anything performance wise....
22:51 Verty: it didn't crash xorg so far at least :)
22:55 karolherbst: Verty: no, but you can reclock now
22:56 Verty: right... when saying it didn't crash.... it crashed :)
22:56 Verty: how's the reclocking done?
22:57 karolherbst: through the pstate file
23:06 skeggsb: hakzsam: i've been using your patches on gm206 a lot recently, can't fault them so far :)
23:06 skeggsb: hakzsam: aside from enabling gl4.3 making piglit run some tests that trigger copy engine faults, but, i doubt that's related to your work
23:08 Verty: karolherbst: it feels faster but $game (e.g. broforce) is still terribly slow
23:09 karolherbst: some are
23:09 karolherbst: you could verify if the clocks are set
23:09 karolherbst: cat pstate and check the last line
23:14 Verty: it seemed to pick it up... until it crashed again (this time with white squares and some dodgy ones :))
23:14 Verty: but the speed increase was only noticable in Enlightenment
23:17 karolherbst: mhh, well
23:17 karolherbst: there are some things I still need to figure out
23:17 karolherbst: or somebody else
23:17 karolherbst: no access to gpus with issues though
23:17 karolherbst: which makes it hard to figure anything out
23:18 Verty: I'll setup the prop driver for now but if you want me to test something let me know
23:20 Verty: also I'm thinking of replacing the 660 so let me know if you want it :)
23:32 jouboyzandgals1: so we are looking at some sort of nominal ebergy consumption with the performance patches, let me stress out, that our planet has enough energy, before it will be destroyd
23:33 jouboyzandgals1: we are likely to see planet earth destoyd before we consume all the available energy that is
23:33 Tom^: the sun is shining, and the earth is spinning. your point being?
23:34 jouboyzandgals1: my point is earths core is full of energy, probably there is global warming that kills most of us, before we consume those
23:57 RSpliet: skeggsb: hereby drawing your attention to the regression since 4.8 on NVAC related to the SPLL workaround - sent both an e-mail to the ML and a trace to the mmio dumps