04:46amonk: can nouveau work with opencl?
04:46amonk: oh, bummer. that was a quick nope. why not? any idea?
04:47amonk: well, if you don't have a clue as to why not, i have to doubt your assertion. sorry.
04:51amonk: and i just found this... https://linux.slashdot.org/story/12/02/07/1645255/nouveau-open-source-nvidia-driver-achieves-opencl-support
04:51amonk: and this... https://www.phoronix.com/scan.php?page=news_item&px=MTA1Mzk
04:51skeggsb: amonk: doubt all you like, it doesn't change the facts
04:51amonk: from ~2012 without too much difficulty, so...
04:51skeggsb: source: nouveau kernel maintainer (me)
04:51amonk: skeggsb: look up. that fact is dubious at best.
04:52amonk: skeggsb: okay. so why the discrepancy?
04:52airlied: there are plans, none of them have achieved opencl
04:52skeggsb: there's missing pieces on the compiler side, no way to get from what LLVM produces, to what the driver can consume
04:52amonk: okay. so why do those posts contradict what you all are saying?
04:53skeggsb: do you believe everything you read in the news?
04:53amonk: yeah, about as much as everything i read on ird, at least. lol
04:53amonk: skeggsb: what about gcc?
04:59amonk: well, apparently Francisco Jerez demoed it working at FOSDEM 2012. so, there is at least legitimate discrepancy, so forgive me if i don't just believe everything i read on irc in the first second (especially when it contradicts known history/facts).
05:00skeggsb: i don't recall exactly what was demoed, but i doubt it was CL, unless it was hacked up to show compute working
05:00skeggsb: we support compute, but only via GL compute shaders
05:01amonk: well, you can read, right. it's right there.... https://www.phoronix.com/scan.php?page=news_item&px=MTA1Mzk
05:01skeggsb: no amount of arguing is going to change it dude, try it for yourself and find out
05:01airlied: it was hacked up OpenCL
05:02airlied: amonk: the person talking to you is the project maintainer
05:02airlied: he might understand the current state of the project better than article from a dubious news source 5 years ago
05:02amonk: well, i am sure what you all are saying is not totally wrong. clearly the truth/fact lies in the middle somewhere. i am just trying to get to it. sorry
05:02airlied: amonk: https://www.x.org/wiki/Events/XDC2017/Program/
05:03airlied: there are some recent links to talks
05:09amonk: airlied: thanks, but that's really one link, and talk singular, but really just the slides. better than nothing, but not so conclusive. the most salient detail in my cursory look was "so much fragmentation". yeah. :9
05:10amonk: i have it working with the free amdgpu driver (after much effort). was hoping there might be a similar path with nouveau. looks more grim i guess. bummer. :(
05:15amonk: i only "argue" when there are contradictions. seems reasonable. and everything is hacked up (lol). anyway, thanks for the help. l8r
10:58NanoSector: okay my laptop locked up right after typing a message here, did it get sent correctly?
10:58NanoSector: seems any interaction with my dedicated GPU now locks up my laptop eventually
10:58NanoSector: (i opened gnome-control-center and went to the details pane)
11:42karolherbst: NanoSector: are you sure you only reclock while the GPU is turned on?
12:01rhyskidd: any reviewers on these final Pascal SLCG regs for rnndb? Should be fairly straightforward. https://github.com/envytools/envytools/pull/103
12:02karolherbst: rhyskidd: well it looks fine... but I have no clue if the names are correct
12:03rhyskidd: I've matched them from the nvgpu blocks, similar to Lyude's approach, and then used demmio to confirm that matches what the blob is doing
12:03karolherbst: ahh, I see
12:03rhyskidd: contextually, I'm confident they are all SLCG based
12:03karolherbst: would be nice to reference the code in the cmmit message
12:04rhyskidd: ok, fair point. will add that to the commit message
12:05NanoSector: karolherbst, i wasn't reclocking it at all
12:05NanoSector: just opening gnome-control-center to the details pane is enough to hang my system
12:05karolherbst: NanoSector: bad luck then? dunno. Maybe suspending/resuming is killing your GPU
12:05karolherbst: NanoSector: did you try to boot with nouveau.runpm=0
12:05NanoSector: idk, it's odd because it worked fine before
12:05karolherbst: well, sometimes we mess up
12:06karolherbst: and if it worked before and doesn't know
12:06NanoSector: but even if i boot back to kernel 4.12 it's broken, and i'm pretty sure it worked on that
12:06karolherbst: a git bisect would be really cool
12:06karolherbst: I don't like those issues
12:06NanoSector: now i'm scare
12:06karolherbst: NanoSector: did you try 4.12.0?
12:06karolherbst: .0 is the important bit here
12:06karolherbst: sometimes fixes get cherry-picked
12:06karolherbst: it happened to me once, and stuff broke in a patch release
12:06karolherbst: super annoying to track down
12:07NanoSector: i think i started with 4.12.4
12:07NanoSector: but i'll see if i can find a 4.12.0 package
12:11NanoSector: i think they all got erased from the updates server, is 4.11.8 okay?
12:15NanoSector: ah, got it
12:18NanoSector: karolherbst, so do i try kernel 4.12.0 with or without the runpm=0 part?
12:19karolherbst: both please
12:20NanoSector: be right back, then
12:26NanoSector: karolherbst, kernel 4.12.0 without nouveau.runpm=0 also hangs, with runpm=0 it's fine. same goes for kernel 4.13.6
12:27NanoSector: without runpm=0 'DRI_PRIME=1 glxgears' is a black screen and hangs, with runpm=0 it works
12:28NanoSector: without runpm=0 the Dolphin emulator hangs like i described yesterday, with runpm=0 it works
12:35karolherbst: same with the newest kernel?
12:36NanoSector: the newest available is 4.13.6, i can try to find 4.14 RPMs
12:37karolherbst: well if runpm=0 works on 4.13.6 then it's fine
12:37karolherbst: seems like you just have a runpm issue for whatever reason
12:37NanoSector: hmm okay, it's odd that it worked before though
12:37karolherbst: maybe it works with 4.11 or 4.10?
12:37NanoSector: i could try
12:37karolherbst: maybe a firmware update messed something up if you did something
12:37karolherbst: *did one
12:37NanoSector: no, ASUS didn't release any BIOS updates
12:37NanoSector: (this is a Zenbook UX510UX)
12:37karolherbst: maybe you are remembering wrongly or something, can also happen, and happens to me from time to time as well
12:38karolherbst: no clue
12:38NanoSector: no i'm 100% certain it worked before, I played hours of Half life 2
12:38NanoSector: using the nvidia card
12:38NanoSector: but could be 4.11
12:40NanoSector: note to self https://koji.fedoraproject.org/koji/buildinfo?buildID=885151
12:46NanoSector: karolherbst_, kernel 4.11.0 is fine
12:46NanoSector: well, nouveau isn't entirely happy, but no hangs
12:46NanoSector: [ 54.035540] nouveau 0000:01:00.0: priv: HUB0: 6013d4 00005700 (1f408200)
12:46NanoSector: [ 54.078112] nouveau 0000:01:00.0: priv: HUB0: 10ecc0 ffffffff (1e40822c)
12:47NanoSector: also thanks dnf for uninstalling kernel 4.13
12:47karolherbst_: okay, so it's a regression inside 4.12
12:47NanoSector: anything i could test?
13:08karolherbst_: NanoSector: you could do a git bisect
13:10NanoSector: i might try that later this week or next week
13:28imirkin: lol @ guy arguing about opencl above. funny thing to wake up to.
13:50NanoSector: ah okay
13:54NanoSector: LOL https://i.imgur.com/1gY4yj5.png
14:34NanoSector: so, 7 bisections to do according to git
14:35karolherbst: wow nice, when I do a full kernel bisect I get like 13
14:35karolherbst: NanoSector: but, the issue is, it might be not directly caused by Nouveau code
14:36NanoSector: i filtered on /drivers/gpu/drm/nouveau
14:36karolherbst: could be some pci runpm stuff
14:36karolherbst: try to only filter /drivers
14:36NanoSector: it gave me 14 bisections without the filter
14:36karolherbst: might take you ~3 steps more
14:36NanoSector: well it's compiling now :x
14:36karolherbst: you can start again a full bistect with the last bad/good pairs afterwards
14:37karolherbst: or do a check if the HEAD^ of the first bad commit also causes the regression
14:37karolherbst: just saying that it might be the case
14:37karolherbst: maybe it isn't
14:38NanoSector: "Bisecting: 12146 revisions left to test after this (roughly 14 steps)"
14:38karolherbst: meh :(
14:38NanoSector: i have ccache and stuff anyway so builds should be speedy
14:38karolherbst: I don't trust ccache though, it broke builds for me in the past
14:38NanoSector: oh :\
14:38karolherbst: well, it's md5 hashing afaik
14:38karolherbst: what do you expect
14:39NanoSector: i never had issues with it using Arch though, but we'll see how it fares
14:40NanoSector: if anything my system won't boot, big deal, i'll get rid of it if that happens
15:55NanoSector: this is going to be a long night
15:55NanoSector: compiling my second bisect right now :x
15:57karolherbst: NanoSector: it is getting faster over time
15:57NanoSector: ah good
15:57NanoSector: because you're getting narrower so less changes?
15:57karolherbst: the last ~5 steps taking as long as the first or something
15:57karolherbst: NanoSector: yeah
15:57karolherbst: less files touched: less recompiles
15:57NanoSector: yeah, it's recompiling most things now
15:57NanoSector: gives me plenty of time to study though :D
15:57karolherbst: sometimes you jump around a global header change, which is slightly annouying
15:58NanoSector: i should set up modprobed-db anyway
15:59NanoSector: only compile the stuff i really need
15:59karolherbst: fun if you get into bisecting RC releases
16:29NanoSector: yay, time to test build #2
16:32NanoSector: hmm, it started somewhere in 4.11
16:41NanoSector: yeah they are getting much quicker
17:31NanoSector: hmm i have the feeling it is still recompiling everything on every run
17:33karolherbst: NanoSector: how many steps are still to go ?
17:33NanoSector: i'm currently doing the 4th
17:33NanoSector: out of 14
17:33NanoSector: 1400 or so revisions to go, git said
17:33karolherbst: ohh, you won't see much of a differente for the first ones sadly
17:33NanoSector: well this build works
17:34NanoSector: my previous one didn't
17:34karolherbst: at last
17:34NanoSector: so we're getting somewhere
17:34NanoSector: it's funny, the builds which work have these two lines:
17:34NanoSector: [ 21.092348] nouveau 0000:01:00.0: priv: HUB0: 6013d4 0000573f (1f408200)
17:34NanoSector: [ 21.127462] nouveau 0000:01:00.0: priv: HUB0: 10ecc0 ffffffff (1940822c)
17:34NanoSector: the ones that don't work don't have them
17:35karolherbst: it might be that somebody bistected that already..., but I can't remember right
17:35NanoSector: we'll see, can't hurt to confirm it once more
17:35karolherbst: sadly git bisect can't be easily automated on the kernel
17:36NanoSector: yeah, especially not with the reboots and everythng
17:36NanoSector: no biggie though, i shoved it in a single command and my terminal pings me when it's done
17:37karolherbst: ahh, nice
18:25NanoSector: build #4 is good, 825 revisions to go
18:25NanoSector: 4.11 rc6 now, but i already told it 4.11 stable is good
18:36Llmiseyhaa: Y'know, I'm beginning to wonder if my GT730 is bum.
18:37Llmiseyhaa: The official nvidia drivers lock up basically within minutes of me getting back to my computer after leaving it idle for a while -- which makes me suspect power management at some level. The nouveau driver runs into problems as well, as discussed in here. Though those could be nouveau bugs, but... ugh.
18:55gnarface: Llmiseyhaa: how about temperatures? i've had a LOT of nvidia cards go bad over the years (almost always turns out to be partial RAM failure) but i've also had at least one that i can confirm i saved before permanent damage by cleaning and re-seating the heatsyncs with high quality brand-name thermal paste (instead of that crummy black rubber stuff that turns into an insulator after 6 months of re-heating)
18:56Llmiseyhaa: The temperature sensor on it has never reported high temperatures.
18:56Llmiseyhaa: Like, I don't think I've even seen 60C
18:56Llmiseyhaa: Always below; especially after the computer's been idle and I get back to it.
18:57gnarface: Llmiseyhaa: well, if you also see weird artifacts during POST like scrambled character glyphs and such, that's pretty much a guarantee of partial ram failure. 60C sounds a bit high for idle though.
18:57Llmiseyhaa: With nouveau, I can reproduce the bug regardless of anything else by... loading maps site. Doesn't greatly matter which one, but the way they do their canvas in the browser seems to do it.
18:57Llmiseyhaa: I'm not at home now and don't have my influxdb logs (yup, I'm logging the sensor data on my desktop) to verify the range; but my wife's card has that... ooof.
18:58gnarface: hmmm. well, loading something up that fills video ram would be one reliable way to trigger a ram-failure-related bug
18:58Llmiseyhaa: True. I've never had artifacts on boot or such though myself, and the error wasn't so much a RAM error as a... I think someone in here indicated it was a data type mismatch. I'd have to dig up the gist and such; and again I'm not at home, so my apologies.
18:58gnarface: in theory it should be possible to run stuff like memtest86 and badblocks on ram, but i've still not seen any working tools in the wild for *video ram*
19:04Llmiseyhaa: And idle is significantly lower than 60C, I more meant that I've never seen it above that at any time. I apologize if I wasn't clear.
19:04imirkin_: could be bad vram too
19:04imirkin_: what issues are you seeing?
19:13Llmiseyhaa: On my own card; under nouveau I'm getting that error (I think you said it was the alpha channel) getting an unexpected floating point 1.0 that locks the card up. Under nVidia drivers I'm getting unexplained hard locks (can't even network in) just after returning from idle -- like if I leave the computer on while I'm at work.
19:14Llmiseyhaa: I don't get the lockup coming out of idle under nouveau drivers, I don't get the maps issue seizing the card up under nVidia.
19:16gnarface: i think i was the one who suggested alpha channel data sneaking in, but i was just guessing, i had no idea what was going on.
19:16imirkin_: oh yeah, the weird desync
19:17imirkin_: where you're getting a 1.0 on the msaa mask
19:17imirkin_: which either means we're messing up the fifo context switch
19:17imirkin_: or the hw is messing things up
19:17imirkin_: or we have a horrid bug
19:17imirkin_: [which could happen due to multithreading in the GL app]
19:18Llmiseyhaa: Always been a browser; Chrome or Firefox both do it -- for reference.
19:19imirkin_: yeah who knows. those are complex applications.
19:20Llmiseyhaa: There are days I'd rather go back to wrenching on my '88 Supra Turbo than keep debugging computers. (=
19:20Llmiseyhaa: (Said with a smile because I am most certainly not upset at you guys.)
19:21Llmiseyhaa: And that '88 Supra Turbo is a notably weird one as I think it's their _only_ '88 that doesn't have a diagnostic serial output so it's all old school tuning/oscilloscope/multimeter debugging
19:23NanoSector: down to 439 revisions, and another build of 4.12
19:23NanoSector: karolherbst, this 4.11 build does not have those two lines and it works fine
19:23NanoSector: so i don't think it's linked
19:36karolherbst: NanoSector: well it should get faster by now, thanks for checking it
19:38NanoSector: yeah i still think it's recompiling everything
20:10NanoSector: on a completely unrelated note, does anyone know a good place to ask about light sensor support in linux?
20:11imirkin_: check MAINTAINERS to see if they have a list?
20:48NanoSector: imirkin_, unfortunately they do not, thanks anyway
20:54pmoreau: karolherbst: Thanks for the ack and Rb! :-) If the program does not use shared memory, then it is “wasted” as it is not used. However, in Volta, they did merge L1 and shared.
20:59karolherbst: pmoreau: ahh,I see
21:00karolherbst: pmoreau: but yeah, having that shared memory program wide makes actually sense, no clue why I was thinking about thread wide...
21:01pmoreau: Program-wide as in nv50::Program, or SPIR-V module?
21:01karolherbst: well I meant the entire think executing
21:02pmoreau: Cause one nv50::Program could contain multiple kernels, in which case having shared memory for the whole program does not make sense.
21:02pmoreau: Ok, then for the whole kernel/compute shader invocation.
21:30mooch: mwk, any idea how debian 6's vesa draws text? i can't figure out how to make it render on my nvidia emulation
21:31mooch: no commands are sent to the card so
21:31imirkin_: it uses vesa vbe calls?
21:31imirkin_: [i'm not mwk, but i suspect he'd agree]
21:31mooch: except all those are supposed to do is write to the LFB
21:31mooch: which it's not doing, evidently
21:31imirkin_: LFB = ?
21:32mooch: linear framebuffer
21:32imirkin_: not at all.
21:32gnarface: afaik nvidia binary drivers don't use the framebuffer in text mode
21:32imirkin_: vesa calls do all kinds of crazy shit
21:32gnarface: old dos text mode stuff
21:32mooch: imirkin, weird, because no commands are being sent to the card right now
21:33imirkin_: basically they are implemented by the vbios software
21:33mooch: yeah which i run
21:33imirkin_: i always get confused actually
21:33gnarface: they might be sent to the BIOS directly instead though?
21:33imirkin_: between how vga works and how vesa works
21:33mooch: gnarface, again, i run the BIOS
21:33gnarface: the motherboard bios actually, i thought?
21:33gnarface: oh hmm
21:33mooch: i run every bios
21:33gnarface: and no commands going to them either?
21:33imirkin_: vga is int 10h
21:33imirkin_: is vesa also handled by int 10h?
21:34imirkin_: as i recall you do have to pass it a fb
21:34imirkin_: which you then manage yourself.
21:34gnarface:has no idea
21:34imirkin_: gnarface: that was already apparent :p
21:34mooch: this card doesn't have an accelerator call option in the bios
21:34mooch: all it has is VBE
21:34mooch: no really, i tried to use it
21:34imirkin_: but VBE are the extensions...
21:35imirkin_: "VBE is made available through the video card's BIOS, which installs during boot up some interrupt vectors that point to itself."
21:36mooch: gnarface, you don't understand, i don't simulate the BIOS, i run the BIOS directly
21:36mooch: which means you need the original card's BIOS to run this emulator
21:36mooch: okay, i just found out this is an svga bug
21:37mooch: it happens on the s3 virge/dx with vbe 2.0 too
21:39airlied: vesa x driver just maps some lfb
21:40airlied: it only uses vbe for setting modes
21:40mjg59: mooch: When you say "Debian 6's vesa", do you mean the DDX or vesafb?
21:40mooch: i'm not sure
21:40mjg59: Is this on the console or in X?
21:40mooch: i think it's just the vesa x driver
21:41mjg59: Ok then yeah what airlie said
21:41mjg59: The only vesa calls made are for initial modeset and for DPMS
21:41mooch: then i know why the text isn't rendering
21:41mooch: basic svga emulation bugs
22:20mooch: mwk: how does the free pfifo method work?
22:22mooch: on NV3 that is
22:25NanoSector: i am an idiot, i kept copying over the .config file from my current kernel and that kept triggering make to recompile all modules... :\