00:01 imirkin: karolherbst: i need to check.
00:01 imirkin: this is all connected ... stuff like MAX_OUTPUTS, etc
00:01 imirkin: gpuinfo.org should show what blob reports
00:02 karolherbst: 128
00:02 karolherbst: https://opengl.gpuinfo.org/displayreport.php?id=317
00:03 karolherbst: vertex output is 64 though...
00:03 imirkin: that sounds right
00:03 karolherbst: gs can output 128 though, so that all fits
00:03 imirkin: right
00:05 karolherbst: anyway.. will try to go to bed early today :) and over the weekend I may even add the two ubos to maxwell+, should be fun :)
00:41 lovesegfault: Lyude: Hum, all those modules seem to already be loaded
00:41 lovesegfault: I loaded typedc_nvidia manually
00:41 lovesegfault: let's see what happens on hotplug
00:42 lovesegfault: Yeah, no difference; needed lspci to make things go
01:00 imirkin: skeggsb: hm, why does devinit/fbmem.h use ioread/write32 instead of the _native variants?
01:04 jbryn: Glad to be contributing....
01:04 imirkin: well, it's been that way for a while. looking at kernel versions, that *did* work on the nv34
01:04 imirkin: which i had in my ppc
01:05 imirkin: that file's been there since the 4.3 conversion, and i definitely remember debugging some unrelated issues in that on the ppc
13:02 wifire1: hi people!
13:03 wifire1: I had before GTX 660 (gk106) and it worked with NvGrUseFW=1 only. Now I have GTX 650 (gk107) and it fails to load firmware, because it doesn't exist... Direct firmware load for nvidia/gk107/fecs_inst.bin failed with error -2, same from nouveau/ folder, no any firmware exist for gk107
13:03 wifire1: please help me finding firmware for gk107 for gentoo
13:39 RSpliet: wifire: we don't do distribution support here. You're going to have to ask the people over at Gentoo where they hide their firmware binaries
13:39 RSpliet: that being said
13:40 RSpliet: Nouveau has firmwares as part of the kernel driver. Built in... they're in-lined in header files. They work on most graphics cards just fine. Did you try booting the GTX650 without NvGrUseFW?
13:41 wifire1: gtx 650 without grusefw, same as gtx660 gk106 works unstable, X crashes, and screen artifacts appears
13:41 wifire1: no firmware in gentoo and ubuntu too for this card. only gk106, no gk107...
13:43 RSpliet: wifire: which kernel is that?
13:44 wifire1: 4.9.135. I can't use newer. but linux-firmware is separate package, same as nouveau-firmware. and it not contains these files
13:44 wifire1: in this system gtx660 gk106 worked perfectly, same kernel
13:44 wifire1: I bought gtx650 and thought it have same chip, but it is gk107...
13:46 RSpliet: wifire1: those firmware files you're loading aren't part of nouveau. They have been extracted by some means from an official NVIDIA driver. We can't do that for you, because licensing doesn't permit redistribution.
13:47 wifire1: i know. maybe you know who packaged more firmware... ubuntu have 2009 year even on latest release
13:48 RSpliet: You *may* just be able to copy/rename the firmware files, I don't think nouveau uploads different firmwares for GK106 and GK107
13:48 RSpliet: But your mileage may vary
13:48 wifire1: do you think gk106 firmware may be compatible with gk107?
13:49 wifire1: ok I'll try
13:49 RSpliet: Otherwise, the path of least resistance for a decent nouveau experience really is updating the kernel. I don't quite know your constraints for sticking with 4.9, but bear in mind that was released in... December 2016. Many bugs with nouveau have been fixed, introduced and re-fixed since.
13:49 wifire1: i use grsecurity
13:50 RSpliet: Ah
13:50 wifire1: the last patch available for this kernel only
13:50 wifire1: it worked perfectly with gk106
13:51 RSpliet: Yeah, nouveau definitely uploads the same firmware for both. That's no guarantee that NVIDIAs firmware does something weird that makes the firmwares incompatible, but... it's worth a try
13:52 RSpliet: Worst case you'll have to reboot
13:55 RSpliet: As for 4.9 and grsecurity... the latter is a strong indication that you're not always after the path of least resistance :-P Personally not sure if its benefits outweigh the benefits of a 2020 kernel, but I guess that's an individual's decision to make
13:56 wifire1: once my server was hacked with some buffer overflow or something like this
13:57 wifire1: pax denies execution attemps in software
13:57 wifire1: and in memory pages
14:05 RSpliet: Either way, let me know whether renaming firmware works for you
14:06 wifire1: ok thanks, will try later, need to insert it back
14:28 imirkin: wifire1: you can use my extract_firmware.py script
14:28 imirkin: if you use it with blob drivers 325.15 or whatever the wiki page tells you to do, you should get them all
14:28 imirkin: that said, i've never heard of anyone with firmware-related issues on GK107
14:56 wifire1: I use firmware from 340
14:58 imirkin: then you don't get the gr firmware
14:58 wifire1: ok, will try to install 325
14:58 imirkin: no need to install it
14:59 imirkin: just have to grab it
14:59 wifire1: [I] sys-firmware/nvidia-firmware
14:59 wifire1:     Available versions:  ~325.15^md 340.32^md
14:59 wifire1:
14:59 imirkin: the extract script runs on the NVIDIA-bla.run file
14:59 wifire1: extract script runs only on nvidia proprietary drivers, as I understood
14:59 imirkin: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
14:59 imirkin: if you run it on that version
14:59 imirkin: it will make fuc_* files too
15:00 imirkin: for gr ctxsw
15:01 wifire1: ok thank you for info
15:04 RSpliet: imirkin: I had to double-check, but my most recent gr firmware fixes solving some stability issues landed in 4.7
15:05 imirkin: that's such ancient history, i had forgotten all about that
15:05 RSpliet: imirkin: so is wifire1's kernel ;-)
15:09 imirkin: hehe
15:10 wifire1: :)
15:11 imirkin: RSpliet: drm/nouveau/gr/fuc: Store $r0 in interrupt handler -- this guy?
15:11 RSpliet: I think the one after that, it's in Ben's name
15:12 imirkin: karol had a few
15:12 imirkin: using the call macro, stuff like that
15:13 RSpliet: was that gr firmware or pm?
15:13 imirkin: says "gr/fuc"
15:13 imirkin: oh wait no
15:13 imirkin: pmu/fuc
15:13 imirkin: i lied
15:14 imirkin: there ya go -- drm/nouveau/gr/gf100-: fix race condition in fecs/gpccs ucode
15:14 imirkin: commit ca79e49d6add77b69be3362ddfe5b068f62bf1de
15:15 RSpliet: I had found it ;-) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm/nouveau/nvkm/engine/gr/fuc
15:15 imirkin: yea
15:30 karolherbst: *sigh* I really can't trigger this one bug with kasan enabled :/
15:35 karolherbst: imirkin: btw, do you think you will fine dome time to look over the shader cache patches at least from a high level point of view? I am not entirely happy with some of the approaches, but I also have no better ideas
15:36 imirkin: yes, will review today.
15:36 karolherbst: cool thanks :)
15:39 karolherbst: heh.. and now that I am back on my non kasan kernel, the bug triggers
15:39 karolherbst: which... itself is a good hint towards this being some random memory issue
15:39 karolherbst: or something is indeed racy? mhhh
15:50 karolherbst: :O
15:50 karolherbst: I think I found it
15:51 karolherbst: client->super is 0/false, so nvkm_umem_search won't return anything... mhhh
15:51 karolherbst: now why is that
15:53 imirkin: there's weird shit which toggles ->super
15:54 imirkin: wouldn't be surprised if that were racy
15:54 imirkin: i don't remember the reason for it by now
15:54 karolherbst: yeah.. but
15:54 karolherbst: how can it be racy
15:54 karolherbst: keep in mind: prime + CTS
15:54 karolherbst: that's all which is running
15:54 karolherbst: mhhh
15:54 karolherbst: mhhhhh
15:54 karolherbst: I have on local modification though I think
15:55 karolherbst: ahh no
15:55 karolherbst: I thought I had forced enabled synced pbs
15:55 karolherbst: mhh
15:55 karolherbst: anyway
15:55 karolherbst: I don't see how this can be racy.. except some kworker is triggered or so
15:56 karolherbst: heh.. only one way to find out I guess
16:01 karolherbst: imirkin: a second after the fail it's still 0 :/
16:02 imirkin: i think super is only true for the drm master
16:02 imirkin: or maybe only for the "drm" client of nvkm
16:02 karolherbst: it's true if supervisor is set in nvkm_ioctl
16:02 imirkin: :p
16:02 karolherbst: but....
16:02 karolherbst: well
16:02 karolherbst: it usually is true
16:04 karolherbst: heh...
16:04 karolherbst: that's not it
16:04 karolherbst: [ 1992.271314] nvkm_umem_search client->super: 0
16:04 karolherbst: [ 1992.271315] nvkm_uvmm_mthd_map client->super: 0
16:04 karolherbst: [ 1992.271316] supervisor: 1 client->super: 0
16:05 karolherbst: heh
16:05 karolherbst: how...
16:08 karolherbst: ahh heh
16:08 karolherbst: it flips
16:08 karolherbst: somewhere
16:08 RSpliet: blame rowhammer
16:09 karolherbst: I think I will :p
16:13 karolherbst: heh
16:15 karolherbst: heh..
16:15 karolherbst: I take it back, there is something racy
16:16 karolherbst: so in a second sleep I see it flipping
16:16 karolherbst: ufff
16:19 karolherbst: that's nasty
16:19 karolherbst: imirkin: do we have anything threaded in mesa for nvc0? Assuming a single threaded application
16:23 imirkin: glthread
16:23 imirkin: that's the only thing i'm aware of
16:23 imirkin: also parallel compiles can happen iirc
16:24 karolherbst: mhh
16:25 karolherbst: well... it's definetly something which could race
16:27 cosurgi: I just did 'echo on > /sys/devices/system/cpu/smt/control' to disable multithreading in my intel CPU. I did this several times before to do benchmarks with SMT on/off.
16:27 cosurgi: And this time my VT completely foroze :()
16:27 cosurgi: I already killed this xserver, but I still see the "old" picture. And I cannot change VT :(
16:28 cosurgi: I will post a dmesg, just give me time to get to irc from my laptop
16:28 cosurgi: any chance we can fix that? :)
16:28 karolherbst: depends on the definition of "we"
16:28 karolherbst: doesn't sound like a nouveau bug :p
16:28 cosurgi: yeah...
16:28 cosurgi: there's plenty of nouveau stuff babbling in the dmesg
16:29 karolherbst: sure
16:29 karolherbst: but
16:29 karolherbst: if you halt threads bad things can happen
16:29 karolherbst: depending on how SMT gets disabled
16:30 cosurgi:just learned that this command is not safe :P
16:30 karolherbst: :D
16:30 cosurgi: I did this plenty of times past week switching on and off to benchmark
16:30 karolherbst: I think it's safer to put the CPUs offline, no?
16:30 karolherbst: but yeah..
16:30 karolherbst: all this stuff is hairy an doesn't matter in practise
16:31 cosurgi: ehh.. I really don't like that apparently I will to to restart
16:31 cosurgi: *will have to
16:31 cosurgi: I only have remote access. And 'chvt 1' and such did nothing.
16:31 karolherbst: well.. more important issues then fixing bugs which happens if you really mess with your system :p
16:31 karolherbst: dunno if there is a reliable way to disable CPUs at runtime though
16:31 karolherbst: there might
16:34 HdkR: Hm? You can park CPU cores and they'll just be offline until you reenable them
16:34 cosurgi: hmm Alt-Sysrq-k kills everything in current VT. But I still see the "old" xserver on my screens, and nothing else :(
16:34 cosurgi: I confirm the kills by looking at dmesg
16:35 karolherbst: cosurgi: tried enabling all cores?
16:35 cosurgi: yeah. I enabled them back
16:36 cosurgi: trying to startx (when logged in remotely as root) does not help. Sometimes this did help in unlocking a frozen VT
16:43 cosurgi: I guess that some nouveau's function was forced to change CPU affinity while mid-drawing something on screen
16:43 cosurgi: because there's really a lot of [cut here] and noveau stuff in dmesg
16:44 imirkin: yeah, you can hot-unplug cpu's assuming your kenrel is configured for it
16:44 imirkin: i wouldn't necessarily remove it from the socket while the system is running
16:44 imirkin: but at least at the linux level, you can do it
16:45 cosurgi: do you want to see this dmesg?
16:46 imirkin: not particularly :p
16:46 imirkin: if it's stuck, it's stuck
16:46 cosurgi: sigh, I guess that I will have to reboot :(
16:46 imirkin: you should try killing the clients
16:46 imirkin: of that x server
16:46 imirkin: if they're still around
16:46 cosurgi: I can do remotely everything, but my LCD screens are really stuck
16:47 imirkin: so what's the problem? :)
16:47 cosurgi: yeah. I killed that xserver
16:47 cosurgi: and another one too, by accident (sysrq-K while VT 2 was activated, while original problem appeared on VT 4)
16:48 cosurgi: heheh, yeah :)
16:48 cosurgi: hm. can I rmmod nouveau ?
16:49 cosurgi: probably not, because I use kernel mode setting text virtual terminals. no "real" text mode anywhere.
16:49 cosurgi: (that was the only way to get rotated text VTs)
16:51 cosurgi: well, ok. reboot then. And a precious lesson: do not ever switch SMT while xserver is active
16:51 cosurgi: I will switch to text VT, then do this and switch back to xserver
16:51 cosurgi: and see if that works :>
16:52 cosurgi: aye! rebootig :)
16:53 imirkin: bad idea
16:53 imirkin: removing nouveau is hard
16:53 imirkin: you have to first unbind the console
16:56 cosurgi: yeah. There would be nothing of value (some programs running in some xservers) after that operation.
16:57 cosurgi: I did a reboot, bot fsck is recovering journal, because in the end I had to Alt-SysRq s u b
16:57 cosurgi: shutdown -r now' didn'
16:57 cosurgi: `shutdown -r now` didn't work for some reason.
16:57 imirkin: coz nouveau is stuck
16:57 cosurgi: was stuck :)
16:58 cosurgi:wonders if there were any pending update/upgrades that warranted a reboot
16:59 RSpliet: that's why it's alt-sysrq (r e i) s s s s s u b in my book
16:59 imirkin: heh, i also hit "s" a bunch of times =]
17:03 cosurgi: I think I did. I usually do ;)
17:04 karolherbst: imirkin: any better idea to solve my issue except turning this field in a struct into a func param and pass it all the way down? Would like to hear alternatives than spending hours on that :p
17:04 imirkin: i have no idea ... this is skeggsb territory
17:04 imirkin: i just remember there being shenanignas where we flip it on and off
17:07 karolherbst: mhhh.. yeah, I don't see a better way though. Locks would be an alternative, but that sounds like a bad idea
17:23 karolherbst: ohh actually, it's not that bad
18:57 cosurgi: imirkin: btw, I just restarted, is there anything that I should try (that involves restarting) to make the DP sound working? :)
19:35 imirkin: cosurgi: i think MST sound got broken in 5.6
19:35 imirkin: what kernel are you on?
22:19 karolherbst: imirkin: uhmm.. aren't NVC0_CB_AUX_UBO_INFO and NVC0_CB_AUX_SAMPLE_INFO overlapping?
22:19 karolherbst: or do I miss something here
22:19 karolherbst: also.. why does it state 13 in the comment
22:38 karolherbst: anyway, fincs, imirkin: https://github.com/karolherbst/mesa/commit/13bb8aa1b340fa89aa3ed7bfef0ccc5d309aa404 :)
22:38 karolherbst: that seems to just work
22:38 fincs: Awesome
22:39 karolherbst: let's see if anyting regresses
22:42 karolherbst: I am actually surprised that no driver exposes more than 14 ubos :O
22:42 karolherbst: now I fear hitting some core mesa issues
22:43 fincs: I guess there is a driver ubo + "default uniform/compiler generated constants" ubo tax
22:43 karolherbst: well.. static sized arrays as well
22:43 fincs: True
22:43 karolherbst: but mhh
22:43 fincs: I saw some static array sizes somewhere
22:43 karolherbst: no, but those are usually driver internal
22:43 karolherbst: yeah.. there are many of them
22:44 karolherbst: makes things easier
22:44 karolherbst: anyway-.. GLES3: Failed: 42/3615 (1.2%)
22:44 karolherbst: huh...
22:46 karolherbst: heh..
22:46 karolherbst: okay, those are regressions from enabling more ubos :)
22:47 karolherbst: mhhh
22:47 karolherbst: I bet there is an hardcoded 15/16 somewhere
22:47 karolherbst: for the driver constbuf
22:48 fincs: Most likely :p
22:48 fincs: Maybe not in nouveau itself, but in mesa more generally
22:48 karolherbst: nope
22:48 karolherbst: driver constbuf is a driver concept
22:48 karolherbst: mesa knows nothing about that
22:48 fincs: Oh
22:48 fincs: Yeah I misread
22:49 karolherbst: NVC0_BIND_3D_CB needs adjustment as well
22:55 karolherbst: found it
22:55 karolherbst: tex descriptor were still bound to 15 :)
22:55 karolherbst: https://github.com/karolherbst/mesa/commit/dd524f7be32b7bebc7b45fce35b59d504bd054e7#diff-d2148248b5e530db60229aa9a7d81e40L1268
22:55 karolherbst: and the next change
22:56 fincs: Whoops
22:56 karolherbst: I am actually more surprised that our compiler doesn't fall apart :D
22:57 fincs: From my own experience, nouveau's compiler doesn't really have problems selecting the driver constbuf id :p
22:57 karolherbst: Failed: 2/3615 (0.1%)
22:57 karolherbst: yay
22:57 karolherbst: those are known tails
22:57 karolherbst: *fails
22:58 karolherbst: fincs: I was more concerned about pushing it to 17.. but yeah
22:59 karolherbst: I still think it's better to have it at 0, but.. oh well
22:59 fincs: I don't think it really matters tbh, it's just an aesthetic thing at this point
22:59 karolherbst: yeah
22:59 karolherbst: true
23:00 karolherbst: "KHR-GLES31.core.geometry_shader.limits.max_uniform_blocks" the heck
23:01 karolherbst: "Wrong result! Expected: 136 Extracted: 120" yeah.. that helps
23:02 karolherbst: ahh yeah
23:02 karolherbst: it binds 17 ubos :)
23:02 karolherbst: ohhh
23:02 karolherbst: smart test
23:03 karolherbst: so I guess there are more hardcoded values around
23:05 karolherbst: duh...
23:05 karolherbst: yeah..
23:05 karolherbst: constbuf_dirty doesn't work with 17 const bufs
23:06 karolherbst: fincs: that support just leasds to more mem usage :p
23:06 fincs: How much, though? :p
23:06 karolherbst: now I've added 6 bytes per context :p
23:06 fincs: lol
23:06 karolherbst: heh.. more
23:06 karolherbst: 36
23:07 fincs: That's such a huge amount, I'll have to revert it lol /s
23:07 karolherbst: dunno how big the core mesa bits are :) :D
23:07 karolherbst: but I wouldn't be surprised if it's more in a 1kb domain in the end
23:07 fincs: At this point within usual noise
23:08 karolherbst: well
23:08 karolherbst: but nobody needs that many ubos I guess :p
23:08 karolherbst: oh well
23:08 karolherbst: doesn't matter anyway
23:08 karolherbst: I just hope nobody complains on the MR and says "adding two more ubos is pointless"
23:08 karolherbst: :p
23:08 RSpliet: I weirdly expect variance in the linker to amount to more than 36 bytes of difference between compiles :-P
23:08 fincs: That's completely dwarfed by the ~1200kb I shaved off post-mesa-upgrade not too many days ago
23:08 karolherbst: fincs: I mean RAM usage though
23:08 karolherbst: but yeah
23:25 karolherbst: heh
23:25 karolherbst: nvidia only exposes 14 still
23:49 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4626
23:50 fincs: :)
23:50 karolherbst: I still want to have a better plan to support constants from the driver constbuf
23:50 karolherbst: don't want to reupload new data all the time
23:51 HdkR: woo free cbufs
23:51 karolherbst: maybe I just scan our shaders for the most common constants and have a static table
23:51 karolherbst: dunno
23:51 karolherbst: and then shaders can use one of those 1000
23:51 fincs: Hmm is loading immediates really worse than loading from a cbuf?
23:51 karolherbst: dunno
23:51 karolherbst: yes
23:51 karolherbst: wait.. I have numbers
23:51 fincs: Seems really counter intuitive to me
23:51 karolherbst: fincs: some encodings don't support long immediates as well
23:51 karolherbst: *instructions
23:51 karolherbst: like gma
23:51 karolherbst: *fma
23:52 karolherbst: so you can get rid of a few movs
23:52 HdkR: You then take a full instruction hit in the case you need a long move
23:52 fincs: I guess it's useful for cases in which you use instruction which don't support imm32s
23:53 HdkR: And then a cbuf is "register" performance :P
23:54 karolherbst: fincs: https://github.com/karolherbst/mesa/commit/4deecb06aacde3bb1eedf4fbf3f8c9cd2a81782d
23:54 karolherbst: -0.64% instructions
23:54 karolherbst: and -0.65% gprs
23:54 karolherbst: :p
23:54 fincs: Ah I see
23:54 karolherbst: ohh right, some instructions don't even have a long imm encoding
23:54 karolherbst: so yeah...
23:54 karolherbst: ohh
23:54 HdkR: look at that, -0.64% icache hit :P
23:54 karolherbst: some even have immediate + cb as an encoding
23:55 fincs: Sounds useful, however I'd stash it in the "default uniform" aka "compiler generated constant" constbuf
23:55 karolherbst: or in the driver constbuf
23:55 karolherbst: plenty of space there
23:55 fincs: Needs to be reloaded with every shader switch then
23:56 karolherbst: but I'd like to have a mix
23:56 karolherbst: static table into driver constbuf
23:56 fincs: But it's at least a good thing that you made it configurable
23:56 fincs: Both the slot and the starting offset
23:56 karolherbst: dynamic per shader values in somewhere else
23:56 karolherbst: or also in the driver constbuf
23:56 karolherbst: doesn't matter
23:56 fincs: (In my case, each shader is an isolated island)
23:56 karolherbst: we don't have to reupload the full thing
23:56 karolherbst: just whatever changes
23:56 karolherbst: and the driver constbuf changes often enough so it wouldn't even matter
23:57 karolherbst: anyway, the potential benefit is quite huge
23:58 karolherbst: and the danger of breaking stuff is quite low actually :)
23:58 karolherbst: I will scan through the shaders and see which imms are common
23:58 karolherbst: would be cool to know
23:58 karolherbst: I expect something like a constant pi to show up quite often
23:58 karolherbst: or e
23:59 karolherbst: or other impotant numbers