08:58hakzsam: imirkin, I can only test on gk107/gm107 for now
09:07mezo: hey, i just compiled from here https://github.com/karolherbst/nouveau.git. how do i see if im on the right version? the boost file seems missing?
09:07karolherbst: skeggsb: in general, the idea of my design was, that we could set the "wanted" pstate/cstate without waking up the gpu and if we resume, we just reclock according to this
09:07karolherbst: skeggsb: but I got a crash doing this. Have to investigate it
09:08karolherbst: skeggsb: so the general idea is that we always safe to things: 1. to what we _want_ to reclock 2. to what we _have_ reclocked
09:08karolherbst: because those things are not always the same, even after a successful reclock
09:09karolherbst: mezo: you need the right branch
09:10mezo: thats my fault :)
09:10karolherbst: skeggsb: in fact, I would like to just reclock on init and remove all that checks against "did we reclock at least once" to simplify stuff again
09:10karolherbst: but this has to wait a little I suppose
09:11karolherbst: mezo: but chances are it crashes your machine now, because I am currently working on it
09:12mezo: what are the big changes?
09:12karolherbst: review stuff
09:12karolherbst: but I am +quite sure I didnt break anything, yet
09:12karolherbst: otherwise the kepler_maxwell_reclocking has a good enough state
09:15Tom^: in a moment il report if a 770m works on that branch too.
09:30Tom^: karolherbst: yep the 770m clocks to 0f and runs cs:go , so i guess it works. :p
09:33jelle: Tom^: it werks
09:34jelle: now how did xrandr werk
09:34Tom^: karolherbst: ^ and a k1000m works too.
09:34jelle: Tom^: no wait I didn't try re-clocking yet
09:34jelle: Tom^: bug me tonight ;-)
14:48Lekensteyn: Heh, KDE Plasma changes the background wallpaper every version it seems, I thought my screen was broken >.>
14:49Lekensteyn: so, I just did some PCIe config dumping on Win10, hopefully it teaches me more about what Windows/Nvidia do while runtime-suspending
14:50Lekensteyn: I also discovered that the HDMI device really disappears from the PCI bus when no HDMI display is connected, and re-appears when plugged in (it is unrelated to runtime suspend)
14:50Lekensteyn: karolherbst: your suggestion to remove the alsa device was not that bad :)
14:50karolherbst: it makes the most sense in my eyes :p
14:51karolherbst: though laptops with no digital audio output and only HDMI audio might want to use hdmi...
14:52Lekensteyn: do they exist...?
14:52karolherbst: if you care about sound that much, you have a laptop with S/PDIF output, that simple
14:52karolherbst: no clue
14:52karolherbst: I have two digital audio outputs... and I thought you always have at least one
14:52Lekensteyn: maybe we can detect (based on the DSM ACPI method?) whether the audio device will disappearor not
14:53karolherbst: I have one optical and one non-optical
14:53Lekensteyn: will have to dig in the documentation I found yesterday :)
14:58karolherbst: well, now I messed something up
14:58Lekensteyn: what happened?
15:00karolherbst: I messed up my reclocking stuff
15:04karolherbst: yeah, waiting inside an interrupt handler, very smart
15:38karolherbst: Tom^: did you actually tried to reclock with my newest version?
15:38karolherbst: it should crash so hard...
15:48Yoshimo: btw carol if you use the past on the auxiliary you don't have to use the past of the actual verb, so your sentence should be "did you try"/"have you tried"
16:00rhn: does the nvidia driver do away with vspaces completely on Maxwell?
16:02rhn: there's something that changed since Kepler and I'm not sure what exactly
16:04imirkin: maxwell got rid of immediate vertex submission, if that's what you mean
16:04imirkin: which is super-annoying for blits
16:05rhn: imirkin: no, I mean the IOCTLs that are needed for initialization and mmapping
16:08imirkin: i think there's a vspace2 now
16:08imirkin: that is the state of the art knowledge on this stuff... i haven't gone digging in recent blob versions though
16:09imirkin: i think pascal changes a lot of this stuff around
16:09imirkin: but maybe maxwell2 does as well
16:09rhn: imirkin: thanks. I can see that there's lots of MEMORY2 calls, but no more VSPACE
16:10rhn: Kepler already worked this way, but the old methods worked as well
16:10rhn: I guess it's time to actually discover what the new way is
16:10imirkin: send patches ;)
16:11rhn: as soon as anything useful comes out of it :P
16:26karolherbst: always validate user input :D
16:31karolherbst: skeggsb: if you want you can look over my branch again now and see if you like it more this way. I still have some things to take care of (validating earlier behaviour and some error checking), so I won't send out a series today.
18:09Tom^: karolherbst: _v5 ?
18:09Tom^: karolherbst: thats what im on now playing cs;go with like a madman
18:09karolherbst: Tom^: well, the stuff I push recently :p
18:10karolherbst: at least I had it broken locally
18:10karolherbst: maybe you pulled when it was till good
18:10karolherbst: or I never pushed the broken state
18:10Tom^: karolherbst: 2 days ago i pulled it
18:10karolherbst: ahh, then you are fine
18:11Tom^: and got a friend with a 770m pulled it 8 hours ago try cs:go, now i just need to get this other friend with k1000m to test things when hes home
18:11Tom^: i figured you might wanna know if various cards reclocks
18:11karolherbst: I want to know when a card doesn't reclock
18:12jelle: Tom^: o/
18:12karolherbst: I have a nice RE task for somebody who wants to hack at nouveau around
18:12karolherbst: totally uncritical section, but still important to have :p
18:12karolherbst: I would do it myself, but I lack the needed amount of time
18:14Tom^: im not sure i qualify enough to RE things, i think i lack knowledge about various things to do so. :p
18:16karolherbst: it is just a vbios table :p
18:16karolherbst: for sw overheating protection
18:16karolherbst: and other things maybe
18:16karolherbst: but only the sw overheating protection things are important
18:17karolherbst: the table tells the driver something like that: if 3 °C above the software crit temperature, clock down 3 cstates per second
18:17karolherbst: or something like that
18:19karolherbst: Tom^: UNK50 table in vbios :p
18:20karolherbst: entriy size is like 28 bytes :/
18:21Tom^: wasnt that the thing you wanted me looking at when i didnt have a resource2 file?
18:21karolherbst: mupuf: I guess you also won't have time any time soon?
18:21karolherbst: Tom^: resource2 file?
18:21Tom^: so i couldnt use any nva* tools on the blob
18:22karolherbst: no clue
18:22Tom^: got 3 week vacation in a week, might see what i can figure out. but dont hold your breath tho
18:23karolherbst: well the procedure is fairly simple:
18:23karolherbst: fake a temperature and collect what nvidia does
18:24karolherbst: modifiy the vbios
18:24karolherbst: repeate data collecting
18:24karolherbst: at some point you can create hypothesis about what the fields are for in the vbios
18:24karolherbst: verify them and you are done :p
18:36karolherbst: skeggsb: I see that kepler has a maskaddress of 0x022554 and maxwell has 0x021c14 for the RAM
18:36karolherbst: passed to gf100_ram_create
18:37karolherbst: are you sure the maxwell one is right?
18:41karolherbst: skeggsb: I am especially curious, because in traces 0x021c14 doesn't seem to be touched on gm108
18:43karolherbst: ohhh wait
18:43karolherbst: you are right
18:43karolherbst: I was looking at a nv108 trace...
18:54imirkin: anybody around with a fermi who could test a mesa patch by running 1 piglit test?
18:57Lekensteyn: imirkin: which one? (have a GT 425M here)
18:58imirkin: Lekensteyn: oh awesome. patch: https://patchwork.freedesktop.org/patch/99103/
18:58imirkin: Lekensteyn: piglit test: bin/pbo-readpixels-small -auto
18:58imirkin: make sure it passes after applying the patch
18:58imirkin: (on top of git master)
18:59Lekensteyn: ok brb, setting up system
18:59imirkin: [and nothing untoward in dmesg as a result of running it]
19:21Lekensteyn: imirkin: what kernel is needed? Is 4.6.3 sufficient?
19:22imirkin: Lekensteyn: any kernel is fine
19:24Lekensteyn: maybe my hardware is defect, I cannot even load nouveau normally http://sprunge.us/OBLJ
19:24Lekensteyn: this is that laptop that I abandonded because pressing at a bad point would result in an instant poweroff :P
19:25Lekensteyn: I can still try to run the tests if you think it is worthwhile
19:25imirkin: file a bug, hopefully skeggsb can have a look
19:25imirkin: and/or try an older kernel
19:28imirkin: Lekensteyn: or if you feel like trying the latest and greatest, pmoreau makes some iso's at https://nouveau.pmoreau.org/
19:29imirkin: either way, this is quickly getting to the "not worth it" point, i'm sure someone else will have a fermi that works
19:30Lekensteyn: I can remember that the kernel included with arch iso 2016.01.01 also exhibited the same issue
20:07jelle: karolherbst: your stable_reclocking_kepler_v5 works fine on my quadro k100m!
20:07jelle: your branch
20:08Tom^: karolherbst: now get it upstreamed! :)
20:12Yoshimo: 4.8 is still open, isn't it? ;)
20:38mezo: karolherbst: i compiled the latest reclocking code from ur git and now my system freeze 100% when i change pstate
20:48karolherbst: mezo: yeah, you have to pull the updated branch
20:48karolherbst: I had to work on it
20:48karolherbst: Tom^: working on it :p
20:49karolherbst: though I doubt it will make it into 4.8
20:53mezo: karolherbst: what is the updated branch (sry for stupid question)
20:53Tom^: mezo: https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5
20:54Tom^: or well the stable_reclocking_kepler_v5
20:55karolherbst: mezo: same name
20:58karolherbst: well I hope I didn't break anything within the last push, but it worked at least here and I also had some crashes today (which I fixed)
20:59mezo: i gonna report soon
21:00Tom^: karolherbst: il rebuild and report back. :p
21:03mezo_: seems to work like it was before
21:04karolherbst: good :)
21:05Tom^: karolherbst: yea seems to be fine here aswell
21:53airlied: imirkin: how much work would nir->nv50 be?
21:54karolherbst: airlied: nir is SSA, right?
21:55karolherbst: ohh wait, we had this already
21:55RSpliet: airlied: I guess that depends on whose time it is?
21:55RSpliet: (assuming the quantity of work is hours)
21:56imirkin: airlied: a ton
21:57imirkin: airlied: the main issue is either (a) going out of ssa in nir or (b) converting all of the nv50 ir lowering passes to work on ssa [including some pretty nasty control flow issues]
21:58karolherbst: I think nir can go into non-ssa form
21:58imirkin: airlied: most importantly, i see no benefit in it... just doing a ton of work for no reason at all. i assume you're asking re vulkan, in which case spir-v -> nv50 ir would be just as much or even less work.
21:58karolherbst: I do not know if that is possible from ssa-nir to non-ssa-nir
22:01imirkin: airlied: fyi, pmoreau has started on a spir-v -> nv50 ir adapter, but i don't think he's properly thought the ssa -> non-ssa bits. i think it can be done with some fairly modest cleverness in a two passes
22:45airlied: imirkin: okay the big problem with spir-v->nv50 is lack of interstage optimisations
22:45airlied: unless nv50 doesn't interstage
22:48imirkin: airlied: interstage like what?
22:49airlied: cross shared stage optimisations
22:49airlied: shader stage
22:49airlied: what glsl linker essentially does now
22:49imirkin: ah ok. yeah, nv50 ir doesn't do anything of that sort
22:49imirkin: however ... i wonder how necessary that actually is
22:49airlied: there are plans for nir to do some of that
22:49imirkin: it'd be quite simple to hook that up though, i think
22:50imirkin: albeit slow - basically you'd compile each thing once, and then create per-combo "optimized" groups
22:51imirkin: by dropping the relevant inputs/outputs
22:51imirkin: but probably not a horrible idea either, since you could do that "in the background", while you still had a working shader for drawing
23:33Tom^: hm i just noticed my cpu usage spikes to like 80% when i move my mouse unless i set hwcursor to false, but with that it flicker badly :p
23:39Tom^: any known downsides with using the modesetting driver instead? seems to run okay so far.
23:40Tom^: doesnt spike in cpu usage when moving the mouse either
23:43imirkin: mmm... if you use X11 stuff, it sucks. however 99% of modern applications don't really make use of X11 things.
23:43Lekensteyn: so, I fixed the PXE boot menu for the nouveau iso https://github.com/hakzsam/archlive-nouveau/pull/10
23:43Tom^: imirkin: guess i should be fine then
23:43imirkin: Tom^: would probably be good to figure out why nouveau ddx has issues with the mouse...
23:44Lekensteyn: imirkin, skeggsb the fermi hang issue is now reported with three dmesg from the nouveau iso https://bugs.freedesktop.org/show_bug.cgi?id=96968
23:44imirkin: Lekensteyn: thanks. this is totally out of my area, hopefully skeggsb will have a look.
23:45Tom^: imirkin: if you openup top, and start jerking your mouse, you dont see a high cpu usage?
23:45Lekensteyn: imirkin: btw, did you see my earlier observation today on the audio devices disappearing on Windows when there is no HDMI monitor connected?
23:45ownaginatious: Hi everyone!
23:46imirkin: Tom^: X is at 5%... seems semi-reasonable
23:46ownaginatious: So I recently bought a 4K 60Hz TV. I can get it running at 30 Hz under HDMI 2.0, but not 60 Hz. Does the nouveau support 4K at 60Hz over HDMI?
23:46Tom^: imirkin: hm let me record a clip for you then. :p
23:46imirkin: Lekensteyn: yes, i did.
23:46imirkin: Tom^: attach perf to it, see where that cpu time goes
23:46ownaginatious: I'm using a 960 GTX
23:46imirkin: ownaginatious: congratulations, i believe you're the first person to try to do this.
23:46ownaginatious: haha, yay!
23:47imirkin: the prize you win is that you get to try to debug it :)
23:47ownaginatious: lol okay
23:47Lekensteyn: I hope to get the changes in 4.8 before the pci/pm patches cause hangs, would it be possible to get some acks?
23:47imirkin: fwiw there's a kernel param to let you up the max hdmi clock speed
23:48imirkin: ownaginatious: nouveau.hdmimhz iirc -- you can set it to = whatever, and it'll let the 60mhz modelines go through.
23:48imirkin: whether more setup is necessary for HDMI 2.0... who knows
23:49imirkin: ownaginatious: fwiw DP should work fine though, if available on your board. (assuming that MST isn't needed)
23:49ownaginatious: Unfortunately, the TV only has HDMI inputs.
23:50imirkin: right, of course - why *would* a brand new 4K tv have DP ports...
23:51imirkin: ownaginatious: the low friction path is to just install the blob and then buy an amd gpu next time.
23:52ownaginatious: hmm, the proprietary nvidia drivers don't work either (only under Windows).
23:52ownaginatious: Allegedly, they used to work, but were broken. Super hard to get support from their forum... pretty sure their Linux driver team is literally one guy, lol
23:53imirkin: either way, if you want good open-source support on linux, get amd. or intel. definitely not nvidia.
23:55ownaginatious: *sigh* yeah, you're right. I'll probably look into getting a Radeon RX 480 when they come down to normal price.
23:55imirkin: if you want to try something easy with nouveau, boot with nouveau.hdmimhz=600
23:55imirkin: however i haven't the faintest clue whether that will work
23:55ownaginatious: What does setting the hdmimhz setting do exactly?
23:56imirkin: it tells the driver what the max allowed tmds speed is for hdmi connectors
23:56imirkin: there's allegedly a "real" way of doing it, but we don't really know what it is
23:56ownaginatious: I see
23:56imirkin: so... for now it's 165mhz on tesla, 225mhz on fermi, and 297mhz on kepler+
23:56imirkin: but user-overridable
23:56ownaginatious: Hmm, I guess I'll check it out and see if anything explodes, haha
23:56imirkin: the driver filters out any modelines that require a pixel clock faster than that rate
23:57imirkin: i believe the 4K @60 modeline requires 533mhz
23:58ownaginatious: Ah okay. Thanks! I'll try it out when I get home later :) *crosses fingers*