14:43 vries: Hi. I got a question about the "nouveau_compiler". It spits out binary SASS in text form: "401f9c6c 0040000d ...". Is there a known tool that wraps that code in an elf object to generate a cubin, which f.i. would make it possible to disassemble the SASS using nvdisasm?
14:48 imirkin: nvdisasm -b is what i use...
14:48 imirkin: this is what i do:
14:48 imirkin: perl -ane 'foreach (@F) { print pack "I", hex($_); }' > tt; nvdisasm -b SM50 tt
14:48 imirkin: adjust the SM version to taste
14:49 imirkin: if you go with SM50+ you have to make sure to pad out the last block. or just omit it. has to be in 0x40 multiples or nvdisasm falls over.
14:50 imirkin: [the first part of that converts the text hex to a binary file called 'tt', the second runs nvdisasm over that file. i couldn't convince nvdisasm to accept the file on stdin.]
14:50 imirkin: not even with the <() notation since it wants to be able to seek :(
14:51 imirkin: vries: if you're debugging some codegen issue, it can also help to see what nouveau *thinks* it's emitting, which you can do with NV50_PROG_DEBUG=1 nouveau_compiler ...
14:51 vries: imirkin: that's helpful, thanks
14:52 imirkin: vries: are you trying to do something concrete, or just poking around?
14:54 vries: imirkin: atm just poking around, trying to learn more about nouveau.
14:54 imirkin: cool. if you have questions, feel free to ask
14:55 vries: imirkin: thanks.
15:00 imirkin: karolherbst: not sure if you saw, but i have prelim bindless patches for maxwell+ (bindless branch in my tree). if it's easy, would appreciate a piglit run (-t bindless). note that there's a good chance you'll get hangs due to some sort of resource management screwup.
15:01 karolherbst: imirkin: yeah, I saw and forgot again. I can test on my pascal GPU
15:01 imirkin: cool thanks
15:04 karolherbst: imirkin: any plans regarding the nir patches? Currently I have no idea how much I may be able to spend time on such stuff in the future. So if there is anything critical which might should get resolved it would be better to let me know early. Things have gotten a little complicated.
15:05 imirkin: work sucks, right :)
15:05 imirkin: iirc you fixed the major concerns, the leftovers are, well, leftovers
15:05 karolherbst: right
15:05 imirkin: i would like to review, but i don't think there's anything at the design-level holding it up.
15:06 imirkin: i glanced briefly and didn't see anything too crazy
15:06 karolherbst: :)
15:06 karolherbst: well I still want to clean it up a little
15:06 imirkin: the whole "LValues" name may want replacing
15:07 imirkin: and some of the other ones. i get why you did it, but then it gets confusing wrt the nv50_ir:: ones
15:07 karolherbst: right
15:07 imirkin: i dunno, maybe its fine
15:07 imirkin: but all that's just a sed -i away from fixing, i.e. not serious
15:08 karolherbst: right
15:08 imirkin: i haven't reviewed the resource handling stuff, that could be the other tricky bit.
15:08 karolherbst: I will try to find some time to go over all the patches carefullt
15:08 karolherbst: *carefully
15:08 karolherbst: resource as in?
15:08 imirkin: textures, images, ubo's
15:08 karolherbst: I see
15:08 karolherbst: I think I may be too optimistic with the texture stuff
15:08 imirkin: but if you pass the various ARB_gpu_shader5 non-const-indexing tests, you're fine
15:09 karolherbst: the only things I fail in arb_gpu_shader5 is interpolateAt
15:09 karolherbst: related
15:09 imirkin: yeah, i don't care about that
15:09 imirkin: tarceri sent out some related fixes it seems
15:09 karolherbst: I have new fails in: arb_arrays_of_arrays, arb_gpu_shader5, arb_separate_shader_objects, arb_shader_ballot and arb_shader_image_load_store
15:10 imirkin: =/
15:10 karolherbst: those aoa fails hit nir internal asserts though
15:10 imirkin: super.
15:10 karolherbst: I still want to go through those at some point, but in total it is like one page of additional fails
15:11 karolherbst: just some corner cases
15:11 karolherbst: like images with indirect references, which are pain in nir
15:11 imirkin: as long as the general addressing scheme works
15:11 imirkin: i don't care about getting *all* the specifics right
15:12 karolherbst: anyhow. I run some benchmarks doing 64 bit stuff and they ran without problems
15:12 imirkin: i just want to make sure it doesn't become some giant "oh oops, we totally have to redo everything" sort of thing
15:12 karolherbst: so I guess it should be good enough
15:12 karolherbst: yeah...
15:12 karolherbst: but as I said, I still want to go over all the patches again if I find the time for this
15:12 imirkin: (getting the specifics right is a nice little bonus, of course)
15:13 karolherbst: right. I doubt I got something fundamentally wrong
15:13 karolherbst: in the worst case I may be too optimistic about certain things
15:13 imirkin: took me a long time to get it all to work in the current state. most of that is in the lowering passes anyways.
15:13 imirkin: and i have a strong suspicion they took the opportunity to redo TEX yet again in volta.
15:14 imirkin: that op is the bane of my existence
15:14 karolherbst: regarding lowering... I had some 64 bit mul fun....
15:14 karolherbst: guess what
15:14 imirkin: it's broken?
15:14 karolherbst: worse
15:14 imirkin: it works? :)
15:14 imirkin: we rely on earlier stages to get rid of a lot of it
15:15 imirkin: (you're talking about i64 right?)
15:15 karolherbst: well... it was broken and I didn't thought that s32 vs u32 makes much of a difference when lowering that stuff
15:15 imirkin: it matters for IMUL_HI
15:15 karolherbst: right
15:15 karolherbst: took me long enough to actually track this down
15:16 imirkin: but now you know forever.
15:16 karolherbst: hopefully
15:16 imirkin: this is how i learned all this stuff :)
15:16 karolherbst: imul is the only alu op I had to add a silly special case for getting the dType
15:17 imirkin: bfe
15:17 karolherbst: didn't had to for bfe actually
15:17 imirkin: er what, why do you have to get the dType?
15:17 imirkin: for mulhi, stype == dtype
15:18 karolherbst: there is only imul :)
15:18 imirkin: right
15:18 karolherbst: and tgsi only knows umul
15:18 imirkin: it has IMUL_HI
15:18 karolherbst: right
15:18 karolherbst: but it matters when lowering 64 bit ops
15:19 imirkin: as long as you keep types consistent, should all work out
15:19 karolherbst: yeah
15:19 karolherbst: the last 64 bit fails I had were mul related and thinking the type matters was just the last thing I actually checked
15:20 imirkin: i don't think there's a dtype vs stype issue
15:21 imirkin: dtype != stype only matters for like ... cvt
15:21 imirkin: and cmp
15:22 karolherbst: the issue was, that in TGSI there is only a umul and nir has only imul. so for imul I ended up with s64 and the lowering code just didn't care much
15:22 imirkin: :)
16:19 cwabbott: karolherbst: umul and imul are the same thing
16:19 cwabbott: they produce the same bits
16:19 cwabbott: that's why nir only has imul
16:20 cwabbott: (imul_high and umul_high are different though)
17:22 imirkin: cwabbott: any time you want a wider (logical) result for the output than the input
17:22 imirkin: same problem with 16x16 -> 32
17:22 imirkin: [as we have to do on nv50]
17:22 cwabbott: yeah, that's why imul_high and umul_high are different
17:22 imirkin: not to mention the sheer joy of composing 16-bit muls to get a 64-bit result
17:23 cwabbott: sounds fun
17:23 imirkin: [of course the way bugs in that presented was "division by 255 doesn't work")
18:31 Lyude: mupuf: btw: do you think I should try to land the patch series for kepler1 and 2 clockgating first; then work on fermi afterwards?
18:32 mupuf: Lyude: yep, absolutely!
18:32 mupuf: you'll learn from user reports
18:32 Lyude: sweet
18:32 Lyude: \
18:33 mupuf: kepler is also closer to gk20a, which is what we based all our kjnowledge on :s
18:33 mupuf: I mean, desktop kepler :)
18:33 Lyude: mhm; I'll have to go reformat all the blcg registers on kepler so they make use of the fermi registers at some point, but that's not too big of a deal
18:35 mupuf: yeah, that should not be a big patch
18:35 mupuf: or just use the the address for now
18:36 Lyude: mhm; just going to move some of the common stuff into gf100 then I'll start sending this out
19:24 Lyude: btw; I'm pretty sure that even with just idle you still get some pretty crazy power savings with this.seeing a 12W difference just idling on fbcon with blcg
19:25 Lyude: i'm sure there's more power saving under load, but I'm just going to use that for now since it's the easiest thing to measure for the patch series :)
19:28 Lyude: man though, I really wish I understood why a single s/r cycle actually ends up lowering power consumption even more
19:41 mupuf: Lyude: yeah, that is interesting given that a s/r shuld reset the whole context
19:42 mupuf: maybe nouveau's POST is better than the bios'?
19:42 Lyude: that might be it
19:42 mupuf: or enabling less things
19:42 mupuf: (more likely)
19:43 Lyude: mhm
20:32 goose121: hi, I was wondering if there was anything I could do to help debug a hang in nouveau. I've done some dmesg-dumping, and I posted a more detailed overview here: https://www.reddit.com/r/linuxquestions/comments/7iiveh/tips_for_debugging_suspend_with_nvidia_graphics/drxkeb2/
20:34 goose121: the hang doesn't happen with the nvidia driver, instead the driver just refuses to do anything
20:34 imirkin: goose121: looks like your gpu isn't coming up
20:34 imirkin: or more like 'the gr unit in your gpu'
20:34 imirkin: which happens to be the important one
20:35 imirkin: goose121: can you try booting with nouveau.runpm=0 ?
20:35 goose121: sure, just give me a sec
20:35 imirkin: that should prevent the gpu from suspending, and should provide a clue as to what sort of thing is off
20:35 imirkin: it's not a permanent solution if it does help
20:35 goose121: it's a weird thing, because it only happens with system suspend
20:35 goose121: runpm suspending works fine
20:35 imirkin: oh hm
20:36 imirkin: interesting. well the two can overlap, it's worth a shot imo
20:36 goose121: alright, I'll be back in a minute after I try
20:45 goose121: I'm back, this time with a new issue :(
20:46 goose121: I updated my kernel recently, so now nouveau apparently doesn't even want to touch my device
20:46 goose121: I get nouveau: probe of 0000:01:00.0 failed with error -12
20:47 imirkin: it's a GM108 right?
20:47 goose121: yes
20:47 imirkin: pastebin dmesg?
20:48 goose121: https://gist.github.com/goose121/00b1f2db36ea7338bb44ef2bacd5647a
20:53 goose121: the "unknown chipset (ffffffff)" is especially weird because lspci (correctly) says "rev a2", not "rev ff" or anything, and lspci says that the card's associated kernel module is nouveau
20:54 imirkin: that means the gpu's unpowered
20:54 imirkin: or was at the time of the probe
20:55 goose121: alright, I'll try turning it on w/ bbswitch
20:56 imirkin: the other thing is... pcie_port_pm=off
20:57 imirkin: oh and bbswitch + nouveau is likely to end badly
21:17 goose121: alright, I got it to load and stuff; now to see if it crashes again
21:23 goose121: Yep, same symptoms with runpm=0
21:26 goose121: btw, just to be more descriptive, it doesn't really crash right away; it kind of slows to a halt over a couple of seconds, with the mouse cursor moving less and less smoothly, until at some point nothing works, including sysrq
21:36 goose121: I think that a big part of it is probably the atomic update failures, because there were a ton of them which to me seems related to the CPU load that comes with the hang
21:38 karolherbst: imirkin: no, ffffffff doesn't mean the GPU is unpowered
21:38 karolherbst: it means the GPU doesn't answer to a request or the kernel doesn't check for the answer
21:38 karolherbst: that's all
21:46 karolherbst: imirkin: I have the situation where I need to remove and rescan the nvidia GPU so that it doesn't return ffffffff anymore
21:46 karolherbst: and if it is off for real, it fails at pci init aready
21:46 karolherbst: *already
21:59 goose121: is there anything that nouveau should output when suspending/resuming (without debug messages)?
22:09 Lyude: can someone confirm that my clockgating patches got on the mailing list? one of the nvidia addresses from cc_cmd bounced
22:09 Lyude: ...of course it'd be -that- email that bounces
22:14 mauri: Hi
22:15 mauri: Is this nouveau channel ?
22:15 goose121: yes
22:16 mauri: Ok
22:16 mauri: I would report a trouble with Geforce Gs 9600 gt
22:17 mauri: I will explain quickly the situation
22:19 mauri: I will to resolve the Intel Meltdown and spectre bug
22:21 mauri: There is not proprietary Nvidia drivers with last updates
22:22 mauri: Linux chooses the Nouveau drivers but doesn't work
22:22 Lyude: this is the nouveau channel
22:22 mauri: yes
22:22 mauri: I say that Noveau drivers doesn't work
22:23 Lyude: yeah. anyway; if there's a nouveau bug happening we can look at that but you're mostly on your own with the nvidia blob, are you sure that the nvidia blob didn't just blacklist the nouveau modules or disable modesetting on the commandline?
22:23 gnarface: mauri: everyone knows
22:24 mauri: but me no
22:24 mauri: sorry I don't undertand
22:24 gnarface: mauri: steps to reproduce
22:24 imirkin: mauri: saying "it doesn't work" is equivalent to no information at all.
22:25 gnarface: mauri: be specific
22:25 mauri: Which information need ?
22:25 gnarface: steps to reproduce
22:25 gnarface: description of problem
22:25 imirkin: and perhaps a description of the problem :)
22:26 mauri: ok I try to explain it
22:27 mauri: the trouble is that Cpu temperature is constant increase when I use the Open Source driver
22:28 mauri: Do you want to know the os I use ?
22:29 gnarface: tell everything, mauri
22:29 gnarface: what programs you were running
22:29 gnarface: does it also do it at idle
22:29 gnarface: what window manager you use
22:30 mauri: I use Linux Mint 17
22:30 gnarface: kernel version
22:30 mauri: The last kernel version is 3.13.139
22:30 RSpliet: perhaps the best start is to drop your kernel log (dmesg) onto a paste website of choice.
22:30 mauri: The Gui is Mate
22:31 gnarface: 3.13 is pretty old
22:31 mauri: Yes but is supporte unti 2019 :)
22:31 RSpliet: And... oh... yeah, I don't think it's worth for us to try and help if you're not running a 4.14 kernel. We do upstream development here, so are interested in bugs of upstream nouveau. If you are convinced that this is a kernel driver problem, the Mint people are your source of help
22:34 mauri: Yes I would report this bug for all Ubuntu users not only Mint. Should I report only my distro ?
22:39 mauri: I have a question: Where is the compatibility list of gui in Nouveau driver in site Nouveau ?
22:40 imirkin: mauri: it's not supported by anyone here until 2019. if you're looking for support for anything but the latest kernels, you should go to whoever you got those kernels from.
22:41 mauri: But it's receive secure update It's a Lts Kernel...
22:41 imirkin: you can argue all you want, but what i said is the reality.
22:41 RSpliet: mauri: we are not responsible for the kernels that third parties ship.
22:41 mauri: ok
22:41 mauri: i check
22:42 mauri: ok you have right
22:42 mauri: sorry
22:42 imirkin: someone can stick an LTS label on whatever they like (and even continue to support it). doesn't mean people here do.
22:44 mauri: ok thanks for our support
22:44 mauri: I will try to ask Mint team
22:45 imirkin: that said, G9x which is what you have, should work just fine. dunno what your issue is, but you'd have to provide a ton more info, and most importantly, be willing to test latest kernel + patches
22:48 mauri: The last kernel is suitbale for recent Ubuntu distro. I have old it
22:49 mauri: Thanks for all
22:50 mauri: Bye
23:59 pllz: hi, my x session on tty1 crashes when i login and then logout tty2. since i see some nouveau related errors in Xorg log file, can you tell me whether its a nouveau bug thus i can report it somewhere?
23:59 pllz: heres the log: https://paste.debian.net/plainh/d3156d0a