00:00 Simber: I've never done too much in linux before besides killing my vps a few times a year and crying at my laptop when it wont work
00:05 Simber: especially when the wifi refuses to work at uni
00:05 imirkin: yea that's always nice
00:05 Simber: for some reason in linux my laptop refuses to connect to the wifi
00:06 imirkin: yeah... there's a slew of reasons why this can happen
00:07 Simber: Seems to be something to do with network-manager and wpa2 enterprise
00:09 Simber: I never could be bothered to getting it to work so I just conenct to the wifi on my phone usb tether
00:32 imirkin: ah yeah. i avoid network manager, just use wpa_supplicant directly
00:39 Simber: I guess I'll have to try that to get the wi-fi working at uni but I've don't really do much in the console, I tend to stick to GUI
00:40 imirkin: ah yeah. i tend to avoid gui's - much harder to use :)
00:41 imirkin: or rather - much harder to get them to do what you want
00:41 Simber: Unless it's something on my VPS, then I obviously use the console probably much to my server hosts dispise. He gets many tickets from me going "hey I broke something, pls help"
00:42 Simber: I should probably go sleep, thanks for the help
00:42 imirkin: hopefully ben can look at your issue and determine what's up
00:43 Simber: it is a pretty niche case, I doubt to many people are going to run into this kinda issue
00:54 imirkin: looks like it's a 2160x1200 fb
15:32 jamm: imirkin: that forum post was very educational. Thanks!
15:33 jamm: it helped me fill many gaps in my knowledge of GPU hardware - firmware
15:35 imirkin_: i might start a blog.
15:35 imirkin_: haven't had one in decades
15:36 imirkin_: [wow, that makes me feel old.]
15:36 imirkin_: back before they were called blogs
15:38 feaneron: afaik they're still called blogs these days
15:39 imirkin_: right, but they weren't called blogs when i had one :)
15:39 feaneron: no kidding!
15:40 imirkin_: back when LJ was just starting out
15:41 imirkin_: i think the term 'blog' came about somewhere in the early 2000's
15:41 feaneron:hides
15:42 feaneron:is not that old to remember early 2000s
15:42 imirkin_:is old
15:42 imirkin_: https://www.webdesignerdepot.com/2011/03/a-brief-history-of-blogging/
15:46 feaneron: nice read, thanks
18:36 mwynne: Hi guys. Can anyone tell me if it's possible to get a console connection to an nvidia card without any video drivers (assuming I removed nouveau temporarily)?
18:38 imirkin_: rephrase the question please
18:39 imirkin_: "console connection to nvidia card" isn't a thing that makes sense to me
18:40 mwynne: imirkin_: Sorry. I'm not running a window manager or anything. I just require video out to get command line access to the system.
18:41 imirkin_: i believe you'll find this article interesting: https://nouveau.freedesktop.org/wiki/KernelModeSetting/
18:41 mwynne: imirkin_: Thanks. I'll read up.
18:41 imirkin_: esp the bit about "Deactivating KMS and unloading Nouveau", and the "NOTE: For NV50 class hardware and above"
18:47 Lekensteyn: imirkin_: test what stuff out? the "old" method uses _DSM followed by a _PS3 call which could be invoked manually through "acpi_call" (or bbswitch)
18:48 imirkin_: Lekensteyn: when someone comes in with weirdo PM issues, what do i get them to do?
18:48 imirkin_: [given that i currently am not well versed in all the details, and quite frankly, don't think i ever will be.]
18:49 Lekensteyn: depends on "weird", if their machine appears to lock up, then try booting with the acpi_osi="!Windows 2013" (or acpi_osi=! acpi_osi="Windows 2009") option
18:49 imirkin_: weird as in "it doesn't work, but looks like it ought to"
18:49 imirkin_: and esp "it used to, but doesn't anymore"
18:50 Lekensteyn: that specific hang issue is this: https://bugzilla.kernel.org/show_bug.cgi?id=156341
18:50 Lekensteyn: the
18:50 imirkin_: that dude had it working in kernel 4.9, but not in 4.14
18:50 Lekensteyn: pci_pm_port=off could be tried
18:50 imirkin_: pcie_pm_port? or is it pci_pm_port?
18:51 Lekensteyn: pcie_port_pm=off
18:51 Lekensteyn: sorry
18:51 imirkin_: kk
18:51 imirkin_: and then messing about with the acpi_osi
18:51 Lekensteyn: oh another note...
18:53 Lekensteyn: it is possible that with older kernels, PM did not work (no power savings), but with 4.8 PM got enabled, but it triggers lockup issues on some laptops
18:53 Lekensteyn: in that case, disable PM completely with nouveau.runpm=0. This can halve battery life though
18:53 imirkin_: this particular person had the GPU stop auto-suspending when plugged into power
18:54 imirkin_: in 4.9 it suspended, in 4.14 it didn't
18:54 imirkin_: on battery, it auto-suspended fine
19:05 Lekensteyn: another thing to check: autosuspend is only activated when all references to the PCI device (and its parent root port) is idle, check /sys/bus/pci/devices/0000:00:01.0/power/runtime_* (runtime_status should be "suspended" which requires also "runtime_enabled" to be "enabled" instead of "on")
19:13 imirkin_: would you expect those to be different between plugged into battery and not?
19:17 Lyude: Anyone else seen this recently? https://folv.es/t/UXvTdI_ZhgXWEyBf5bSnEg/dmesg a friend of mine is poking me saying that resizing windows in compton with X is causing their GPU to crash
19:18 Lyude: they'e using the nouveau ddx as well, told them to give it a shot with modesetting as well and now I'm just waiting for them to get back to me
19:18 Lyude: (they posted their X log but I didn't see anything remotely interesting in there...)
19:19 imirkin_: dunno, sorry
19:19 imirkin_: either way, the issue is unlikely to be X-related
19:20 imirkin_: i have seen a bunch of firefox flying by
19:20 imirkin_: about resizing windows being broken
19:28 Lyude: firefox breaks a lot of thngs, I have some i965 mesa bugs I've noticed becuse of it that I still need to report…
19:28 Lyude: but i guess that's what you get when you stubbornly enable hw accel on everything
20:34 Manoa: lel console connection to nvidia card :)
20:47 Lyude: man when you start working with a different kernel gpu driver you really start to miss how coarse nouveau's debugging levels are
20:48 Lyude: soooooooo much noise with the rest of the DRM drivers :(
20:49 RSpliet: Lyude: then don't do that, just stick with Nouveau ;-)
20:50 Lyude: hehe
20:50 Lyude: unfortunately nouveau doesn't drive my displays at work :(
20:51 RSpliet: Sounds like a fun project to fix :-P
20:51 Lyude: Spent most of my last work week coming up with patches to make i915 do mst link retraining correctly so maybe someday my whole dock will actually work :P
20:53 Manoa: you know, something about i915 that I recently found surprising
20:53 Manoa: someone played doom 3 on radeon 3000 series card and another guy connected, I asked him too what card he was on, he said the built in intel
20:53 Manoa: you will not blieve this but, the radeon 3000 guy had 6 fps and the intel guy had 30-40
20:53 Lyude: i can
20:54 Lyude: intel-gfx isn't the worst tbh
20:54 Lyude: Especially kbl an up
20:54 Lyude: *skl and up
20:55 Manoa: they made big improvements in skylake yhe ?
20:56 Manoa: I suppose AMD's equal inbuilt card would be just as good
20:56 Lyude: well they've been progressively getting better with performance and skl was a pretty big jump
20:56 Lyude: nah
20:56 Lyude: amd still wins iirc
20:56 Lyude: but mostly with the newer stuff
20:57 imirkin_: haswell was the big bump in perf
20:57 imirkin_: also they made "larger" versions of their graphics cores for some high-end laptops
20:57 imirkin_: (GT4e stuff)
20:57 imirkin_: which are comparable to a low-end dGPU it hink
21:17 mwynne: imirkin_: If my understanding is correct, I need to replace nouveaufb with another framebuffer, since I have NV50 class hardware. Is that correct?
21:30 imirkin_: mwynne: i don't know what hw you have. but if you have nv50+, then there's no way to get a vga console back.
21:31 imirkin_: nouveau kicks out the firmware that implements the vga/vesa/efi services, and there's no way to get it back
21:32 mwynne: imirkin_: I have an NVIDIA GT218
21:32 imirkin_: yeah, that's nv50.
21:32 mwynne: Yeah.
21:32 imirkin_: (well, nv50+)
21:37 imirkin_: you can mess around with vbeinit, but only when nouveau's not loaded
21:37 imirkin_: that might re-run the card init which would get those services back
21:37 imirkin_: and then you'd have to reattach the vga console to them
21:38 imirkin_: but i've never done that
21:41 mwynne: hmm
22:16 pmoreau: Is there an architecture which uses 64-bit addressing for shared memory? I doubt we will see anytime soon >4GB shared memory/L1 caches.
22:18 pmoreau: I just realised that, as envytools was not printing a ‘d’ after the register, for the address in shared loads and stores.
22:21 imirkin_: pmoreau: the address in loads/stores varies based on ST vs ST.E
22:21 imirkin_: i.e. you can use a 32-bit address with a gmem load too (at least on fermi)
22:22 pmoreau: I’m only talking about shared, I’m aware of 32-bit/64-bit for gmem
22:22 imirkin_: yea ... i don't think there's a 64-bit encoding for that. not sure.
22:23 pmoreau: Given that the most share memory per SM you can have is about 96kB, I doubt they made it 64-bit.
22:26 pmoreau: But I was surprised to see `st b32 $r2 ld s[$r6]` when passing the generated binary through nvdisasm/envydis, whereas I know $r6 is actually a 64-bit value (and is printed as such when printing the program).
22:27 pmoreau: I haven’t looked at the TGSI frontend to check if it assumes 64-bit pointers for everything as well, or not. I could add a pass to truncate it back to 32-bit for shared mem pointers, as that could get rid of the instructions for computing the unused high bits.
22:33 imirkin_: $r6 is a 64-bit value?
22:33 imirkin_: what do you mean by that?
22:33 imirkin_: iirc shared mem is just a 32-bit value.
22:34 imirkin_: either way, the nvir can say whatever you want, only certain things can be encoded :)
22:35 pmoreau: Right, but during the whole “compilation phase” the smem pointer is assumed to be 64-bit, and only during the emission is it ”truncated” to 32-bit.
22:38 pmoreau: For example: https://hastebin.com/iwazadihej.pl
22:39 imirkin_: "assumed to be"?
22:39 imirkin_: you mean you make it so?
22:40 pmoreau: Yes, I make it so
22:48 pmoreau: I’ll need to change that in my code.
22:52 imirkin_: i think we just do 32-bit values in the tgsi fe
22:58 pmoreau: I had a look at it, and it seems to do 32-bit, but the code is commented out (the part creating smem symbols), as you can’t access it directly through GLSL, and maybe not even in graphics context, as we were discussing some times earlier.
23:04 toad_: What's my best option for a version of nouveau supporting recent graphics cards on debian?
23:05 imirkin_: define 'recent graphics cards'
23:05 toad_: The kernel recognises the card, but the Xorg driver does not ... unfortunately recent means NV130
23:06 imirkin_: latest released xf86-video-nouveau should support pascal just fine
23:06 toad_: Although I might be willing to downgrade to NVE0
23:06 toad_: Hmmm
23:06 imirkin_: that'd be 1.0.15
23:06 imirkin_: released in april 2017
23:06 toad_: Ah thanks, I wasn't able to find any version numbers...
23:07 imirkin_: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau
23:07 toad_: Stretch has 1.0.13, which only supports up to NVC0
23:07 toad_: I.e. four generations prior
23:07 imirkin_: you're going to get way better support for kepler though
23:07 imirkin_: 1.0.13 should support kepler just fine.
23:07 imirkin_: in fact 1.0.0 supported kepler.
23:08 toad_: Nouveau driver built september 2016 ...
23:08 toad_: Yeah but really I'd like support for Pascal
23:09 imirkin_: dunno what your end goal is
23:09 imirkin_: but with kepler, you get reclocking, which means that you can get within an order of magnitude of the perf you should get with that board
23:09 toad_: According to the logs, the debian version (supposedly 1.0.13???) only supports up to GTX 400 / NVC0 / Fermi
23:09 imirkin_: with pascal you get super-low-clocks and various bugs in the 3d driver
23:10 imirkin_: yeah, that's just a fixed string that's printed
23:10 toad_: Hmmm ok so what you're saying is it's impossible to do gaming on linux? :(
23:10 imirkin_: on pascal with nouveau? i guess it depends on the game
23:10 toad_: Well it also says unknown chipset NV134 :(
23:10 imirkin_: if the game is tuxracer, then you should be fine.
23:10 toad_: And Wine doesn't work well with AMD, as a rule
23:11 toad_: (Sorry)
23:11 imirkin_: well, if it works poorly with amd, it'll work poorly with nouveau
23:11 imirkin_: since it's the same GL backend
23:11 imirkin_: i think what you're saying is that wine works well with nvidia blob driver and nothing else
23:11 toad_: Nah, there were other issues ... but off topic
23:11 imirkin_: which i can totally understand, but no amount of using nouveau will fix that :)
23:12 toad_: Well it sounds like an old GTX Titan would work reasonably well with nouveau?
23:12 pmoreau: Depends which one: the original one, yes, but the Maxwell based one, no
23:12 toad_: Kepler is the last card we have any chance of having performance close to the proprietary level on?
23:12 imirkin_: in a moment of frustration with idiots posting idiotic things, i wrote up a length post about some of the current issues faced by nouveau with newer chips: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998427#post998427
23:13 imirkin_: depends on what you mean by 'close', but you should get about 60-80% of blob perf if you reclock manually to the highest perf level
23:21 BootI386: imirkin: Why not 110% ? :)
23:33 imirkin_: why not 110%? because i suck, i guess.
23:34 imirkin_: and apparently can't outperform the entirety of nvidia's driver team
23:36 imirkin_: [and also perf isn't something i've really focused much on, all my gpu's are total crap.]
23:36 imirkin_: actually i guess the Quadro FX 3450 was decent in its day
23:37 imirkin_: and maybe the FX 3700 was too
23:40 pmoreau: imirkin_: I am hitting an assert within RA: “nouveau_compiler: ../../../../../mesa_spirv/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp:1367: void nv50_ir::GCRA::checkInterference(const nv50_ir::GCRA::RIG_Node*, nv50_ir::Graph::EdgeIterator&): Assertion `vB->compound' failed.” (whole output: https://hastebin.com/ihonogaqus.pl)
23:40 imirkin_: you're in serious trouble.
23:41 imirkin_: whatever you did ... undo :)
23:41 pmoreau: :-D
23:41 imirkin_: 30: st u32 # s[%r21d+0x0] %r26 (0)
23:41 pmoreau: I just moved a mov from one BB to its parent, in order to get a phi node on it.
23:42 imirkin_: should be a 32-bit indirect no?
23:43 pmoreau: Yeah, but it will be emitted as `s u32 # s[$r21+0x0] $r26`, so we will only miss on removing dead code.
23:43 pmoreau: *st
23:44 imirkin_: heh
23:44 imirkin_: i just mean like ...
23:44 imirkin_: you're asking for trouble.
23:44 pmoreau: I can try to force it to 32-bit
23:44 imirkin_: don't ask for trouble :p
23:44 imirkin_: i'm sure that's not it
23:44 imirkin_: but it's not helping.
23:44 pmoreau: Sure
23:45 imirkin_: er what??
23:45 imirkin_: 50: shl u32 %r205 %r203 0x00000002 (0)
23:45 imirkin_: 51: shr u32 %r206 %r203 0x0000001e (0)
23:45 imirkin_: 52: shl u32 %r207 %r204 0x00000002 (0)
23:45 imirkin_: 53: or u32 %r208 %r207 %r206 (0)
23:45 imirkin_: 54: merge u64 %r131d %r205 %r208 (0)
23:45 imirkin_: 55: ld u32 %r132 s[%r131d+0x0] (0)
23:45 imirkin_: care to explain what this is trying to do?
23:45 pmoreau: But the code, similarly to SPIR-V, assume all pointers are 64-bit, so I might have to go through all the code to fix that for smem pointers.
23:46 pmoreau: 50: shl u32 %r205 %r203 0x00000002 (0)
23:46 pmoreau: 51: shr u32 %r206 %r203 0x0000001e (0)
23:46 pmoreau: 52: shl u32 %r207 %r204 0x00000002 (0)
23:46 pmoreau: 53: or u32 %r208 %r207 %r206 (0)
23:46 pmoreau: That’s the split of shl u64 %r207d %r205d 0x0000000000000002
23:47 imirkin_: why are you splitting it?
23:47 pmoreau: (and with the merge included)
23:47 imirkin_: it should just get emitted
23:47 pmoreau: That’s your handleShift code from NVC0LegalizeSSA :-p
23:47 imirkin_: oh. kepler1.
23:47 imirkin_: right.
23:48 pmoreau: Yes
23:48 pmoreau: It always takes me a bit that that code is doing what it should, even if it looks really weird initialy.
23:50 imirkin_: ok
23:50 imirkin_: so
23:50 imirkin_: here's the thing
23:50 imirkin_: i've never ever ever ever ever. ever. EVER. seen 64-bit phi nodes.
23:50 imirkin_: now, in PRINCIPLE it should all work
23:50 imirkin_: however. i've never ever ever ever ever seen it
23:50 imirkin_: coz tgsi doesn't generate it
23:52 pmoreau: Let me try to drop it to 32-bit values, for the smem pointers at least.
23:54 imirkin_: well, i'm mostly concerned about the phi values
23:54 imirkin_: esp i dunno how it interacts with the compounding logic
23:54 imirkin_: which iirc is fragile at best
23:55 imirkin_: that said ... it OUGHT to work
23:55 imirkin_: if you can gdb into the assert
23:56 imirkin_: and do a bt + i locals, p *node, p *intf, p *vA, p *vB, p *vD, p *vd
23:57 imirkin_: (in the checkInterference frame)
23:58 pmoreau: Sure
23:58 imirkin_: that assert is saying that there's something pretty fishy going on
23:58 imirkin_: it saying that 2 values got joined together, and one is a compound and the other isn't
23:58 imirkin_: which would imply some sort of rig node madness
23:59 imirkin_: compounds happen with merges and splits...