00:11 mooch: imirkin, i have a gf119, but i'm about to sell it, i think
00:12 imirkin: are you running nouveau on it right now?
00:16 mooch: no lol
00:16 mooch: i'm running a radeon right now
00:20 imirkin: ok, then that won't help me
02:55 lapion: imirkin, which ram is normally relocated ? the vram or the systemram ?
02:57 imirkin: lapion: vram isn't a concept that's accessible by the system
02:57 imirkin: lapion: stuff is laid out in physical memory space... like BAR's and actual RAM. this is all configured by the bios, i thought.
02:58 imirkin: if a pci bar and physical memory overlap, then i dunno what happens
02:58 imirkin: "don't do that" :)
02:58 imirkin: but it's not like physical ram has to be mapped to start at 0
02:58 imirkin: the bios has various ways of remapping it
03:29 imirkin: orbea: interesting. so actually it's the *road* that appears to be getting blended on there wrong. i think it's supposed to get culled out and it's not.
03:30 orbea: Interesting
03:32 imirkin: i think it has to do with polygon offsets
03:33 imirkin: when i force-disable the polygon offset it doesn't look as bad
03:33 imirkin: (but has lots of other nasty artifacts)
03:34 orbea: is this entirely the nouveau backend or could it be the graphics plugin too (gliden64)?
03:35 orbea: turning off the framebuffer emulation for gliden64 will fix it, but that is required to fix several other bugs
03:35 imirkin: i mean ... gliden64 might be relying on something that's not well-specified
03:37 imirkin: although given that it works on nv50 and llvmpipe and intel, i'm gonna guess it's something nouveau does poorly
03:38 orbea: yea, that makes sense
03:42 imirkin: unfortunately i have no idea what the difference might be
04:11 lapion: imirkin, in memtest I can see that the last gig is relocated but how can I see if the kernel does not override this ?
04:12 imirkin: lapion: sorry, it's a bit outside my expertise
06:47 gnurou: skeggsb: just sent a big ball of poo your way - hope you won't mind the big refactoring >_< it's for the greater good (more firmwares!)
06:48 gnurou: ah damn, patch 5 was too big and it got moderated on the list
06:52 pmoreau: gnurou: Moar? O.O
06:52 pmoreau: Have to check my inbox
06:52 gnurou: pmoreau: not today though
06:52 gnurou: this just sets the infrastructure for moar firmwares
06:53 pmoreau: Right, but at least the infrastructure is there, which is a good step in the right direction!
06:53 gnurou: think of it like a cargo cult: we build runways, and hope that the firmwares will land there as a result
06:53 pmoreau: If the infrastructure is there, then the firmwares are most likely on the way
06:54 gnurou: well they are running on my machine at least, which is why I sent this (*teasing*)
06:54 pmoreau: Oh, and it could benefit to PMU firmwares as well! Nice
06:54 pmoreau: Grrr! Teasing is not allowed! :-p
06:55 gnurou: I have more stuff regarding PMU actually, but again, without a firmware, cannot send the code :/
06:55 pmoreau: PMU firmwares for Pascal only or Maxwell as well? (And Volta? :-D)
06:55 gnurou: I hope to release the GM20B PMU firmware in a first time so the support code can land
06:56 gnurou: pmoreau: don't know yet the extend of this - but new chips will be privileged over old ones, although I will try to make sure everyone gets decent support
06:56 gnurou: and again, I have no ETA - things are just starting to work on our end
06:56 pmoreau: Thanks for doing that!
06:56 gnurou: it's such a bloody mess, frankly
06:56 pmoreau: No problem about the ETA, you never know what might disturb plans… :-/
07:10 karolherbst: gnurou: next time I will check the IRC logs before posting crap on the list :D
07:10 gnurou: karolherbst: which crap?
07:11 karolherbst: pinging about the 5th patch
07:11 gnurou:loves crap, as his latest code submission attests
07:11 gnurou: karolherbst: ah, don't mind
07:12 karolherbst: but I am looking forward to see some PMU interface documentation :)
07:12 gnurou: karolherbst: I hope this will follow next
07:12 karolherbst: yeah, first images then docs would be messy and a questionable act indeed :p
07:13 gnurou: you know we would never do that *ahem*
07:13 karolherbst: ha, I already see those GTX 980 nouveau benchmarks, being close to the 780 ti :D
07:14 gnurou: but at the same time I cannot publish code unless there is a firmware file that can be used with it
07:14 karolherbst: ohh wait
07:14 karolherbst: the 780ti is faster anyway
07:14 karolherbst: I meant the 980 ti of course
07:14 karolherbst: gnurou: true, but with documentation there is no such problem
07:15 karolherbst: if you code against the docs, who cares if there is an image or not?
07:16 karolherbst: anyway, I REed the pmu counter interface anyway and will adjust my pmu counter code to the nvidia interface
07:16 karolherbst: :D
07:16 gnurou: you're right, although docs are more difficult to negociate for me than code, for some reason :/
07:17 gnurou: probably because review takes longer - with code I can always argue that we already published it with some Tegra kernel
07:17 karolherbst: true
07:17 karolherbst: and the annoying guys won't understand the code anyway
07:19 mupuf: karolherbst: they won't understand the doc either
07:19 mupuf: OMG, this scatter-gather piece of engineering is amazing, we cannot disclose any of it!
07:20 karolherbst: well, but they think the do!
07:20 mupuf: AKA, an MMU
07:20 mupuf: they lack the context
07:20 karolherbst: sure, but code is worse for them
07:20 karolherbst: (to understand)
07:20 karolherbst: or they don't even try
07:21 karolherbst: depends on the doc though
07:23 karolherbst: gnurou: will try to take a look later the day/week
07:23 gnurou: karolherbst: thanks! note that this is mostly moving stuff around, so it is harder to follow than it should
07:24 karolherbst: sure
07:24 gnurou: I think looking at the end result instead of the individual patches makes it easier to understand what it does
07:24 karolherbst: but mistakes still happen
07:24 karolherbst: ohh
07:24 karolherbst: yeah, got it
07:24 karolherbst: you already hinted at this in the cover letter I think
07:24 gnurou: I have been thoroughly testing it on many cards with many different firmware formats, and it looks solid to me
07:25 karolherbst: nice
07:26 karolherbst: I guess you didn't had any chance to check if it is possible to use the nouveau pmu image after your rework?
07:26 gnurou: the patchset doesn't change any of the PMU code, so that should not change
07:26 karolherbst: k
07:27 karolherbst: but maybe it is easier to full reset something, but then again, the order messes things up anyway
07:27 gnurou: and at the end of the day, secure boot is still performed the same way - it's just that we have more hooks to plug into and the code is more cleanly organized
07:27 karolherbst: so basically the PMU needs to be init after the other falcons in any case
07:27 karolherbst: even with the signed pmu firmware, right?
07:27 gnurou: with signed PMU firmware the PMU is started by secboot
07:28 gnurou: so the PMU subdev must acknowledge that
07:28 gnurou: and assume firmware is already loaded and started at init time
07:28 karolherbst: sure, but the is only possible after the GR was started already or after the PMU performance secboot for all the other falcons
07:28 gnurou: with signed PMU firmware, the PMU is used to start the other falcons
07:29 gnurou: so the order is secboot -> pmu -> GR
07:29 karolherbst: ohhh I see
07:29 gnurou: the advantage of this being that you can now restart GR falcons without redoing the entire secure boot
07:30 gnurou: you just need to send the right command to the PMU
07:30 karolherbst: sure, but what happens when the pmu has to be restarted?
07:30 gnurou: eh.
07:31 gnurou: I don't know if we considered this, but I suppose you can either (1) send a command to the PMU to restart itself, or (2) redo secure boot from start
07:31 gnurou: (1) seem plausible, unless the PMU is completely crashed
07:32 karolherbst: well, it is nouveau we are talking about, so the PMU might be able to crash if we send enough garbage to it, dunno
07:32 karolherbst: we don't have the pmu code, so we can't investigate anyway
07:32 gnurou: in the worst case, redoing secure boot will work
07:32 karolherbst: but the gr can stay as it is then?
07:33 karolherbst: or would it also has to be restarted?
07:33 gnurou: unless the PMU is explicitly commanded to reset them, I think so, yes
07:33 karolherbst: okay sounds good then
07:33 gnurou: with signed PMU firmware the ACR only sets PMU up, I believe
07:34 karolherbst: this will be fun to adjust the code for the PMU thing :/
07:35 karolherbst: I doubt we could just disable specific things it does?
07:35 karolherbst: like currently we read out the power sensors on the host and I think the blob does it on the PMU
07:35 karolherbst: no idea how that will work out
07:36 karolherbst: in the end we would need to move that stuff into our pmu code as well, which will be really painful
07:36 gnurou: well I would not expect a fully-featured PMU release in a first time anyway, so that should not be a problem :/
07:36 mupuf: karolherbst: we'll do what is necessary
07:36 gnurou: seems like we are going to continue doing custom Nouveau firmware builds for a while
07:37 karolherbst: mupuf: sure, just saying it will be painful
07:37 mupuf: yes...
07:37 mupuf: we can move some of it to a different fw, like pcopy[1]
07:37 karolherbst: is there a reason we don't use all the pcopy engines by the way?
07:37 karolherbst: I am sure I asked already :D
07:38 mupuf: we use one for FB acceleration
07:38 mupuf: that's about it, AFAIK
07:38 karolherbst: I see
07:38 karolherbst: I guess we could do more things with those?
07:38 mupuf: yes
07:38 mupuf: quite probably
07:39 karolherbst: gnurou: mhh troublesome
07:39 karolherbst: gnurou: but I hope we will get to use the nvidia interface from the start for the parts the firmware implements?
07:39 karolherbst: gnurou: anything else would be…. well too annoying to deal with
07:39 gnurou: the interface should be the same, but I would not expect full functionality immediately
07:40 karolherbst: k, sounds good
07:40 gnurou: in any case, the PMU support code will be able to deal with changes in the protocol, the same way we are dealing with firmware formats differences in secboot
07:40 karolherbst: we need at least fan controls and the hw thermal protection setup :p
07:40 gnurou: I know, fighting to get these in...
07:41 karolherbst: memory reclocking bits aren't as important, because if it comes to the worse, we just reset the pmu, upload our image, memory reclock and redo sec boot :D
07:42 karolherbst: gnurou: mhh, no I am thinking about what we use the pmu for anyway, and there isn't much left besides memory reclocking and vsync (until fermi?)
07:43 karolherbst: mupuf: seems like we need to test our i2c pmu code
07:44 mupuf: karolherbst: write the tests ;)
07:44 karolherbst: but I really would like to write that stuff in C
07:44 karolherbst: mupuf: my test would be like this: move the iccsense stuff onto the pmu and see how that works out :D
07:45 karolherbst: allthough it isn't that much actually
07:45 karolherbst: just write the sensor config
07:45 karolherbst: read out the values
07:45 karolherbst: and that's pretty much it
07:45 karolherbst: no idea what nvidia does though
07:45 mupuf: testing the PMU is a bit tough
07:45 mupuf: but I guess stressing the command submission would be a good idea
07:46 karolherbst: already done
07:46 karolherbst: there is one issue left basically
07:46 karolherbst: but it is pretty much stable
07:46 karolherbst: 2000 commands per second are no big deal
07:46 mupuf: should you ask ben to merge it to a "tests/" folde
07:46 mupuf: r
07:47 mupuf: but do you verify that it actually does what you want?
07:47 karolherbst: yes
07:47 mupuf: how?
07:47 karolherbst: well, memory wasn't screwed up and the clock changed :p
07:47 mupuf: lol
07:47 karolherbst: I spend more time than this though
07:47 karolherbst: we actually had some bugs
07:48 karolherbst: like we didn't set the interrupt flags right on the pmu after handling one
07:48 karolherbst: fun bug
07:48 karolherbst: and the bug occured like 1 in 10k commands or so
07:49 karolherbst: or my dyn reclocing thing is able to ping the host every 10ms about the new load
07:49 karolherbst: stuff like that
07:49 karolherbst: 1ms was a bit too tough on the reclocking code so the interrupts were piling up
07:49 karolherbst: especially because the host also does memory reclocks sometimes as the result of the ping
07:51 karolherbst: I think my heaviest stress test was: while true echo > reclock in one shell; while true; cat current_load; in another shell and running glxspheres64 ontop of that :D
07:53 karolherbst: there is still a bug though where the pmu starts to send commands and things get slow, have to investigate this
12:42 karolherbst: … we have to fix the vbios table offsets now… cause even fairly recent gpus might be reclockable and have those silly vbios :D
12:43 karolherbst: I guess I will pause my mesa stuff and focus on that
12:43 karolherbst: except skeggsb wannts to do this?
12:52 RSpliet: karolherbst: think skeggsb's todo list already included stuff like atomic modesetting... that'd keep him occupied for the coming few weeks ;-)
12:53 karolherbst: :)
12:53 karolherbst: k
12:53 karolherbst: then I will do that
12:53 karolherbst: we had somebody here who actually wanted to look into it though...
12:53 karolherbst: I should check that out
13:00 vitis: Hello i have a question i didn't find answer to it in logs or anywhere. The website says there's experimental support for pstate on fermi and kepler but when i booted with the nouveau.pstate=1 my fermi card gt635m cannot be clocked when i try to write a pstate it says "Function not implemented"
13:01 vitis: did i miss some more information anywhere on how to set it up?
13:09 pmoreau: vitis: Changing pstate on Fermi isn’t available yet, it is still a WIP.
13:13 vitis: well since it says experimental support i thought that it allows some clocking. Ok then gotta wait for it to be finished :)
13:41 imirkin_: vitis: where does it say experimental support?
13:44 RSpliet: imirkin_: a quick search on the wiki only reveals https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
13:44 pmoreau: RSpliet: For the NvBoost value?
13:45 RSpliet: pmoreau: the removed "pstate" value
13:45 RSpliet: "WARNING: Power management is a very experimental feature and is not expected to work."
13:46 pmoreau: Mh, okay, I was looking for the "Fermi" string :-D
13:52 vitis: well the home page said "Experimental support for performance level selection (also known as "reclocking") " in the Current status so that's why i expected it to work at least on some basic clocking
13:55 RSpliet: vitis (in case you read the backlog): it also says "on Kepler and Tesla G94-GT218"
13:57 imirkin_: RSpliet: have you been able to make any progress on reclocking?
13:58 RSpliet: I've spent some time before XDC on finding Fermi PMU firmware, but no success
13:58 imirkin_: should be in the repo, no?
14:21 karolherbst: in theory yes
14:21 karolherbst: isn't the pmu just uploaded through mmio?
14:21 imirkin_: it's normally right there in the mmio trace. perhaps they got creative...
14:21 karolherbst: with maxwell2 they did
14:21 imirkin_: [for pre-gm20x that is]
14:22 karolherbst: I doubt it
14:22 karolherbst: it should be just inside the trace
14:23 RSpliet: to the best of my knowledge NVIDIA maps into the PMUs channel pagetables
14:24 RSpliet: they apparently have a page-swapping mechanism to manage bigger PMUs in limited code space
14:24 imirkin_: well, my direct recollection is that this isn't done for video. but i'm 99% sure that's not done for PMU either. but i don't remember.
14:24 imirkin_: ew
14:24 RSpliet: for that it has to be mapped :-)
14:24 imirkin_: i never considered the "code > 64k" issue
14:24 imirkin_: 64k should be enough for anyone!
14:25 RSpliet: don't ask me about the specifics though, this is second hand knowledge
14:27 karolherbst: RSpliet: did you actually check within the mmiotrace?
14:28 RSpliet: karolherbst: look at how nvagetpmu gets the firmware for some of the details. iirc 10a110 contains the channel pointer, 0x10a47c the (virtual?) pointer to the code segment. There's a few other registers they use to DMA in data(/text) from there, that take an offset and size.
14:29 RSpliet: it's certainly not the same as how nouveau uploads text/data
14:29 imirkin_: blob uploads a single code/data combined thingie
14:29 imirkin_: [not for ctxsw fw, but for the others]
14:30 karolherbst: RSpliet: I thought the tool was used to get the pmu without having to parse it out of the mmiotrace
14:30 RSpliet: the code is mapped into the channels VM space for a reason ;-)
14:32 karolherbst: well, you can also just read the pmu out trhough the dmem/imem window afaik
14:33 imirkin_: karolherbst: either way, don't worry about it - i'll try to scrape it out from somewhere
14:33 karolherbst: yeah
14:38 RSpliet: karolherbst: I believe the problem with reading from the imem window is paging. You can only read currently paged in code, and their mapping to imem "pages" is not the identity mapping. In other words, you'll read out those parts of the code mapped in (potentially not everything), but in arbitrary page order
14:44 karolherbst: mhh I see
14:54 karolherbst: hakzsam: the k4200 is also a kepler ;)
14:54 karolherbst: and actually quite fast
16:37 mezo: hey, maybe someone here can help me with my problem :) i recently installed debian stretch and gdm starts fails to start. with the proprietary driver everything works. i made a screenshot of the journal output: https://goo.gl/photos/fAC3cqFNXtbDJWK89
16:39 imirkin_: what does "Die Resource ist zur Zeit nicht verfuegbar" mean?
16:39 mezo: i hate it, when the log is translated - why? -.-
16:40 imirkin_: mein Deutsch ist nicht gut ;)
16:40 mezo: it means: the resource is not not aviable
16:40 mezo: *at this time
16:40 imirkin_: [that's about the limit of my knowledge]
16:40 imirkin_: ok, so that most likely means X didn't start
16:40 imirkin_: got an xorg log?
16:41 mezo: i have to reboot, to check the xorg log. im brb
16:53 mezo: hm, i cant find any xorg log. if i start xorg manually it creates one, but xorg dont seem to have problems to start.
17:15 mezo: checked again. i cant find any xorg log...
17:16 imirkin_: ask debian folk? doesn't sound like a nouveau issue.
17:16 imirkin_: at least nothing to indicate that it is.
17:17 mezo: ok, thank you :)
18:35 vita_cell: kalorherbst my system crashes sometimes, and here is red line in dmesg
18:35 vita_cell: nouveau 0000:01:00.0: priv: HUB0: 085014 ffffffff (1f70820b)
18:36 vita_cell: http://dpaste.com/2E0EG69
18:40 imirkin_: i get that too on my GK208B
18:42 mezo: hey, its me again. i just tried fedora 25 to make sure its not a debian problem and i encounter same problem there. screen goes standby/on in a loop. so i connected another screen with dvi and it works oO
18:42 karolherbst: vita_cell: if your system crashes there should be a more serious issue inside the log
18:42 mezo: my mainscreen is connected via displayport
18:43 vita_cell: probably, I still don't know why it crashes
18:44 imirkin_: mezo: i'll say again what i said before... let's see the xorg log
18:44 imirkin_: mezo: also from the photo you took it seems like KMS is working. but in hindsight, perhaps nouveau's just broken and you're getting the high resolution via efifb (and your bios) if you're booting in efi mode
18:45 imirkin_: mezo: and lastly, what GPU do you have?
18:45 mezo: gtx760
18:46 imirkin_: yeah that should be fine
18:46 mezo: i gonna check xorg later on fedora.
18:47 imirkin_: and it's a single monitor, no DP-MST nonsense?
18:47 mezo: single, yes
18:51 mezo: im bbl. hopefully with xorg logs
19:09 mezo: hmm, i begin to feel stupid, but there is no xorg log aswell. fedora use wayland by default and if i remember right debian tried to boot into wayland aswell. can this the reason why there is no xorg log and if so, what can i provide you?
19:22 imirkin_: that seems like a reasonable explanation
19:22 imirkin_: so ... why didn't weston or whatever start? :)
19:23 ajax: mutter is the weston server for gnome
19:23 ajax: excuse me, wayland server.
19:23 ajax: weston itself probably works fine, if'n you have it installed
19:24 imirkin_: mezo: listen to ajax. all i know about wayland is that i have little to no interest in using it :)
19:24 imirkin_: ajax, otoh, has a vested interest in getting people to stop using X
19:24 imirkin_: since he's the defacto X maintainer
19:24 ajax: that's... not how i would describe it
19:25 imirkin_: hehe
19:25 imirkin_: that bit was mostly a joke
19:25 imirkin_: perhaps it struck too close to home?
19:25 ajax: no, just inaccurate
19:26 ajax: i have no problem with people using X. i want it to keep working well.
19:26 imirkin_: sure
19:26 imirkin_: never said anything to the contrary
19:26 ajax: that need not mean that X own the output pipeline
19:26 ajax: and maybe some day wayland will be better at driving the output pipeline than X
19:26 ajax: that'd be super
19:26 imirkin_: ah, right - i confused X with display driven by X :)
19:26 imirkin_: a common mistake, i'm sure
19:26 ajax: anyway. just touchy about being misrepresented.
19:27 mezo: ajax i want to provide him the necessary logs for my screenproblem, but i dont know where i have to look for, because i cant provide xorg logs...
19:27 ajax: "but you said xorg.conf was deprecated!" no i didn't, i said we're trying to make sure you don't _need_ it.
19:27 imirkin_: hehe
19:27 ajax: "but you said xinerama was deprecated" oh come on you're not even listening to me a little now
19:27 imirkin_: i miss xinerama
19:28 ajax: it's still there, it works pretty well if you don't mind not having GL
19:28 imirkin_: back when multi-gpu Just Worked (tm)
19:28 ajax: (which has always been true of xinerama with the free drivers)
19:28 imirkin_: what would i do with GL anyways
19:29 imirkin_: [i'm only 95% playing devil's advocate]
19:29 ajax: mezo: the little gear icon on the gdm login screen should let you choose "Gnome on Xorg" as a session option
19:29 imirkin_: online reconfiguration with xrandr beats xinerama quite nicely :)
19:30 ajax: mezo: if that doesn't work, then the journal should have the normal Xorg log output
19:30 imirkin_: ajax: he earlier posted a screenshot that looked like it was in text mode
19:30 ajax: if it does work, then i'd try installing weston and launching Xwayland by hand and seeing what goes wrong
19:30 imirkin_: it was unclear whether this was a efifb terminal, or nouveaufb
19:31 mezo_: doesnt work on the live cd
19:32 imirkin_: mezo_: check logs for some advice from ajax
19:34 mezo_: for now i cant provide more thant that
19:34 mezo_: 15:32:25 localhost.localdomain gnome-settings-[2574]: failed to create device: failed to obtain org.freedesktop.color-manager.create-device auth Oct 11 15:32:25 localhost.localdomain gnome-settings-[2574]: could not find device: property match 'XRANDR_name'='DP-1' does not exist
19:35 mezo_: sorry... thats all the journal shows me when i connect the screen
19:36 imirkin_: none of this indicates a problem with nouveau
19:57 kwizart: hi, any good laptop vga card debugger here ? my optimus laptop doesn't POST after a reboot. Nothing is displayed, even during bios/efi
19:58 imirkin_: kwizart: do you have a T420s by any chance?
19:58 kwizart: is there any functions keys that would have some effects (like reseting some register)
19:58 karolherbst: kwizart: and how should we know about those?
19:59 imirkin_: mine for a long period of time stopped resuming after suspend
19:59 kwizart: imirkin_, nope, it's a weird noname laptop (clevo W650SG) Maxell1 card
19:59 karolherbst: kwizart: by any chance custom bios?
20:00 kwizart: nope,
20:00 kwizart: but I've managed to make it run under nvidia binary with libglvnd for the first time
20:01 karolherbst: mhh
20:01 karolherbst: did you by any chance disable the intel gpu?
20:01 kwizart: yep, as it was part of the setup (with xrandr)
20:01 kwizart: but not from bios (muxless as I understand)
20:01 kwizart: I don't remeber any option to disabled the intel gpu from bios
20:02 karolherbst: I know that their bios isn't the best
20:02 karolherbst: did you disable the bios emulation and stick with pure uefi?
20:03 kwizart: yes, I remember that I've certainly set thoses options
20:03 kwizart: +uefi - bios emulation
20:10 s0be: Just curious, I see messages like: nouveau 0000:01:00.0: priv: HUB0: 614900 00800000 (1a408200) whenever dri_prime fires up my discrete gpu. They seem to be logged at 'error' level, but it doesn't really spell much out.
20:11 imirkin_: s0be: i think that's logged at gpu powerup - i guess you have runpm enabled
20:12 imirkin_: skeggsb: i get that on boot on my GK208B as well ... what does it mean, and should it be kept at error level?
20:12 s0be: yep, everything works fine, just didn't like the red text when dmesg has color enabled
20:12 kwizart: I will try to get the support, but I wonder if they is shutcuts such as using Fn + 1 (that will run fan full speed)
20:13 Lyude: mupuf: ping, at XDC you mentioned there's easy optimizations in nouveau'mesa that no one's gotten around to doing, are those still around? I figured it might be a good way to get myself started on getting famililar
20:13 Lyude: ...
20:13 Lyude: *nouveau's mesa driver that no one's gotten around to doing, figured it might be a good way get started with working on mesa
20:13 imirkin_: Lyude: anything in particular you're interested in, and what hw do you have handy?
20:14 Lyude: imirkin_: hardware: not sure off the top of my head, but getting new chips wouldn't be a big deal. what I'm interested in: pretty much any TODOs in mesa that would be good for beginners. I've got a good bit of experience working with the modesetting side of things now, but nothing with rendering
20:15 Lyude: GTX760 is one chip I know I've got under my bed
20:15 imirkin_: ok cool, so a kepler
20:15 imirkin_: thinking ...
20:16 imirkin_: Lyude: do you have compiler experience?
20:16 imirkin_: (like, compiler design, have you heard of SSA, etc)
20:16 Lyude: imirkin_: a little bit! I took a bit of a compiler class stanford was doing online in HS, but ended up having to drop out so I could work on school work :(
20:16 Lyude: i'm more then willing to learn though
20:17 imirkin_: and also what sort of time commitment are you looking for? is this part of your RH work, or a free-time project?
20:17 Lyude: Part of my RH work but I wouldn't be surprised if I did it during my free time every now and then as well
20:17 Lyude: won't be my top priority though
20:17 imirkin_: k
20:17 imirkin_: well
20:18 imirkin_: if you have access to a GM20x chip, there are a bunch of exts that should be moderately easy to implement
20:18 imirkin_: https://trello.com/b/ZudRDiTL/nouveau
20:18 imirkin_: and should get you familiar with some core concepts
20:18 imirkin_: for an example, this one's 80% done: https://trello.com/c/IAqZXMmt/154-gm200-amd-vertex-shader-layer-viewport-index
20:19 imirkin_: i couldn't get the viewport index write to ACTUALLY work
20:19 imirkin_: but i also don't have the hw
20:19 imirkin_: so debugging was limited
20:20 mupuf: Lyude: I see you are in good hands ;)
20:24 imirkin_: it'd probably not be such a great move to try to get you to fix bugs that have stumped me for many years ...
20:25 imirkin_: tbh the main thing that sucks about nouveau is reliability
20:25 imirkin_: it crashes. a lot.
20:25 imirkin_: early and often
20:25 imirkin_: and it never comes back
20:25 ajax: ssh, don't tell her that
20:25 ajax: if they don't know it's impossible they won't know what can't be done ;)
20:25 imirkin_: hehe
20:32 Lyude: hah. anyway; I will look into getting my hands on a GM200
20:35 imirkin_: Lyude: IME these things work best when you propose a project that you will enjoy doing
20:35 imirkin_: Lyude: there are "larger" projects that are out there too, but those wouldn't be great to start with
20:36 imirkin_: Lyude: i would also encourage you to familiarize yourself with the rendering pipeline... you don't have to remember it 100%, but being familiar with the general terms helps
20:36 Lyude: I am familiar with that term at least!
20:36 Lyude: i've done a bit of reading up on how it works
20:36 imirkin_: if you claim to understand tessellation, i'll know you're lying
20:36 airlied: someone posted a realy evil GL picture somewhere last week
20:36 Lyude: didn't say I understood it, just that I read it ;)
20:36 airlied: write a sw tessellator, then you can claim to understand it :)
20:37 karolherbst: sure, why not
20:38 karolherbst: airlied: what is the status about nouveau and 4.9 by the way? heard anything?
20:38 airlied: karolherbst: don't think I'll be taking a pull request at this point
20:38 karolherbst: yeah... I thought as much
20:38 airlied: skeggsb ran into some last minute holes
20:38 airlied: Lyude: http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGL44PipelineMap.pdf
20:38 karolherbst: ....
20:38 Lyude: imirkin_: also tbh I'm pretty excited to work on any part of it
20:39 karolherbst: airlied: k. so no nouveau update for 4.9 as it seems
20:39 imirkin_: airlied: boo :(
20:39 karolherbst: well, that was to be expected, seriously
20:39 RSpliet: airlied: that pdf is the single most structured OpenGL related document I've seen so far... I should print that and put it up the wall here :-)
20:40 Lyude: flowcharts always confuse me
20:40 imirkin_: that chart really only makes sense if you know what all the pieces are already
20:40 karolherbst: I have no frigging clue what that chart tries to tell me
20:40 imirkin_: (and even then, it can be a bit confusing)
20:41 imirkin_: but it's quite good at explaining the *real* order of things
20:41 imirkin_: and precisely where various bits happen
20:43 imirkin_: like "does the polygon depth offset apply before or after clipping"
20:43 glennk: the gles 2.0 chart is a bit less confusing
20:43 airlied: imirkin_: probably unfair to suggest Lyude writes a vulkan driver
20:43 imirkin_: airlied: probably.
20:45 mupuf: I'm afraid that the new machine I added last week end ... just died on me
20:45 Lyude: hehe, I'd love to try sometime though :)
20:45 Lyude: once i understand some rendering stuff
20:45 imirkin_: Lyude: also if you're interested in super-old hw, there's a lot of stuff that could be improved in the nv30 driver (which covers GeForce FX and GeForce 6/7 series hardware)
20:45 mupuf: I was replacing the power supply because it was too noisy
20:45 mupuf: and now ... it does not boot at all
20:45 mupuf: the previous power supply also does not work
20:45 mupuf: damn it!
20:46 airlied: Lyude: it might be interesting to get the GL conformance test suite running on nouveau
20:46 imirkin_: oh yeah - i don't have access to CTS - airlied has done a few runs for me, but it's difficult to act on them since it's one-time runs
20:47 imirkin_: (and at the time, the number of CTS bugs was ... non-zero)
20:47 imirkin_: and also one could look at the dEQP GLES31 conformance tests, which i haven't spent a ton of time on
20:47 airlied:needs to rebase that laptop to mesa master at some point
20:48 imirkin_: airlied: to be clear, i appreciate the runs. just ... without access to the actual tests, it can be difficult to determine what's wrong.
20:49 airlied: imirkin_: yeah I understand, it might be a plan to port some of the more broken things to piglit tests at somep oint
20:49 imirkin_: [even *with* access to the tests, it can be quite difficult]
21:03 karolherbst: airlied: :( user will be disappointed again, cause most already expected my patches in 4.8 :D
21:05 airlied: karolherbst: the trick is to get skeggsb to send his tree in chunks rather than queue up so much stuff :)
21:06 karolherbst: :D
21:06 imirkin_: airlied: perhaps you could let him know?
21:06 karolherbst: I am sure he knows
21:06 imirkin_: :p
21:06 karolherbst: and his boss already knows he has no time for that stuff :D
21:06 karolherbst: so yeah
21:07 imirkin_: the fact that it's a separate tree so doesn't get any testing doesn't help
21:08 airlied: karolherbst: you can always send him pull requests :)
21:08 airlied: then if he fails to pull them I can do it :-P
21:08 imirkin_: well he wants them against his weirdo tree... whereas you'd want it against the linux kernel
21:09 airlied: send them against the kernel and he can fixup his wierdo tree :)
21:09 karolherbst: airlied: thing is, it is already merged in his tree
21:09 karolherbst: airlied: the patches apply just fine with some -p magic
21:10 imirkin_: airlied: would you take a pull from karol with all of his patches?
21:10 karolherbst: :D
21:10 airlied: imirkin_: probably, I'd at least let Ben ack/nack it
21:11 imirkin_: karolherbst: you should put that together. grab airlied's drm-next tree and send a git pull req against that
21:11 airlied: since his bottleneck seems to be getting the patches from his tree to me
21:11 karolherbst: imirkin_: yeah, will take me like 30 minutes?
21:11 airlied: probably won't merge it this window, I'm already seriously late
21:11 karolherbst: then it is pointless anyway
21:11 airlied: but it would be good to get stuff into drm-next in advance of Ben's dequeuing
21:12 karolherbst: it isn't like I pinged already a week ago or so ,....
21:15 skeggsb: airlied: i'll send you a pull req for the already queued stuff once i get to the office, and then another later today if i get the rest of this shit sorted out finally
21:15 skeggsb: on a call currently
21:16 airlied: skeggsb: no worries I've sent to Linus now, once he harrasses me I can't do much :)
21:19 karolherbst: did I actually say 30 minutes?
21:19 karolherbst: airlied: https://github.com/karolherbst/linux/commits/nouveau_reclocking :D
21:19 karolherbst: well
21:19 mupuf: I guess it is too late now
21:19 karolherbst: yeah ...
21:20 karolherbst: I would still prefer to do it through skeggsb
21:20 karolherbst: but we should communicate things faster and _much_ earler
21:20 skeggsb:will make a better effort to send airlied chunks instead of one massive pull
21:20 karolherbst: like if we don't have a linux tree one week before airlieds deadline, we should get it the next day
21:20 karolherbst: stuff like that
21:20 skeggsb:hides in shame
21:21 imirkin_: skeggsb: that's ok, when you have DP-MST actually working, you'll triumph
21:21 karolherbst: how I generated those patches^^: 1. git format-patch 2. find . -iname "0*patch" -exec sed -i "s/\([ab]\)\/drm/\1\/drivers\/gpu\/drm/" {} + 3. git am 0*.patch
21:21 karolherbst: ;)
21:21 karolherbst: for future reference
21:22 imirkin_: (and then you'll realize you're nowhere close to having it _actually_ work out in the wild, but that's for later)
21:22 mupuf: imirkin_: agreed!
21:22 skeggsb: imirkin_: it works, it's just got two more show-stopping bugs to resolve
21:22 imirkin_: skeggsb: i'm sure the intel guys thought it worked too
21:22 skeggsb: heh, true
21:22 pmoreau: mupuf: Too bad for the computer… :-/
21:23 karolherbst: skeggsb: developing features a few days before the merge window closes is usually not a good idea ;)
21:23 skeggsb: but still, i can be better at not blocking other changes on my own
21:23 karolherbst: even if only "small" things are left (tm)
21:23 skeggsb: karolherbst: these have been developing for months now
21:23 mupuf: pmoreau: yeah... curro is coming in a minute, I will see if he can think of a stupid thing I did not think about
21:23 imirkin_: skeggsb: yeah, sending early to drm-next would be fantastic
21:23 mupuf: otherwise... I'm good for buying another mobo
21:24 karolherbst: mupuf: bake it in the oven! :D
21:24 mupuf: I doubt that's it
21:24 pmoreau: mupuf: :-(
21:24 mupuf: I have been putting quite a lot of stress on the mobo because everything is so tightly packed
21:24 mupuf: and getting the oversized PSU out took me an hour
21:25 imirkin_: mupuf: try plug/unplug some stuff?
21:25 mupuf: well, I tried multiple PSU, tried re-sitting the cpu
21:25 imirkin_: no
21:25 imirkin_: pci
21:25 mupuf: oh, I got everything out
21:25 imirkin_: ah =/
21:25 imirkin_: i see this isn't your first time
21:25 mupuf: it is a mini ITX
21:25 karolherbst: skeggsb: sure, but if I know I won't make a change ready in time, I won't even bother to try to still push it in in time.
21:25 mupuf: there isn't much to take out :s
21:26 mupuf: there is still one mini PCIe board... for the wifi
21:26 karolherbst: take out that silly batery?
21:26 mupuf: but it is screwed on the PCB, so I guessed it would not be the cause
21:26 karolherbst: battery
21:26 mupuf: also tried it
21:26 karolherbst: k
21:27 karolherbst: well my atari once didn't boot anymore for real
21:27 mupuf: I will try twisting the mobo
21:27 karolherbst: a year later it worked again
21:27 mupuf: that was what I needed to do with my atari :D
21:27 karolherbst: :D
21:27 mupuf: twist it just the right amount and ... tadam!
21:27 karolherbst: my atari was so heavily modded
21:27 karolherbst: 100MB HDD! damn
21:28 imirkin_:never had an atari :(
21:28 karolherbst: even case modded, so the hdd fit in :D
21:28 Lyude: the other day i had some skl machine that was breaking in rc4, then stopped after I left it in the office for a weekend
21:28 karolherbst: we are talking about hw issues though :p
21:29 Lyude: ah whoops
21:33 mupuf: well, tried again
21:33 mupuf: nothing...
21:33 mupuf: tried taking the ram out and back in again
21:33 mupuf: and tried both of the sticks individually
21:33 karolherbst: mupuf: did you try to boot without ram?
21:33 mupuf: AFAIK, no PC accepts this
21:33 karolherbst: well
21:34 karolherbst: they complain
21:34 imirkin_: mupuf: in what way does the boot fail?
21:34 imirkin_: normally the BIOS emits post codes via beeps
21:34 mupuf: well, maybe I should look for a buzzer because I hear no beeps
21:34 mupuf: the fan just starts spinning
21:34 imirkin_: or, in the case of a particularly fun motherboard, by saying them out in english over the pc speaker (or, with a jumper toggle, in thai or perhaps cantonese)
21:35 mupuf: now, it is much worse... it keeps cycling between power and no power
21:35 mupuf: oh, fun but probably expensive!
21:35 karolherbst: mhh
21:35 karolherbst: that cycle could mean a ram issue though
21:35 karolherbst: had this once
21:35 mupuf: 7 segment displays were expensive?
21:35 mupuf: but I already tried taking both out
21:35 imirkin_: hakzsam: if you don't like my s?0:1 -> !s suggestion, don't take it
21:36 karolherbst: mupuf: try to leave it unplugged from any power suply for 30 minutes
21:36 karolherbst: *supply
21:36 mupuf: karolherbst: I guess, yes
21:36 karolherbst: even remove the battery
21:36 mupuf: yeah, will try that
21:36 mupuf: I tried for 15 minutes already, but with the cmos battery
21:36 karolherbst: I see
21:37 karolherbst: sometimes my laptop firmware is also pretty much screwed up
21:37 karolherbst: desn't boot at all
21:37 hakzsam_: imirkin_, I wasn't complaining about your suggestion :), just about the convention which doesn't really exist in my opinion
21:37 karolherbst: weird power cycles
21:37 karolherbst: I usually try several times and then it starts working again
21:37 hakzsam_: imirkin_, for such minor things, anyway
21:37 imirkin_: hakzsam_: i thought there was, but perhaps there isn't - either way, feel free to ignore
21:38 mupuf: well, now, it does not boot anymore unless I bend one side of the mobo
21:38 mupuf: I guess I clearly broke something ... or ESDed something
21:38 imirkin_: mupuf: i don't suppose you have a screw loose underneat the mobo?
21:39 imirkin_: [which in turn shorts random parts of it]
21:39 mupuf: nope, I moved the entire thing out of the casse
21:39 mupuf: case*
21:39 imirkin_: [not that anything of the sort would have ever happened to me...]
21:39 karolherbst: ...
21:40 karolherbst: once I hit of a resistor from my ATI gpu
21:40 karolherbst: taped it back on and didn't notive any obvious issues
21:40 mupuf: imirkin_: heh
21:40 karolherbst: except that the gpu broke a year later
21:41 mupuf: well, I guess I will just ask my colleagues if they want to give away or sell their older machines
21:41 mupuf: pmoreau got a fermi for 40, I wonder if I can score an entire machine for the same price
21:43 mooch2: hey, what's the earliest linux kernel that has any semblance of an nvidia driver?
21:44 imirkin_: hmmmm... i bet rivafb & co existed in 2.4
21:44 mupuf: mooch2: are you asking when nouveau got merged?
21:44 mupuf: imirkin_: an accelerated fb?
21:44 mupuf: it would have conflicted with the xserver though
21:44 imirkin_: fbdev driver, yes
21:44 mooch2: no, like, any nvidia driver at all
21:45 mooch2: i'm asking because i wish to test this kernel version in 86box's nvidia emulation to see where it stands
21:45 imirkin_: including blob driver?
21:45 mooch2: since later kernel versions are likely to use more features of the hardware
21:45 mooch2: yes
21:45 mooch2: wait no
21:45 mooch2: blob driver will be tested seperately
21:45 imirkin_: i'd recommend using xf86-video-nv
21:46 mooch2: as soon as i figure out how to install it
21:46 imirkin_: it's userspace
21:46 mooch2: ah, true
21:46 imirkin_: works for NV4 and newer
21:46 mooch2: well, i also need something to test nv3 as well
21:46 mooch2: considering that got added to 86box as well
21:47 imirkin_: not sure if rivafb supports nv3 or not
21:47 mooch2: also because mwk has hwtests in envytools for nv3
21:47 mooch2: that might assist me in writing emulation
21:47 mooch2: i know vesa mostly works
21:47 mooch2: though the bios is problematic when used with windows 98
21:47 mooch2: it keeps doing weird shit with the RMA regs
21:48 imirkin_: aha, looks like xf86-video-nv does support nv3
21:48 imirkin_: { 0x12D20018, "RIVA 128" },
21:49 mooch2: yeah, according to nouveau's wiki, it does
21:51 mooch2: i will need lots of luck to get the blob drivers working tho, on linux or windows
21:51 mooch2: they're kinda psychotic in their usage of the hardware tbh, at least on windows
21:51 imirkin_: i dunno that blob drivers ever existed for riva128
21:51 imirkin_: the 96.* series should work on tnt though iirc
21:53 mooch2: whoa, the earliest xf86-video-nv also supported nv1 from the looks of it!
21:53 mooch2: written in 1996-1997, good fucking lord
21:53 mooch2: though nv1 would be a LOT harder to emulate due to it not being fully VGA compatible
21:53 mooch2: i wouldn't be able to rely on the emulator's pre-written svga code
21:58 mupuf: well, I guess I will try to update the kernel of the tk1 and, hopefully, I can start using it for unit tests
22:38 imirkin: skeggsb: btw, your tree has "fifo/nv04: avoid ramht race against cookie insertion" twice and one of the "drm-next" changes reverts it. dunno if that's somehow on purpose, but thought it was odd.
23:34 mupuf: imirkin_, Lyude: how about writing an instruction scheduler to reduce register spilling?
23:35 mupuf: and then increase the number of cycles between a load and use
23:35 imirkin: mupuf: that sounds complicated ;)
23:35 imirkin: and esp given that no one's been able to do it successfully thus far, i dunno if that makes a great first project
23:39 mupuf: hehe, there may be some stupid heuristics that would help on this front
23:39 mupuf: without writing a scheduler
23:40 mupuf: silly things like not loading inside a register a constant when you can use an immediate
23:40 imirkin: huh?
23:40 mupuf: or not storing a constant for longer than necessary
23:40 mupuf:is just speculating
23:41 imirkin: i know you haven't looked much at the GL driver, but the compiler is actually pretty sophisticated
23:41 imirkin: it's not sophisticated compared to, say, gcc, but it's pretty good in general
23:42 mupuf: ok, cool!
23:43 imirkin: nowadays nvir is ~ same opt level as nir, but much faster.
23:44 imirkin: (it used to be much better, but nir has been catching up)