11:18cosurgi: On some remote server I am using:
11:18cosurgi: export DISPLAY=:22
11:18cosurgi: Xvfb :22 -screen 7 1024x768x8 &
11:18cosurgi: xfce4-session &
11:18cosurgi: x11vnc -display :22 -bg -nopw -xkb
11:18cosurgi: There's an nvidia card, and a nouveau driver loaded.
11:19cosurgi: The probem is that I want to open several instances with working opengl graphics inside Xvfb
11:19cosurgi: I don't care if that's software rendered.
11:19cosurgi: But I could not find a way to force Xvfb to use software rendering.
11:20cosurgi: When I launch a second one I get an error about not being able to use /dev/dri/card0
11:20cosurgi: How can I force Xvfb to use software rendering?
11:20cosurgi: I only need this remote server to draw some super simple opengl stuff.
11:21cosurgi: Those several instances are for several different users. All of them need simpe opengl to work.
11:22gnarface: you sure it isn't a permissions problem?
11:22gnarface: oh, maybe xvfb has something to do with it
11:22gnarface: i don't know
12:10leidurleo: I Do not precisely know how the scheduling is still done, in multi SIMT core environment, I have attilagpu but miaow does not implement texture units which are responsible for scheduling stuff to certain compute units.
12:12leidurleo: So in opencl and compute based stuff, there are abstractions for scheduling, this corresponds to some methods of texture units and arbitration on graphics shading, i have my ideas how to do this, but i may not be accurate what the real hw does.
12:16leidurleo: what i have gathered so far, on compute workloads, based of the abstraction in the compute shader the chip allocates wavefronts dynamically to the compute units
12:17leidurleo: but i think that sort of thing does not happen with texture units, where workgroups in fragment shading are allocated by the fixed function hw instead
12:26leidurleo: i just do not understand the concept what is shared resource there, since the end goal is executing the same instruction with different operands and fragment on different compute units in parallel
12:27leidurleo: i assume on opencl this is done via cache coherency protocol of instruction cache somehow
12:28leidurleo: on earlier chips if this type of thing was possible it should had been some hw dependent command buffer methods on graphics shading
12:43diogenes_: Hello guys, where can i find all available nouveau.config= options?
12:46diogenes_: ok found it
12:49leidurleo: the correct solution would be, the warp that spawns other warps stores it's queue entry where others will have the broadcasted pc entries which are temporary, then arbiter chooses another king warp, which spawns all other warps, and only king stores the queue entry etc.
12:52leidurleo: othwrwise chip has duplicated queue entries instead of little lock-step serialized logic
12:52leidurleo: which is definitely not good
14:32leidurleo: ouh, actually the chip once again does that
14:34leidurleo: I am not sure how the same PC is issued in fixed function for all the Compute Units, except for some amd cards, but it can be done with playing a little bit with texture units
14:36leidurleo: instr_info_table.v and wave.c in miaow code, kinda referre to this, when f_decode_wfid == f_vgpr_alu_done_wfid reload new stuff from cache
15:40leidurleo: rereading separate shader objects arb spec
15:49leidurleo: this is crap like expected, well it is sure, that old GPUs did not have multiple compute units
15:51leidurleo: i'd expect something like sm3.0 to have them as the first ones
16:07leidurleo: the hw dispatcher has some shared tables , however i would not do things that way to be honest it seems pretty heavyweight adding latency a bit
16:31Hopland: Hey folks. The nouveau driver freezes my system completely (i.e kernel panic). I'm unsure of how to collect logs. I'm running fedora 29. Is the magic SysRq key the way to go?
16:32karolherbst: Hopland: mhh, is there anything special you do or jsut something randomly happening?
16:32karolherbst: I think it's just an engine hang and the system would unfreeze the moment the process gets killed
16:32karolherbst: Hopland: do you have a second machine you can use to ssh into your machine to check that?
16:33Hopland: Unfortunately not
16:34karolherbst: Hopland: what you could do is to have a timer doing a sync from time to time (1 minute interval or something) and then after the next freeze you can check the logs of the last boot
16:34karolherbst: maybe it's still in the log
16:34leidurleo: Hopland: skeggsb uses netconsole , serial terminal would be ok, but all that requires another machine
16:34karolherbst: then you could check with "journalctl --boot -1" whats in there
16:35leidurleo: so you have not gotten the context scheduler still into shape, to ban corrupted bits?
16:36Hopland: karolherbst: nothing substantial. There are a few entries in regards to nouveau however - but no crash dumpb.
16:36karolherbst: Hopland: well, mind pasting the last few lines nouveau prints?
16:37Hopland: The last few lines seem to be common or standard outputs, but there are a few interesting lines at initial load...
16:37Hopland: nouveau 0000:01:00.0: DRM: BIT table 'A' not found
16:37Hopland: nouveau 0000:01:00.0: DRM: BIT table 'L' not found
16:37Hopland: not sure if that means anything
16:37leidurleo: Hopland: what is the app triggering this...?
16:38Hopland: what app? gdm... I guess. It's different though. On some liveusb's I got into the desktop, but after a short while.. freeze
16:38leidurleo: long time ago, i had serious locking due to lack of multithreading of contexts, and i gave up on it
16:38leidurleo: Hopland: well that is encouraging :D, what chip?
16:39Hopland: for instsance: on elementary OS liveusb the system would instantly freeze is I tried to open settings or the user menu on the top right
16:39Hopland: Well I've been going on for two weeks now blacklisting the nouveau driver, but I thought I might jump down that rabbit hole
16:39leidurleo: Hopland: i do not think it is kepler then, kepler was little more stable when it came to glamor, some new chip then
16:40karolherbst: Hopland: hard to say what's the cause without having anything in the logs
16:40Hopland: It should also be noted that I'm not sure if the acpi on this system fully conforms to the linux kernel
16:41Hopland: I know
16:41Hopland: I think I got a kernel panic log in ubuntu, but now I'm running fedora
16:41Hopland: right now I'm just trying to figure out how I could collect that data
16:43leidurleo: 4.4billion transistor bundled pascal
16:43Hopland: Are there any kernel boot parameters for nouveau that might help isolate the problem?
16:44leidurleo: is that chip suppose to give 3d hardware acceleration those days too, did they release those signatures i mean NVIDIA?
16:45Hopland: It should be noted that this is an ASUS ROG gaming laptop (specifically the Zephyrus M, GM501)
16:45Hopland: There might be some BIOS trickery going on.. but nothing I can alter, as the BIOS is a bit strict about what one can do
16:46leidurleo: as i remember ben i think did the 3d engine code, but prolly the firmware of reclocking would not work on this
16:46leidurleo: i do not know nothing about such card
16:47Hopland: can't find anything about it in the bug tracker
16:50leidurleo: i vaguely remember reading something about it, i think maybe pascal was the first chip to remove the GigaThread engine, that sits between the pcie and decode units
16:54Hopland: Should I try to reboot with the nouveau.debug="PTHERM=debug,PTIMER=debug" boot parameter? the kernel config in /boot says that the nouveau driver has been built with the CONFIG_NOUVEAU_DEBUG=5 flag
16:55Hopland: and what about NvI2C?
16:56Hopland: nothing in i2cdetect -l shows nvidia related i2c entries...
17:02karolherbst: Hopland: that won't help
17:02leidurleo: Hopland: seems none of the experts are coming into this, sorry i dunno anything about NVIDIA cards
17:02Hopland: installing kdump now btw
17:02karolherbst: you really want to be able to get the last dmesg from the last boot
17:03karolherbst: Hopland: "journalctl --boot -1 --dmesg" might give you a more filtered result
17:03karolherbst: and there might be some errors at the end
17:03leidurleo: Hopland: is the firmware loaded on this card for acceleration?
17:03karolherbst: or "engine resets" or something
17:04Hopland: 1) the dmesg is not very informative. I've already showed you everything that was off in regards to nouveau. 2) I'm not sure if the firmware is loaded for acceleration
17:05karolherbst: Hopland: mhhh, so probably the journal wasn't flushed out to the drive :/
17:05karolherbst: Hopland: how does the freeze look like? nothing happens, but you can still move the cursor?
17:05karolherbst: leidurleo: whether the firmwares are loaded or not are completly irrelevant to this issue
17:05karolherbst: spoiler: they are
17:05Hopland: cursor freezes as well. I can't even ctrl-alt-f1 into tty
17:06karolherbst: Hopland: mhhh, so maybe it is indeed a hard crash, so yeah...
17:07karolherbst: Hopland: do you have pstore mounted? /sys/fs/pstore/
17:07karolherbst: there _might_ be some files in there
17:07karolherbst: but... it seems all distributions are configureing it wrong
17:07karolherbst: so there won't be any
17:08Hopland: karolherbst: nothing there
17:08karolherbst: crappy distributions :P
17:08karolherbst: none of them does it
17:08karolherbst: Hopland: "/sys/module/pstore/parameters/backend" contains "(null)", right?
17:09Hopland: It shure does dere, buddy
17:10leidurleo: karolherbst: i followed your vision about graphics workload warp scheduling, and was it such, that on graphics you get parallelism on only one core if the compute unit is not being used , it sounded ammusing, but it looks like someone is also talking about it?
17:10Hopland: installing kernel-debuginfo and crash right now
17:10Hopland: See if I can't get a proper crashdump
17:10karolherbst: Hopland: I know that there are some systems where writing into the uefi can brick the machine though :/
17:10karolherbst: but I think those issues are resolved
17:10karolherbst: and only covered samsung laptops
17:10karolherbst: or something
17:10karolherbst: Hopland: yeah.. well, the thing is, when the kernel crashes for real, there is nothing the kernel can do
17:10karolherbst: not even writing into the fs
17:10karolherbst: because it could corrupt it
17:11karolherbst: pstore can be used to store the current dmesg into the uefi
17:11karolherbst: and read out on next boot
17:11Hopland: I see
17:12karolherbst: Hopland: with pstore.backend=efi it can be enabled though... but again, there were some systems out there which were allergic to that kind of stuff :/
17:12karolherbst: best alternative would be netconsole
17:12karolherbst: but that requires a second machine
17:13karolherbst: there is also some weirdo memory backend for pstore
17:13karolherbst: but I have no idea how to use that one
17:14Hopland: I'm going to test some boot parameters - brb
17:15karolherbst: Hopland: ohh, you could also just use your phone
17:15karolherbst: and use that as a ssh client
17:16karolherbst: and just run "dmesg -w'"
17:16karolherbst: this might be enough to print something
17:19Hopland: Watchdog BUG: soft lockup
17:20karolherbst: is there also a stacktrace?
17:24Hopland: Yup ^^
17:27karolherbst: ahh, ignoring the first stacktrace
17:27karolherbst: Hopland: this is a laptop right?
17:27karolherbst: ahh, heh.. known issue
17:28Hopland: My beautiful multi-coloured ASUS ROG Zephyrus M GM501 ^^
17:28Hopland: Really? Cool! That means I can just wait :D
17:28karolherbst: "wait" is a bit overstressing it
17:29karolherbst: we have no idea on how to fix it, and nvidia is "working on it"
17:29karolherbst: the painful part is, the nvidia driver doesn't do that runtime d3cold stuff on linux
17:29karolherbst: so we can't really reverse engineer it
17:29leidurleo: hmm what, means this card is not working on nvidia binary too?
17:29karolherbst: Hopland: nouveau.runpm=0 "fixes" it
17:30Hopland: So I'm guessing if it'll ever be fixed it'll be fixed in the form of a firmware update
17:30karolherbst: but.. your GPU is always on then
17:30HdkR: "working on it"
17:30karolherbst: HdkR: well, there _was_ an update
17:30HdkR: Oh snap
17:30Hopland: Even on Ubuntu, there's this bug since 16.04 where some dGPUs will be running - DESPITE the fact that the module has been unloaded
17:31karolherbst: Hopland: well, that's the default
17:31Hopland: Not on Windows :(
17:31karolherbst: Hopland: what you could do is to blacklist nouveau and let something enable the runpm features through sysfs
17:31Hopland: there it turns off quite nicely
17:31karolherbst: Hopland: even on windows, it needs driver support for turning the gpu off
17:31karolherbst: well right...
17:31karolherbst: the issue is not turning it off
17:31Hopland: Of course it does
17:31karolherbst: the issue is turning it back on
17:31karolherbst: this fails... for whatever reasons
17:31karolherbst: and essentially hangs your system
17:32karolherbst: if there is no driver doing stuff, it all turns off/on quite nicely
17:32Hopland: Which is why my default is to not have the nvidia driver installed and blacklisting nouveau from boot parameters
17:32karolherbst: Hopland: I have a kernel module which only does that: https://github.com/karolherbst/pci-stub-runpm
17:32karolherbst: needs tweaking for other devices
17:32karolherbst: and such
17:33karolherbst: but you could also let tlp or laptop-mode-tools handle that
17:33karolherbst: doesn't really matter
17:33karolherbst: Hopland: mind pasting your lspci -t ?
17:33karolherbst: with nouveau blacklisted
17:33Hopland: In the presence of GODS one must comply
17:34karolherbst: ahh, that makes it easy
17:35leidurleo: shit. i would like to know how the SM in glsl is being scheduled to
17:35karolherbst: echo "auto" > /sys/bus/pci/devices/0000\:01\:00.0/power/control
17:35karolherbst: echo "auto" > /sys/bus/pci/devices/0000\:00\:01.0/power/control
17:35karolherbst: Hopland: ^^
17:35karolherbst: with that your GPU should turn off and on
17:35karolherbst: well... it wouldn't really turn on all that much, because no driver
17:35karolherbst: but still
17:35karolherbst: shouldn't cause any hangs
17:36karolherbst: cat /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status
17:36karolherbst: tat should print "suspended"
17:36karolherbst: did you invoke the echo calls?
17:36karolherbst: both of them?
17:36Hopland: should I? ^^;
17:36karolherbst: if you do, then runtime_status should flip over to suspended
17:37karolherbst: well, if you care about using your laptop on battery that is :p
17:37karolherbst: also, might spin down the fans a little
17:37Hopland: I'm having a weird bug now where I can't sudo anymore
17:38karolherbst: you can't
17:38karolherbst: you try to write the output of "sudo echo auto" into the file as your user ;)
17:38karolherbst: "echo "auto" | sudo tee ..." is workaround
17:38Hopland: no no - I can't sudo anything
17:38karolherbst: or root shell
17:38karolherbst: that's a problem then
17:39karolherbst: Hopland: sudo -s?
17:39Hopland: At leasst not in wayland/gdm
17:39karolherbst: well worst case
17:39karolherbst: su root
17:39karolherbst: and root password
17:39Hopland: in tty it works ^^;
17:41Hopland: indeed it is
17:41Hopland: Going to try and reboot - brb
17:42Hopland: reboot did the trick!
17:42karolherbst: what do you mean?
17:43Hopland: must've been some systemd cockup
17:43Hopland: in any case, I ran both those echos and upon cat'ing runtime status: suspended
17:43karolherbst: Hopland: with nouveau blacklisted?
17:44karolherbst: okay, nice
17:44karolherbst: "lspci" just works?
17:44Hopland: no nvidia driver either
17:44karolherbst: lspci might cause some delay though
17:44karolherbst: I guess that should work out alright then
17:44karolherbst: we are trying to get a proper fix for that, but that's not as easy :/
17:45karolherbst: I have some ideas what the issue is, but nothing where I'd say I really undertand the issue
17:48Hopland: You are so far above me on that one
17:49Hopland: Created a bash script and a systemd service to echo those values on boot
17:49Hopland: Thanks :D
17:49Hopland: I'm going to stick around on this channel, so if you want me to test something let me know
17:50Hopland: Just don't brick my system ^^;;
17:56leidurleo: all that i understand from the hw dispatcher that this is also round robin
17:56leidurleo: between CUs but...there are details missing still
18:05leidurleo: current understanding is that dispatch latency is just killing the performance, it is not worth it, so running things on single core for the first pixel would be just fine
18:27leidurleo: one nvidia guy says so in stackoverflow though, that when one workgroup is finished or threadblock, newer nvidia cards raise an interrupt and go to the next
19:34leidurleo: ok I am done, it seems finally I was able to agree with karolherbst too, in the beginning it sounded a bit weird to me, that on GLSL only one CU is scheduled at time
19:45leidurleo: so now you should understand right, instead of reusing the filled in queue slots after the first pixel is done which would give all the performance in the world, you do fetch anything again with full pipeline, therefor the performance is bad also
20:00armadi: Hi all
20:00armadi: has anyone had any luck with a laptop with nvidia optimus + displayport monitors via a tb3 dock?
20:02armadi: Manjaro works out-of-the-box on the laptop screen and Kubuntu (with nouveau) works out-of-the-box on the dp monitors
20:02armadi: but nothing I have tried has made them both work (Besides the windows that the laptop came with)
20:03karolherbst: armadi: mhh, weird
20:03karolherbst: it should just work, more or less
20:03karolherbst: I'd imagine that kubuntu does something weird if the laptop screen doesn't work
20:03karolherbst: because there is no reason why it wouldn't
20:03armadi: The manjaro install (my preferred one) doesn't seem to like loading nouveau, it's never loaded at boot
20:04armadi: if I try to load it, it errors and hangs
20:04karolherbst: what is the error?
20:04armadi: the first relevant one is `nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ]`
20:04karolherbst: doesn't matter
20:04armadi: the hanging is from a billion `nouveau 0000:01:00.0: i2c: aux 0004: begin idle timeout bad00100`
20:05karolherbst: that sounds like an ugly one
20:05karolherbst: does nouveau load alright without the tb3 display connected?
20:06armadi: sort of, there are still errors but it doesn't actually hang
20:06armadi: brb let me try again
20:07leidurleo: anyhow: karolherbst: what i did there was, add the xilinx block_ram module and fixed the vgpr.v and issue testbenches minorly, and called the issue_tb.v from vgpr_tb.v with minor modification, issue_tb.v alone would had been fine too
20:08leidurleo: and than simulated stuff with verilator, since i do not have synapsys, and there wr_decode_data flops were dumped in the Trace.cpp file
20:08Armadi_: Ok connected on my phone so when it hangs I don't drop
20:08leidurleo: and final thing is the code...but that is very easy
20:10Armadi_: It hangs a little and then loads with the same errors
20:10Armadi_: And then tries to load Nvidia which I have blacklisted ?????
20:10leidurleo: block_ram module for the vgpr register file was needed to be added and regfile implementation changed based of the scratch aka miaow2.0, since the old one did not simulate or compile
20:13armadi3: karolherbst: any idea why nvidia will get loaded if I have it blacklisted?
20:14armadi3: I mean it's not loaded but it threw some messages in the kernel log ???
20:14leidurleo: ah heck now i remember, that issue_tb.v was not enough but, i just called the issue module from vgpr_tb.v, i can give the trace though
20:16armadi3: by booting, loading nouveau with runpm=0, and *then* connecting the dock, I can get xrandr to show the ports, but they show as disconnected
20:16armadi3: I've been messing with it for a few days now
20:18leidurleo: karolherbst: finnish hackers from Tampere have the full opencl implementation called POCL as you know, it is 2.0 compliant, they use it as a front-end to their TCE processors
20:18karolherbst: armadi3: userspace
20:18karolherbst: if applications do cuda stuff eg
20:18karolherbst: or CL
20:18karolherbst: the nvidia userspace tries to load the nvidia kernel module
20:19karolherbst: armadi3: mhh, interesting
20:19armadi3: do you think I should try uninstalling then?
20:19armadi3: nvidia blobs I mean
20:19karolherbst: armadi3: I know we had some issues there, but it should work with newest software
20:19karolherbst: armadi3: shouldn't matter
20:19karolherbst: nouveau.runpm=0 is definetly a good idea to debug this
20:20karolherbst: armadi3: what's the version of the kernel you are running?
20:20armadi3: 5.0.1, the kubuntu that worked on the DP monitors was 4.19
20:20armadi3: or maybe 4.18 idr
20:21karolherbst: can you try to plug them out and in again?
20:21karolherbst: also content of your /var/log/Xorg.0.log should be helpful
20:22armadi3: nothing in the kernel log from unplugging/replugging the DP
20:22armadi3: I'll get a paste for the X log
20:22leidurleo: it is distribution specific, but the nvidia driver binary today, has also some KMS console plumbing?
20:23armadi3: karolherbst: https://pybin.pw/8Jiu
20:23leidurleo: armadi3: otherwise just unload the nvidia module, and change the glx xorg module against mesa stuff
20:23leidurleo: armadi3: which distribution?
20:24armadi3: leidurleo: manjaro
20:24leidurleo: manjoro, is arch based right, i can not remember how that worked
20:24armadi3: leidurleo: according to lsmod, nvidia isn't actually loaded
20:24leidurleo: i use mint linux
20:24armadi3: leidurleo: yes it is basically arch
20:25leidurleo: what i think maybe the usual problem could be that there are remains of the nvidia ddx glx modules somewhere
20:26armadi3: how would I go about checking/fixing that?
20:26karolherbst: armadi3: uff, it uses modeset for both devices... mhh
20:27leidurleo: armadi3: well i managed to open your log, and it does not prove my theory
20:27leidurleo: you are trying to load an intel module there
20:27leidurleo: probably cause you have also an integrated gpu
20:27armadi3: leidurleo: intel needs to be loaded for optimus, doesn't it?
20:27karolherbst: armadi3: sadly there aren't many with a TB3 display yet.. allthough that should be simply be DP
20:28karolherbst: Lyude: any ideas?
20:28leidurleo: armadi3: well i can't remember there was something like reverse prime which yeah might had needed to be loaded indeed
20:29Lyude: karolherbst: drm.debug=0x106
20:29karolherbst: armadi3: listen to Lyude
20:29karolherbst: DP expert :p
20:29armadi3: ok, stand by for reboot
20:30leidurleo: i think that line figures that out probably
20:30leidurleo: if there is output mux available
20:30Armadi_: I can't get into grub lol, it boots too fast
20:31Armadi_: It's tab to interrupt? Or lshift
20:31karolherbst: Lyude: debug can be changed at runtime, right?
20:31Armadi_: Oh well let's do that then
20:31karolherbst: figuring out hotplugging might be even easier
20:31karolherbst: Armadi_: hotplugging also doesn't work, right?
20:32karolherbst: Armadi_: as root "echo 0x106 > /sys/module/drm/parameters/debug"
20:32karolherbst: and then hotplug the display
20:33karolherbst: there should be new stuff in dmesg then
20:33Lyude: karolherbst: yes
20:33Armadi_: Yes indeedy
20:33Lyude: Armadi_: left shift/f8/esc
20:34Lyude: there's also a command to make it go to the grub menu on the next boto
20:34Armadi_: Ok there is new stuff in dmesg, here's a paste of it in whole: https://pybin.pw/GH6K
20:35Lyude: Armadi_: you'll need to unplug the monitors in question and plug them back in, as that debug option I gave you logs the AUX channel transactions going between the GPU and the displays
20:36armadi4: Lyude: I did that
20:36Lyude: so I can see the actual detection sequence
20:36Lyude: you're sure?
20:36Lyude: mind just trying it one more time for hahas?
20:36armadi4: just did, no new messages
20:36karolherbst: Armadi_: mind giving us your full dmesg?
20:37karolherbst: I ... have a bad feeling
20:37armadi4: that last link should be it
20:37Lyude: Might also be the fact you don't have nouveau loaded
20:37armadi4: literally piped dmesg into curl for that
20:37armadi4: oh you're right lol
20:37Armadi_: Ok we'll try that again
20:38Armadi_: Oh wait no
20:38Armadi_: :| gotta reboot now
20:40leidurleo: Lyude: btw. what this AUX transaction log should reveal/show?
20:40leidurleo: cause again of course i know nothing about that
20:41Armadi_: Ok, set drm debug, now loading nouveau...
20:42leidurleo: allready googled, yeah insanity
20:42Armadi_: Ok so I did it right this time and there's still no new messages (besides the 4 that you already have)
20:43Armadi_: New dmesg: http://pybin.pw/7rMS
20:45leidurleo: i can see there totally different messages about nvidia outputs
20:46leidurleo: since prolly you loaded the nouveau this time too
20:46armadi5: yes, I set drm.debug, then loaded nouveau, then plugged in the dock, then unplugged/replugged one of the DP cables
20:46armadi5: idk if that's the best order
20:47armadi5: still not sure why nouveau isn't loading at boot
20:47karolherbst: big ufff
20:47leidurleo: [ 126.703146] NVRM: No NVIDIA graphics adapter probed!
20:47karolherbst: armadi5: what version of linux-firmware do you have?
20:47karolherbst: leidurleo: please don't interfer with debugging if you have no clue
20:47armadi5: karolherbst: 20190212.28f5f7d-1
20:48karolherbst: big uff
20:48karolherbst: the accel engine doesn't come up
20:49karolherbst: it might be the bug I have on my gp107 as well... but that's a firmware bug nvidia has to fix
20:49armadi5: cool cool cool cool
20:49armadi5: I mean worst case I have to use kubuntu and have 33% fewer monitors than I'd like
20:49karolherbst: yeah.. and the display engine is off
20:50karolherbst: why does it work with kubuntu
20:50karolherbst: armadi5: nvidia driver with kubuntu?
20:50armadi5: Do you think it would help if I booted up kubuntu to get some logs from there?
20:50armadi5: karolherbst: nope, that's using nouveau as well.
20:50karolherbst: yeah... a dmesg would help
20:50karolherbst: and /var/log/Xorg.0.log
20:52Armadi_: Keep in mind this is booting from a live USB so things might be weird
20:52Lyude: karolherbst: yeah I was just about to say before I scrolled down that I think DP probably isn't the issue here
20:53Lyude: Armadi_: don't worry, linux is smart enough to not really make any difference when booting off a USB
20:53Lyude: unlike some other OSs
20:54leidurleo: interact what? i can just read the log, there is something bad with memory engine maybe
20:55armadi7: also, interestingly, I don't need to authorize the tb3 dock for dp to work from kubuntu
20:55Lyude: yeah that's expected
20:55karolherbst: it's a firmware setting though
20:55Lyude: DP kinda goes onto it's own lane iirc
20:55Lyude: karolherbst: for DP? I don't believe so
20:55karolherbst: ohh, DP, yes
20:56karolherbst: Lyude: I think on my XPS I can require auth for DP as well... not quite sure
20:56karolherbst: but there are like multiple settings
20:56karolherbst: just turned it oj a while ago :)
20:56karolherbst: well the basic TB stuff
20:56Lyude: karolherbst: yeah, I'm not entirely sure myself either after I noticed the other day my razer laptop doesn't notice the MST hub connected to my TB3 dock until it's authorized
20:56Lyude: could just be mst being slow though
20:56armadi7: Xorg.0.log: https://pybin.pw/oO_f
20:57karolherbst: Lyude: well, that's TB then ;)
20:57armadi7: dmesg: https://pybin.pw/6nfC
20:57Lyude: karolherbst: maybe, I'd like to actually look at the kernel output to be sure because if it is that means I'm probably going to try at some point to see if we can hook bw info from TB into drm again
20:57karolherbst: heh :D
20:57Lyude: once my plate is like, not overflowing
20:57karolherbst: right :)
20:58karolherbst: I also have a nasty issue to debug right now, and that's nasty
20:58karolherbst: "nouveau 0000:01:00.0: gr: init failed, -22"
20:58karolherbst: so there is that
20:59karolherbst: but apperantly we don't fail as fatal as we do on newer kernels?
20:59armadi7: karolherbst: yes but this is kubuntu where the dp monitors *do* work
20:59karolherbst: yeah, exactly
20:59karolherbst: the gr engine shouldn't be required for displaying stuff
21:00karolherbst: but.. maybe we changed something somehow and now we fail to bring the display stuff up with gr init fails
21:00karolherbst: skeggsb should know
21:00Lyude: karolherbst: it may cause problems or be a sign of a larger underlying issue though
21:00karolherbst: gr fails
21:00karolherbst: that's a point where I am already willing to stop debugging and blame nvidia for shipping us crappy firmware
21:01Lyude: armadi7: if you have the knowledge and/or willpower: a bisect of this issue would help a ton
21:01karolherbst: and crappy means that there is no "error" in order for us to debug it anyway
21:01armadi7: Lyude: this is my new setup and I'm on the second day of my job still trying to get my monitors working, so I'll see if I have time
21:02armadi7: Lyude: tbh I'm not even sure it's the version mismatch causing the difference (unless you are), it could be a config thing
21:03Lyude: I'd imagine it's a version mismatch, there isn't any config that can make nouveau just not turn on like that :p
21:03Lyude: s/version mismatch/regression/
21:03armadi7: in any case, thanks to the whole crew here for giving it a try
21:04armadi7: fun fact: if I boot up kubuntu without the dock, the laptop screen still doesn't work. There's just no display output, so that's super cool :|
21:04armadi7: So it looks like there might be an intel bug as well
21:05karolherbst: armadi7: well that seems to be fixed with a newer kernel though
21:05Lyude: that's very suspecious
21:05karolherbst: or userspace stack
21:08karolherbst: Lyude: or well.. kubuntu uses the modesetting ddx, where the other one used intel
21:08Lyude: ooooh, yeah that could be it
21:08armadi7: all right, it's quitting time here so I'm out. Thanks again for your help. Lyude, I will try to bring back some useful info if I ever find the time to bisect (if I do before it's fixed)
21:09Lyude: armadi7: np, thank you for reporting the issue! :)
21:48lebomees: maybe someone can read it... delt a month with those simulators.
21:50lebomees: i extracted a part from the trace file, it is from instr_info_table.v and includes only f_vgpr_alu_wr_done_wfid mux and the starts of or some part of f_vgpr_lsu_wr_done_wfid
21:51lebomees: there are those hex numbers in the right hand side, and 40*40 instances approximately, it will take some time to read for the best too, maybe glisse can manage to do that
21:53lebomees: the whole trace froze the dpaste site on my computer, cause it was a half a million lines approximately
22:01lebomees: i can't make it more clear, i had trouble reading the code myself too, maybe this dump helps, anyhow those the issue queues
22:03lebomees: there are "7 Vtemp" variables from Vtemp2990 to Vtemp3091 each having 7*40 different wfid combinations or so
22:06lebomees: this linux console stuff is pretty neat, it always ticks reliably on extra big files, and the simulator was also neat to dig those flops out
22:07lebomees: allthough pretty nuts stuff, i do not pretend to be any good at this, but the code is easy
22:07lebomees: the final code
22:14lebomees: i think i mostly explained how this works too, i dunno if you can only understand
22:15lebomees: hw wise it does not cost much to have such central flops in the chip, but performance wise this does nuts stuff in low power mode
22:16lebomees: so designers have planted such queues there, and i explained shortly allready how to run them, so i need to go now