08:50pmoreau: karolherbst: FYI, you can also break on a memory error with valgrind; I discovered that recently: https://heeris.id.au/2016/valgrind-gdb/ (scroll down to the “It’s GDB time” section)
08:51pmoreau: But I should check libasan as well
08:56HdkR: I also fully recommend clang's asan :D
12:40HdkR: karolherbst: btw, did you manage to get those things? Sorry about the pain
12:41karolherbst: something arrived and I want to pick it up from the office today
13:44kwizart: hello, I would like to update the wiki about video firmware availability for nouveau and Fedora (via RPM Fusion)
13:44kwizart: as mentionned here: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#Firmware
13:45kwizart: as one could use it from http://koji.rpmfusion.org/koji/packageinfo?packageID=554
13:49karolherbst: kwizart: those are different things
13:49karolherbst: ohh wait
13:49karolherbst: you just want to have a link added there?
13:49kwizart: another open question, is it possible to (even partially) build some part of the gpu firmware for nvidia hw (before thoses hw generation that requires signing) or are theses blob fully closed source content ?
13:50kwizart: karolherbst, yep, in the lucky distro area ;)
13:50karolherbst: kwizart: the biggest issue is just that nobody spend enough time reverse engineering those. I think we could potentially write our own
13:52kwizart: karolherbst, you are speaking about the video firmware ? well, that's interesting up to the generation that would requires firmware signing, indeed
13:52karolherbst: well, if somebody wants to dig into it, sure.. but we also have to do the bring up for other gens as well and stuff..
13:54kwizart: yep with 340xx been EOL by nvidia, I'm still surprised by the number of people still using 340xx hw, so I'm trying to forward them to use nouveau and that's probably of the the missing feature ootb
13:55kwizart: but my question about building the firmware was more related to the firmware distributed as part of the linux kernel
14:04karolherbst: right, but for that we have to come up with our own firmware
14:07kwizart: but if assuming a own firmware, isn't there a need for a dedicated compiler by then ? for the specific architecture used on the gpu ?
14:08pqatsi: Hello folks! Some time ago, I had issues with my Nvidia Optimus (NVIDIA Corporation GP108M [GeForce MX150]) and nouveau and PM support wasnt complete or stable on my platform. After F31 system upgrade, i'm want to try nouveau again, but i dont know if its stable now. Someone can help-me to check my card compatibility (Specially the PM issue) with nouveau nowadays?
14:09pqatsi: (Environment information: Notebook is a Dell Inspiron 7572 and I'm using Fedora 31 now)
14:11imirkin: kwizart: the firmware shipped with linux is fully open -- the assembly used to generate the data is shipped alongside, you use envyas to assemble it
14:12imirkin: pqatsi: probably not - karolherbst has a couple of patches that aren't upstream at this point
14:12karolherbst: pqatsi: mind pastebinging your "lspci -tv" and "lspci -nn"?
14:13imirkin: i like pastebinging...
14:16pqatsi: karolherbst: Its here: https://paste.fedoraproject.org/paste/x9rmLU0TjRGdcfRM1MdjXg
14:18karolherbst: pqatsi: you had those "refused to change power state" errors or something?
14:22karolherbst: pqatsi: I am working on a fix there, but it's still unclear what the real issue is. I have a workaround you could try and see if that helps
14:23karolherbst: pqatsi: https://copr.fedorainfracloud.org/coprs/build/1092497 I triggered a new build with some adjustments according to your lspci outputs
14:23pqatsi: karolherbst: My last attempt was: 2018-08-24 10:59:24 pqatsi No progress with GP108M and nouveau here - even with runpm=0. There is a chance of better support in kernel 4.18 or something I can try?
14:24karolherbst: pqatsi: right, but I am wondering what exact error you get. I guess with runpm=1 and lspci the machine just crashes or something?
14:24karolherbst: or does it only crash when you try to render something on the GPU?
14:24karolherbst: or does the machine just fails to boot outright
14:24pqatsi: karolherbst: karolherbst well, I can try again, but I need to clean the house. Nvidia and bumblebee removal is enough?
14:25pqatsi: (And also reversing masks from https://docs.fedoraproject.org/en-US/quick-docs/bumblebee/ )
14:25karolherbst: should be, as long as nouveau gets loaded
14:25karolherbst: I am sure that my kernel build will fix the issue, it just a matter of which issue as it fixes two
14:25pqatsi: karolherbst: I remember machine booted well, but crashed when using 3D functions. Ill try again now
14:26karolherbst: okay, having the dmesg output of the crash or something should help identifying which issue it exactly is
14:26pqatsi: right. hold on some minutes plz
14:52pqatsi: karolherbst: well, a mess happened here.
14:54pqatsi: karolherbst: With nouveau.runpm=0 https://paste.centos.org/view/33e61c27
14:56pqatsi: karolherbst: Boot w/o arguments: https://paste.centos.org/view/f87b84c3
14:56pqatsi: Both did not loaded gdm
14:56pqatsi: last resource worked is BOOT_IMAGE=(hd1,gpt3)/vmlinuz-5.3.9-300.fc31.x86_64 root=UUID=1fffc5c0-7768-406d-bec3-a5eea368c93d ro rootflags=subvol=root resume=UUID=6d09f50a-c8a4-4ae8-ae98-3a60c81efa94 rhgb quiet loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3 LANG=pt_BR.UTF-8 pci=noaer nouveau.modeset=0
14:59pqatsi: karolherbst: I saw you compiles a patched kernel module. Isnt possible to build just nouveau with dkms subsystem instead build a entire kernel?
15:06karolherbst: pqatsi: ohh, you don't seem to have the runpm issue
15:06karolherbst: it's something else
15:09karolherbst: pqatsi: and no, we don't support dkms at all. You can build nouveau as a module but then installing it is a mess
15:10karolherbst: pqatsi: mind adding my copr and swtching to kernel-5.3.8-9000.fc31?
15:10karolherbst: this should fix your issue
15:11karolherbst: the pmu reset is also interesting
15:11karolherbst: skeggsb: ever seen that?
15:13karolherbst: pqatsi: so yeah.. no idea really what bug that is, but it seems to be something else
15:13karolherbst: and that runpm=0 doesn't help is kind of showing that
15:14pqatsi: karolherbst: I can install you copr, no problem
15:14karolherbst: well you also need to downgrade the kernel as my kernel build is a bit too old there. The new one will be ready in like 10 hours or so...
15:15karolherbst: skeggsb might know something about your issue, I'll try to talk to him about this
15:15pqatsi: karolherbst: no issue, I can try hold it
15:16karolherbst: pqatsi: right now booting with nouveau.modeset=0 let's you boot, right?
15:16karolherbst: ahh yeah, you wrote it
15:16pqatsi: karolherbst: Yup, booted with modeset=0
15:17pqatsi: karolherbst: build link expired, do you mind to send you copr link?
15:18karolherbst: pqatsi: yeah, I removed the build as your system doesn't seem to be affected by the runpm issue at least
15:19karolherbst: and I want to be super careful on where to enable it in order to properly pinpoint the issue
15:19pqatsi: karolherbst: fair :)
15:20pqatsi: Anyways, install last kernel from you repo?
15:22pqatsi: kernel x86_64 5.3.8-9000.fc31 copr:copr.fedorainfracloud.org:karolherbst:Nouveau_Testing 39 k
15:22pqatsi: right one?
15:30pqatsi: karolherbst: You kernel works with modeset: https://paste.centos.org/view/e98f93bd
15:30pqatsi: But something appeared as a warning on dmesg
15:30pqatsi: karolherbst: Do you want I test something to validate?
15:30karolherbst: yeah, DRI_PRIME=1 glxinfo
15:33karolherbst: this pmu reset issue is still weird
15:33njsg: Is there any known limitation in handling interlaced video with nouveau?
15:34njsg: This would be VGA output on NV44 (if I got the card name right)
15:35pqatsi: karolherbst: https://paste.centos.org/view/66e0fee0
15:35karolherbst: pqatsi: yeah.. seems to work alright
15:35karolherbst: njsg: it's broken over DisplayPort afaik, but it should work with HDMI
15:36karolherbst: but nv44... no idea about that
15:36karolherbst: maybe it works?
15:36karolherbst: maybe not?
15:36njsg: no display port nor hdmi in use
15:36pqatsi: karolherbst: something I can do to help you to find out whats happening with pmu reset issue?
15:36karolherbst: pqatsi: no idea, skeggsb might know more
15:37njsg: a laptop with the radeon driver was apparently able to use that mode, but with nouveau some lines get mixed/repeated (at one point it seemed it was rendering interlaced frames as progressive, but that was possibly a coincidence)
15:37karolherbst: njsg: DVI I guess?
15:38njsg: the physical output port is VGA, whether this is generated by the same part that generates DVI or separately I don't know
15:40njsg: the modes are as reported by the display, I did no manual changes
15:42karolherbst: ohh, I see
15:42karolherbst: imirkin might know something here
15:43karolherbst: the only thing I know is that interlaced isn't supported with DisplayPort on certain GPUs, but I only found this on maxwell ones, which are way newer
15:43karolherbst: maybe there are some limitations on that era as well
15:43karolherbst: njsg: I guess the non interlaced modes just work?
15:43karolherbst: or does this display only does interlaced on higher res?
15:43pqatsi: karolherbst and skeggsb - May be better I register a bug to keep track?
15:44karolherbst: pqatsi: you could, but it might be it's already fixed by some work skeggsb is doing
15:46njsg: karolherbst: the others seem to work fine, although I didn't try them all.
15:46pqatsi: Well, ill wait here some time for a position. I just want to make sure I'll be reacheable if you need more debug
16:00imirkin: njsg: things like that aren't often tested. it's the type of thing that *ought* to work, but might not
16:01imirkin: njsg: a good thing to test would be if the mode works with xf86-video-nv
16:01imirkin: (you'll have to not load nouveau if you want to use that)
16:01imirkin: if it does, you can try to compare the code -- the nouveau pre-nv50 modesetting code is a derivative of that -nv code.
16:09njsg: imirkin: is that the older FLOSS nVidia driver for X11?
16:12njsg: I do have an xf86-video-nv package available, I can try installing that. Is it compatible with the kms,dri, etc kernel driver used by nouveau?
16:29karolherbst: HdkR: so, I have everything except the case at home now :)
16:30HdkR: Did you get the email I forwarded to you about the case in customs?
16:30imirkin_: njsg: no, it's highly incompatible. you'll have to boot with nouveua.modeset=0
16:30imirkin_: however it should let you test whether the code in -nv is able to bring up the right mode
16:30karolherbst: HdkR: yes
16:32karolherbst: HdkR: I think...
16:32karolherbst: maybe I didn't
16:32karolherbst: I got some mails at least
16:32karolherbst: and I had to fill out some stuff
16:32karolherbst: but the case should be in the office
16:33karolherbst: it's just to big for our locker stations :D
16:33HdkR: ah, okay
16:33HdkR: Sounds good
16:33karolherbst: no idea if I have to pay anything ... :D
16:33HdkR: Will have to make it up to you for all the nonsense
16:34karolherbst: I should clarify that somehow
16:34karolherbst: maybe I got emails on my private one
16:34karolherbst: got your email
16:34karolherbst: yeah, that's what I submited online
16:34karolherbst: maybe they send me a letter...
16:35karolherbst: HdkR: comming to fosdem? :D
16:36HdkR: Wasn't really planning on it but maaybe?
16:40njsg: imirkin_: Ok, I'll see how easy/hard it is to test -nv with my current configuration, then. (Not right now, though, a bit later maybe.)
16:43imirkin_: njsg: the relevant modesetting code for your gpu is somewhere in https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/dispnv04
16:44imirkin_: njsg: if you look at the -nv code, you'll note a lot of obvious similarities.
16:44imirkin_: (not sure if you're a developer, if you're not, you may be in trouble...)
16:44karolherbst: HdkR: now I have to think about what to do with that machine, but I guess it could indeed become the controller of the CI system somehow
16:45karolherbst: just have to figure out how to do this setup the others did as well with lava or something
16:45imirkin_: i do have a NV44, which iirc has a VGA port, and i even have a VGA-capable flat panel, so i could hypothetically investigate, but i dunno if i'd ever have time
16:45karolherbst: and connect the tegra with that
16:45HdkR: For the next set you should confirm with me if amazon.de solves the customs problem :P
16:45karolherbst: I probably will need a switch as well.. uff
16:45karolherbst: totally forgot about it
16:46karolherbst: I want to create a full separate network through the controller obviously
16:46HdkR: Ah right, network switch is worthwhile
16:46karolherbst: and a PCIe ethernet card as well probably
16:47karolherbst: uff, the board doesn't come with a GPU or the CPU, right?
16:48HdkR: All the parts should be enough for a complete system other than the GPU
16:48HdkR: and need to make sure to update the BIOS to support the CPU
16:48HdkR: Which it supports bios flashback to flash without a CPU in it
16:49karolherbst: HdkR: the issue is just, that I probably want to have two ethernet ports on that machine :/
16:49HdkR: ah, that board didn't have dual ethernet did it
16:49karolherbst: yeah, and only one PCIe port
16:49karolherbst: ohh wait
16:50karolherbst: I could have a x1 ethernet card
16:50karolherbst: should be enough
16:50HdkR: x1 is good enough for gigabit
17:01karolherbst: HdkR: Intel PRO/1000 PT Server, RJ-45, PCIe 1.0 x1 (EXPI9400PT) is It think what I would go for.. but I guess you haven't a better clue about network cards either
17:01HdkR: Intel usually works pretty well
17:01karolherbst: and it has PXE support
17:01HdkR: Which is a good thing to support
17:02HdkR: I'll double check which one is in my threadripper system and specifically avoid that one
17:03HdkR: Since sometimes it never comes back up from sleep
17:03HdkR: Some random Intel one
17:04karolherbst: TP-LINK TG-3468 maybe?
17:04karolherbst: that would be cheaper
17:05HdkR: eh. I'd trust Intel over TP-Link
17:05karolherbst: yeah, but 12 vs 30€ :D
17:05karolherbst: can't do PXE anyway
17:06karolherbst: "Netis AD1103 PCIe network card 10/100/1000" mhh
17:06karolherbst: the good thing about non intel cards is, that they don't come with that crappy management stuff :p
17:07HdkR: hah :D
17:07karolherbst: that netis card is also super small
17:07karolherbst: the intel card is way too big for doing just ethernet :p
17:08imirkin_: check out 3c509's...
17:08imirkin_: oh actually they're smaller than i remember. hm.
17:08karolherbst: ohh 3com
17:08karolherbst: they have pcie cards? :D
17:08karolherbst: seems pci only
17:08karolherbst: or at most pci
17:09HdkR: yum, ISA cards
17:09karolherbst: ohh.. I have to check linux driver support as well
17:12HdkR: Guess Intel is nice in that regard. Plop it in and it'll mostly just work
17:13karolherbst: netis has propritary drivers.. uff
17:13karolherbst: intel it is then
17:14karolherbst: now a switch
17:15imirkin_: 3c509 were ISA/EISA
17:15HdkR: I usually use Netgear Prosafe switches around my apartment there
17:15imirkin_: 3c905 were PCI
17:15imirkin_: and for a long time were the gold standard of network cards
17:15Pie_Mage: i actually just pitched a 3c905 like a month ago
17:15imirkin_: Pie_Mage: i think i still have mine sitting around somewhere ... 3c905*b*, since the c versions were no good. heh.
17:15Pie_Mage: was actually not bad for running a router
17:16imirkin_: (why do i remember shit like that. totally useless knowledge.)
17:17HdkR: karolherbst: https://www.amazon.com/NETGEAR-Ethernet-Unmanaged-Protection-JGS524NA/dp/B0002CWPW2 ? :D
17:17HdkR: Has full switching throughput
17:18HdkR: Rocksteady for me
17:21karolherbst: HdkR: Netgear ProSAFE GS100 Desktop Gigabit Smart Switch, 8x RJ-45, PoE PD, V2 (GS108T-200)
17:22karolherbst: ohh wait, that's wrong
17:22karolherbst: HdkR: Netgear SOHO GS300 Desktop Gigabit Switch, 8x RJ-45, PoE (GS308P-100)
17:23HdkR: ah, one of the lower end ones
17:24karolherbst: HdkR: actually, I need this: Netgear S350 Desktop Gigabit Smart Managed Switch, 8x RJ-45, 2x SFP, PoE+ (GS310TP-100)
17:24karolherbst: I need 10W per PoE for 2 tegras
17:24karolherbst: well, 10W per tegra
17:24karolherbst: and if I connect two, that's 20W
17:24karolherbst: and PoE for proper on/off through the controller
17:26HdkR: Oh, tegra supports poe?
17:27karolherbst: so.. 8 poe slots, should be enough
17:27karolherbst: will be 160€ in total for me :D
17:27karolherbst: switch + ethernet card
17:28karolherbst: the switch is the more expensive part obvisouly
17:28HdkR: Yea, it's a decent swtich
17:40karolherbst: ordered :)
17:52njsg: nv doesn't show a mode with "i" at the end, but it shows two 1024x768 modes, and I guess the one with the 43.00 rate is the interlaced one. I'll compare xrandr outputs when I reboot (so that I can run with nouveau)
17:52imirkin_: njsg: i think the "i" is just labelling
17:52imirkin_: you can get the full modeline from the xorg logs
17:53imirkin_: and/or xrandr --verbose
17:54njsg: now, on one hand, the screen is much more normal with the 43.00 one in nv, but the first few columns at the left are at the right, if you get what I mean...
17:54njsg: uh, interesting, the cursor is not affected, hardware cursor, I guess
17:54imirkin_: well, -nv probably has bugs too
17:54njsg: which probably means it will click in the wrong place
17:55njsg: I didn't see "interlace" in xrandr --verbose, is this expected?
17:55imirkin_: might just be a 43hz mode...
17:55njsg: the logs speak about a default 1024x768i mode not being used, but says that also about 1024x768
17:55imirkin_: or maybe i just don't know how interlaced modes are displayed
17:56imirkin_: pastebin the output of xrandr --verbose?
17:56njsg: Better to compare the outputs, I also think xrandr is listing more modes than with nouveau
17:56imirkin_: "flags can be zero or more of +HSync, -HSync, +VSync, -VSync, Interlace, DoubleScan, CSync, +CSync, -CSync"
17:56imirkin_: so it should be showing up somewhere
17:58imirkin_: note that there's a *minimum* clk speed too, perhaps the interlaced mode is too slow?
17:58njsg: I don't think I see flags in --verbose
17:58imirkin_: pastebin the output?
17:58njsg: I know I saw them with nouveau...
17:59imirkin_: the -nv code could just be buggy too
17:59imirkin_: it may not have kept up with some interface change
17:59imirkin_: or it could have been broken from the start
18:01njsg: xrandr --verbose with nv: http://dpaste.com/0EQ773M.txt
18:01imirkin_: you weren't kidding
18:01imirkin_: start 0 end 0
18:01imirkin_: that just means it's not filling in the proper values =/
18:02imirkin_: xorg log may be more verbose
18:23njsg: and here's the xorg log: http://dpaste.com/10DQ8BK.txt
18:24imirkin_: i like the edid.
18:24imirkin_: ok, so it has this: Modeline "1024x768i"x0.0 44.90 1024 1032 1208 1264 768 768 772 817 interlace +hsync +vsync (35.5 kHz e)
18:24imirkin_: Clock range: 12.00 to 400.00 MHz - so you're fine
18:25imirkin_: and in the end, you do have:
18:25imirkin_: [ 1515.279] (II) NV(0): Modeline "1024x768i"x43.5 44.90 1024 1032 1208 1264 768 768 772 817 interlace +hsync +vsync (35.5 kHz ez)
18:25imirkin_: so yeah, that 43 or 44mhz mode is in fact interlaced
18:25imirkin_: it's just not shown that way in xrandr
18:25imirkin_: (where does it get 43.5 when the mode is clearly 44.9? no clue whatsoever)
18:26imirkin_: oh, 43.5hz refresh
18:26imirkin_: 44.9mhz ramdac
18:28njsg: I seem to get a consistent result that the first few columns from the left are always shown at the right if I choose that mode.
18:28imirkin_: so the 43hz mode should be the interlaced one
18:28imirkin_: however in the xrandr output, it appears that the 60hz one is selected
18:28imirkin_: ok, well that's probably fixable - some silly timing thing
18:28imirkin_: but it does "work", right?
18:28imirkin_: you get a picture
18:28imirkin_: the picture roughly approximates what should be on the screen
18:29imirkin_: and you get the interlacing artifacts you so desperately wanted
18:30njsg: while it still has an issue, it is working better than nouveau
18:30imirkin_: are you a developer?
18:31imirkin_: (i.e. someone who can read and understand code, maybe even write some)
18:31njsg: In *this* context, no, I think I never touched video drivers.
18:31imirkin_: which context is "this"?
18:31njsg: nouveau and nv :-)
18:31imirkin_: that's true of everyone until they have, right
18:32njsg: but I can work with code
18:32imirkin_: ok, well, here's the -nv code: https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/
18:32imirkin_: and here's the nouveau code: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/dispnv04
18:33imirkin_: i'd grep around for "interlace" and figure out what the diff is
18:33njsg: the cursor problem can probably be worked around by disabling the hardware cursor
18:33imirkin_: ignore all the g80_* and riva_* files in the -nv codebase
18:33njsg: but now I wonder if the input is that good, it looks like there's wider gaps between lines in the interlaced output
18:33pqatsi: karolherbst: After some test, I noticed the following result: https://paste.fedoraproject.org/paste/eX6PufPSXDvyw6RBQZBBkA (TL;DR: Intel with vblank_mode=0 did ~500fps fullscreen with composition but nvidia did ~60fps with a kernel warning)
18:34karolherbst: that pmu issue will happen any time the GPU gets resumed
18:34karolherbst: it doesn't seem to be critical though
18:34njsg: like thin gray lines in a reverse video line in a terminal emulator, it is not visible if I choose the non-interlaced mode
18:35njsg: or could that be an expected side effect of interlacing?
18:35imirkin_: njsg: might i ask why you so want the interlaced mode?
18:35imirkin_: no - interlacing should only cause tearing
18:35imirkin_: between the even/odd fields
18:35njsg: I was hoping it'd have less flickering
18:36imirkin_: are you on a CRT?
18:36imirkin_: the higher the refresh rate, the less flickering
18:36imirkin_: i could see flickering at anything below 75hz ... i was pretty happy with 85hz
18:37imirkin_: it's different for different people though
18:37pqatsi: karolherbst: ah, ok. But this performance was expected too?
18:38karolherbst: glxgears isn't a benchmark ;) but you can also just disbale vsync
18:38imirkin_: pqatsi: 60fps really feels like you're beign limited by refresh rate
18:38karolherbst: vblank_mode=1 I think
18:38karolherbst: you need to use
18:38imirkin_: =0 should be enough
18:38imirkin_: but the compositor might ignore you
18:38karolherbst: it's not
18:39njsg: imirkin_: I can notice less flickering with the interlaced mode in nv, so at least that part seems to be working :-D
18:39imirkin_: njsg: ah ok. it also really depends on the monitor itself.
18:39karolherbst: anyway, prime offloading + vblank_mode=0 == broken
18:39imirkin_: IME the flickering becomes a lot more obvious if you look stragith at the monitor, and then without moving your head, look up
18:39karolherbst: causes Asynchronous wait on fence errors
18:40karolherbst: or other weird things.. something is broken there
18:40karolherbst: no idea what
18:40karolherbst: pqatsi: vblank_mode=1 should be way better
18:40pqatsi: imirkin_: You maybe right, how can I override it? Ive tested also with glmark2: https://paste.fedoraproject.org/paste/vw9WaMVj9vARdOVvOeX1FA
18:41imirkin_: pqatsi: listen to karolherbst. he has a ton more experience than i do with all this offloading BS
18:41njsg: After dinner I'll boot with modesetting and get the logs for X11 with nouveau.
18:41karolherbst: chances are that with nouveau your GPU will still be slower, sadly
18:41karolherbst: also, you are limited by the PCIe bandwidth
18:41karolherbst: which is limited to 1.0 speeds anyway
18:41karolherbst: right now
18:41pqatsi: imirkin_ karolherbst Didnt work well: https://paste.fedoraproject.org/paste/V6XEekh3kKNHb9MR~wlT0A
18:42pqatsi: karolherbst: Ah, where can I check the PCIe bandwidth?
18:42karolherbst: lspci -s 01:00.0 -vv
18:43pqatsi: karolherbst: I in fact not worried too much, since you kernel does not crashes anymore my machine :D But I want to help you to fix things if possible, at least as a tester
18:43karolherbst: mhh, I get "FPS: 51 FrameTime: 19.608 ms" uff
18:43karolherbst: but that's with 100% cpu load anyway :D
18:44karolherbst: I get 83 fps with intel
18:44karolherbst: I blame the cpu
18:44pqatsi: karolherbst: but why mesa did ~900fps on bench so ?
18:45karolherbst: no clue
18:45karolherbst: something wrong on your end?
18:45pqatsi: Maybe something about buffer copy from nvidia to intel?
18:45karolherbst: I get 112 fps
18:45karolherbst: with intel now
18:45karolherbst: ohhh wait
18:45karolherbst: that's with 4k
18:46pqatsi: My res is 1920x1080 indeed
18:46karolherbst: getting 50 fps with nouveau under 4k
18:46pqatsi: LnkSta: Speed 2.5GT/s (downgraded), Width x4 (ok) / LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- <-- This is the bus speed actually in usage?
18:46karolherbst: x4 width?
18:47karolherbst: is that an eGPU case?
18:47pqatsi: karolherbst: Its a Dell Notebook
18:47karolherbst: what's wrong with your laptop...
18:47karolherbst: that's... harsh
18:47karolherbst: I saw x8 in laptops
18:47pqatsi: With integrated intel and nvidia
18:47karolherbst: never x4
18:47pqatsi: o.0 Maybe some bios weirdness?
18:47karolherbst: x16 is pretty normal even in laptops
18:47karolherbst: maybe... your GPU supports changing width though
18:47imirkin_: or maybe we're supposed to upgrade the lane count but don't?
18:48karolherbst: might be
18:48pqatsi: This is a controllable kernel flag?
18:48karolherbst: pqatsi: mind checking with the nvidia driver?
18:48karolherbst: nvidia should pump it up to 8.0
18:48karolherbst: but it would be interesting to see what lane count they use
18:48pqatsi: karolherbst: I can install it again or run a Windows instance I have here
18:48pqatsi: My windows does have nvidia proprietary drivers
18:48karolherbst: I'd prefer to do it with linux
18:48karolherbst: you could give us an mmiotrace as well
18:49karolherbst: and then we could take a look in how to implement it _if_ nvidia changes the lane count
18:49karolherbst: increasing the speed is no biggie and we could actually do it on pascal. Lane count is what is annoying
18:49karolherbst: I used to look into it, but... GPUs just crashed
18:49karolherbst: so we never implemented it
18:50pqatsi: karolherbst: So let-me check the steps: First mmiotrace (As https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt ? ), after install nvidia proprietary and check bus again
18:50karolherbst: ohh, no, just check with nvidia for now
18:50karolherbst: and with lspci
18:50karolherbst: if nvidia changes the lanes, then you could create an mmiotrace
18:51karolherbst: but if they don't there is no need
18:51pqatsi: installing nvidia here, hold a bit
20:19karolherbst: imirkin_: ohh, btw, do you know why some values can end up with multiple defs all pointing to different values actually?
20:20karolherbst: that's more or less what's happening with that RA issue
20:20imirkin_: karolherbst: yeah, we merge nodes
20:20karolherbst: ohh, to assign the same register, right?
20:20imirkin_: or same group of regs, yea
20:21imirkin_: e.g. you have a phi node
20:21karolherbst: ahh, right
20:21imirkin_: which "merges" 2 values
20:21karolherbst: but maybe we have to postpone that stuff somehow
20:21karolherbst: it's weird to group them, but then leave them in ssa form
20:21karolherbst: and then we "remove" an instruction to spill the value, but then everything goes south
20:21karolherbst: because now one of the def points to invalid memory
20:22imirkin_: the remove is a fail
20:22imirkin_: i tried to fix it
20:22imirkin_: but failed almost as much as it was a fail
20:22imirkin_: i had some patches
20:22karolherbst: I don't think the remove is the issue though
20:22imirkin_: but they broke everything
20:22imirkin_: not the remove itself
20:22karolherbst: the issue is, that we group without converting to a register
20:22imirkin_: let me see if they're somewhere...
20:22karolherbst: or at least that would be _way_ saner to guarentee that
20:23karolherbst: or ungroup if we don't convert
20:23karolherbst: everything else sounds like calling for trouble
20:24imirkin_: look at the hunk in nv50_ir.cpp for this commit - https://github.com/imirkin/mesa/commit/0eddaaea62d8ef150720e87cb8d2ad2f4e4095bf
20:24imirkin_: i think it may have been related
20:24karolherbst: I think we have to add some layer between the IR and RA so that we can throw everything away, so our shader is still sane, but we can undo everything essentailly
20:24imirkin_: and maybe the nv50_ir_ra if i didn't already push it
20:24imirkin_: if this is already the current code, then there was more
20:24karolherbst: ahh, I remember this
20:24karolherbst: but this doesn't address the issue at all
20:25karolherbst: the core issue is that the corrupt the entire state of the function
20:25karolherbst: well, not entire
20:25karolherbst: but certain values now have unrelated defs, as we redo RA essentially
20:26karolherbst: I'd rather focusing on makeing the entire process saner than it's currently is
20:26imirkin_: yeah, it's not great.
20:27imirkin_: maybe there's a reasonable way to do this
20:27imirkin_: by dumping the info into the RIG_Node
20:27imirkin_: and not touching the LValue's
20:27karolherbst: or some new struct or something
20:27karolherbst: something we can just delete without messing anything up
20:27imirkin_: i'm going by memory anyways :)
20:28imirkin_: fwiw i'm totally good with making the current process slightly slower (e.g. more copying) in exchange for fixing this issue
20:28karolherbst: I mean, spilling values is still fine as long as everything is in a sane SSA form
20:28karolherbst: so we could still do multiple rounds
20:29karolherbst: imirkin_: I was also thinking about adding a codegen_validate thing and try to have a more well defined IR overall... maybe it even makes sense to do both at once as fixing RA will probably be a side effect of this anyway
20:32imirkin_: good luck.
20:32imirkin_: i mean, i'm all for it
20:32imirkin_: but ... good luck.
20:32imirkin_: we get away with a LOT of BS
20:36karolherbst: although.. we could probably add a workaround, which could address this RA issue in a non breaking way
21:34captain-tux: Hi all, I just joined in. Does anybody know why my new GT 730 could be so sluggish? (Debian 10)
21:36imirkin_: can you be more specific? what's sluggish?
21:39captain-tux: Hey imirkin_, well, it basically runs worse that my old 550 Ti did, even though it should have more "raw performance" number-wise. I have two displays and as soon as I attach the second one, desktop animations become a bit laggy and video output is choppy. Didn't get that before.
21:40imirkin_: pastebin xorg log
21:40imirkin_: also try increasing the gpu clocks
21:40imirkin_: GT 730 is a very weak card - i doubt it's more powerful than the 550 Ti
21:41imirkin_: anyways, cat /sys/kernel/debug/dri/0/pstate
21:41imirkin_: should give you a few options
21:41imirkin_: echo'ing those options back into the file should change the power state
21:41imirkin_: (probably called like "07" and "0f" for that particular board)
21:42captain-tux: Ah okay, thanks. I
21:42njsg: before I reboot with modesetting enabled, is there any other piece of useful debug information I could/should get from nv in X11?
21:43imirkin_: njsg: nope - i mostly wanted to see if it worked at all with the -nv code
21:43imirkin_: (if it didn't, chances of it working with nouveau were considerably decreased)
21:43captain-tux: *I'll try that. I have to switch back to my other machine and get the logs next time. Thanks again!
21:44imirkin_: captain-tux: also - is this a GF108 by any chance? i think they stopped playing those games after the GT 630, but at least that GPU came in a bunch of different versions
21:44imirkin_: or is it a GK208?
21:45njsg: both drivers can give output that can be read, but has problems. the -nv one is more readable.
21:46njsg: Oh, is there any test pattern/image which could be used to demonstrate the issue?
21:46imirkin_: sorry, dunno
21:46captain-tux: imirkin_: According to Wikipedia, it's the GK208-400-A1, it appears that's the only one with DDR5 memory and it says that on the card.
21:46imirkin_: captain-tux: ah yeah, if it's DDR5, it's probably a GK208.
21:47njsg:goes actually take a screenshot of the interlaced mode. Hopefully the screenshot won't have any issue itself...
21:47imirkin_: anyways, those are all shit GPUs, but with reclocking the DDR5 should actually make things fairly snappy i'd imagine
21:47imirkin_: i've only ever used DDR3 GK208's
21:47imirkin_: (i tend to just have whatever comes for free in dell's and can be thrown out)
21:48imirkin_: njsg: yeah, screenshot is all software. you could take a photo, but photos of crt's are tricky
21:49njsg: yeah, I was just trying to make sure it's gremlin-free
21:49captain-tux: Well, thanks... :D Yes, I don't play on this machine and just use it for the displays and playing/editiong videos, but I expected it to at least do that without issue. ;)
21:50imirkin_: yeah, should work fine
21:50imirkin_: i use a GK208 with 2x 1920x1200 monitors without issue
21:53captain-tux: Okay, that's reassuring. I'll head over and try to play around with those settings. Thanks again, that's a start at the very least!
21:56imirkin_: i keep mine on the lowest perf setting too
21:56imirkin_: but i don't use graphical animations frequently, dunno
21:59karolherbst: imirkin_: https://github.com/karolherbst/mesa/commit/a4d6020964c6aec749db3e9de210a5a282d1c815 uff
22:00karolherbst: this fixes the crash
22:00karolherbst: but.. uff
22:02imirkin_: make sure you print the instructions after you do that
22:02imirkin_: make sure it's the same as the original
22:02karolherbst: you mean the one which gets deleted?
22:02imirkin_: + spilled ops
22:02imirkin_: i just mean the whole program
22:02karolherbst: ohh, it's totally unrelated stuff
22:02karolherbst: wait, I can print it
22:02imirkin_: is it unrelated? dunno
22:02imirkin_: if it is, whatever
22:05karolherbst: how often does that happen
22:06karolherbst: but it does seem that it's always a phi
22:07karolherbst: I've added a print everytime erase on the list gets called: https://gist.githubusercontent.com/karolherbst/824524eb70ed54b163cca39b9f95e9b9/raw/dadab473a89cfdacdc3a8059a82a30aa7f65f4fa/gistfile1.txt
22:07karolherbst: that's... a lot
22:07imirkin_: i meant like after the whole run
22:08imirkin_: (and before)
22:08njsg: How'd I get the current framebuffer console video mode?
22:08imirkin_: njsg: huh?
22:08karolherbst: imirkin_: what should change?
22:08imirkin_: karolherbst: nothing
22:08imirkin_: karolherbst: if something changes, you did something wrong :)
22:08karolherbst: so what's the point of printing? or do you mean to check for errors
22:08karolherbst: I see
22:08njsg: I had to force 800x600 to get something usable, and it'd be good to know which mode was being used
22:09imirkin_: on the console? fbset -i or something like that...
22:09imirkin_: or perhaps fbset -s
22:09imirkin_: the fbdev video mode info should also be printed in dmesg - search for nouveaufb
22:10imirkin_: or nouveaudrmfb
22:10imirkin_: it recently got changed
22:12njsg: it does say 1024x768, I guess it must have been the interlaced one
22:14imirkin_: forcing 800x600 should work ... iirc just do video=800x600 should be enough
22:15njsg: I did video=VGA-1:800x600
22:16karolherbst: imirkin_: everything seems fine. The only difference seems to be the inserted spills
22:16imirkin_: njsg: yeah that should work
22:16imirkin_: karolherbst: cool
22:16karolherbst: I really on't like this "fix" though :D feels to much of a dirty workaround
22:17karolherbst: but well.. it fixes the crash
22:18karolherbst: I am now actually surprised that this crash doesn't happen more often with how many of those references there are :(
22:18karolherbst: but maybe it's fine
22:43njsg: Ah, and xrandr --verbose with nouveau: http://dpaste.com/3T8ZMK4.txt
22:43imirkin_: ok, so that 1024x768ihas a big problem
22:43imirkin_: clock 86.96Hz
22:43imirkin_: something forgot to divide by 2
22:44imirkin_: mind pastebin xorg log?
22:44imirkin_: want to see if it's some dumb xrandr thing, or if it's for realz
22:48imirkin_: njsg: --^
22:51njsg: I'll pastebin in a moment
22:55njsg: imirkin_: http://dpaste.com/2PXSBD2.txt Xorg log for nouveau
22:55njsg: it seems to have 43.5Hz for that mode at least in some lines?
22:56imirkin_: yeah, looks like just an xrandr artifact
22:56imirkin_: i'll look into that
22:56imirkin_: could you boot with drm.debug=0x1e
22:56imirkin_: that should dump a lot of info into dmesg about modes,e tc
22:57njsg: if it's an xrandr artifact, and I'm changing modes with xrandr, would it use the incorrect value?
22:57imirkin_: that's why i want you to boot with drm.debug=0x1e
22:58imirkin_: Output VGA-1: Strange aspect ratio (1/257), consider adding a quirk
22:58imirkin_: wonder what that is
22:58imirkin_: never seen that before
22:59njsg: Actually, I saw one or two of these messages before, not four, so these ones seemed to be triggered by a specific event, let me see if I can figure what was it.
23:00njsg: hm, no, I'm probably mistaken and I was just looking at the Xorg log.
23:03njsg: There is still something that was triggered after X started, see http://dpaste.com/275FPXG.txt
23:05njsg: imirkin_: I'll give the debug option a try
23:11njsg: (is the x0.0 normal/expected, btw?)
23:11imirkin_: dunno, but i definitely see it a lot
23:13imirkin_: njsg: btw, i bet this monitor can do 1152x864
23:13njsg: I should try to get the manual, I really have no idea what the specs are.
23:14imirkin_: btw, this is what edid-decode parses the edid as:
23:14imirkin_: noet the 1280x768i resolution. weird. and i think its vertical refresh is also not-divided...
23:15imirkin_: interlaced modes aren't too common :)
23:15imirkin_: and that's where the 1/257 stuff is coming from - check out those "detailed" modes
23:16njsg: I see this has the same quirk message. Different display brand (Nokia, it seems), but at least some modes are the same (including 1024x768i): https://www.centos.org/forums/viewtopic.php?t=50927
23:17imirkin_: feels like edid-decode may have a buggy mode list, since that 1280x768i seems VERY weird
23:18imirkin_: yeah, no way that's right
23:18imirkin_: probably a typo
23:18imirkin_: should check with ville...
23:19njsg: I thought you meant 1024, but no, it really says 1280
23:19imirkin_: the 87 may be right though
23:20imirkin_: and it could be the 43.5 that was wrong :)
23:20imirkin_: yeah, according to wikipedia it's 1024×768 @ 87 Hz, interlaced (1024×768i)
23:22njsg: That would be 87 fields per second, right?
23:22imirkin_: aggregate of 43.5
23:34karolherbst: imirkin_: sent the patch out
23:34karolherbst: I hope the libasan report is a bit helpful
23:40njsg: The manual (at least I think it is this one): https://www.manualslib.com/manual/145641/Samsung-Syncmaster-3.html?page=15#manual
23:42imirkin_: njsg: yeah, i'm sure that's right
23:42imirkin_: it's a standard mode
23:42imirkin_: # 1024x768i @ 43Hz (industry standard) hsync: 35.5kHz
23:42imirkin_: ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync Interlace
23:42imirkin_: from xorg's "vesamodes" file
23:43imirkin_: so i guess it's the xorg convention to list the "effective" refresh rate
23:58njsg: imirkin_: what should I grep the kernel log for, "drm:"?
23:58imirkin_: just pastebin the whole thing
23:58imirkin_: it'll be easier that way
23:59imirkin_: make sure you include switching to the 1024x768i mode