02:55airlied[d]: and so begins my effort to start nouveau support on dgx spark
02:56HdkR: \o/
03:02airlied[d]: oh this might need newer fw, fun times 😛
03:22karolherbst[d]: wait.. GSP is already 72MB big? impressive
03:26redsheep[d]: The GSP prefers you phrase it as 72 MB thin
03:39airlied: TimurTabi: btw the extractor script in openrm is broken on 580
04:20airlied[d]: sec2 making a reappearance in the boot seq
07:31linkmauve: Oh, I just got access to a dgx and an agx boards. ^^
07:37airlied[d]: okay write a bunch of the code, but hopefully can trick it into booting gsp tomorrow
07:38airlied: ^write^wrote for irc :)
07:38notthatclippy[d]: For what it's worth, GSP is expected to get a lot slimmer in the coming months, at least as far as upstream drivers are concerned.
07:42notthatclippy[d]: Right now we ship a lot of embedded ucodes that no one outside if NV has any use for, but they're not easy to split. The *fun* bit is that that portion of dead .data then gets converted to heap, so simply removing it ends up causing OOM. Fun.
10:10mohamexiety[d]: airlied[d]: I got one as well to help with this but been occupied with some nvk stuff. But yeah iirc the first references to GB20B in openrm were in 580
12:07Siggi: mhenning[d]: thanks, I'll give it a try
14:35Siggi: mkay, this morning I went back to kernel 6.17 and nouveau on my 21.5" iMac mid-2011 with the K2100M card.
14:35Siggi: I futzed around with pstates, didn't help
14:36Siggi: I switched resolutions, didn't help
14:37Siggi: but what did help was what karolherbst suggested, adding nouveau.config=NvForcePost=1 to the boot flags
14:37karolherbst: okay.. maybe we don't properly detect whether the card needs to be posted then..
14:37karolherbst: there is a function for it..
14:39Siggi: n00b question: what does Post mean in this context? Not power-on-self-test?
14:41karolherbst: Siggi: gf100_devinit_preinit
14:41karolherbst: base->post = ((nvkm_rd32(device, 0x2240c) & BIT(1)) == 0);
14:41karolherbst: Siggi: yes
14:41karolherbst: it's the BIOS POST thing
14:41karolherbst: so normally the BIOS reads out the VBIOS and executes a binary to POST the GPU
14:41karolherbst: and this gets communicated to the OS whether that has been done or not
14:42karolherbst: and normally it's not considered safe to do that also on the OS level if the BIOS already done it
14:43karolherbst[d]: skeggsb9778: you might have any ideas on what could go wrong there? ^^
14:51Siggi: Interesting. These old iMacs have a notoriously quirky BIOS from what I understand. Maybe this is an iMac quirk, ... though there was someone else who reported similar problems on a non-Mac above
14:56karolherbst: ohhh.. yeah that might explain it...
14:56karolherbst: but the detection is also reverse engineered, it might be that ours isn't perfect..
14:56karolherbst: or something weird going on...
15:03Siggi: f_: you reported artifacting on a K2000 on a HP elitebook of some description. Maybe you can adding adding nouveau.config=NvForcePost=1
15:05karolherbst: I _wonder_ if the issue isn't a bad POST, but rather a bad modesetting? Did you check if changing resolutions or replugging the display makes any difference?
15:06Siggi: karolherbst: I messed around with the resolutions and orientation, no change
15:06Siggi: this is eDP, so can't unplug it without disassembly :)
15:06karolherbst: ahh...
15:06karolherbst: your eDP comes with resolutions? 🙃
15:06karolherbst: I wonder if it's just scaling
15:06Siggi: actually f_: reported his external monitor is fine
15:07Siggi: hehe, no resolutions, just scaling
15:07karolherbst: mhh I don't know how to force a modeset on the eDP display...
15:07Siggi: at least according to the EDID info
15:08karolherbst: yeah.. it sounds like something the compositor might just be doing... or add custom modes? that might work as well
15:08karolherbst: but eDP is funky in that regards
15:11f_: karolherbst: my eDP can change resolutions for sure
15:22Siggi: f_: I get a selection of resolutions in the display control panel, but I don't think this changes the LCD panel's resolution
15:23f_: https://ircb.dersco.re/uploads/funderscore/3ea855da-f_-paste.txt
15:24f_: `Enabled: no` because I have two external monitors connected at the moment and it doesn't really like triple screen so it's in clamshell mode for now
15:24Siggi: another n00b question: something initializes the display at boot time, as I can get to the EFI boot menu and such
15:25f_: Siggi: yes, the bios/uefi does that
15:25Siggi: is that perhaps just some kind of VGA compat?
15:25f_: it would run the VBIOS on boot
15:26f_: which inits your gpu and such etc
15:26f_: (on a high level)
15:29Siggi: f_: how are you getting the info in the paste?
15:29Siggi: when I parse the EDID from my panel (xrandr --verbose), I get only the native resolution of the panel
15:30Siggi: but xrandr reports a bunch of available resolutions
16:17karolherbst: userspace is free to add custom resolutions
16:17Siggi: so the nvbios is parsed, I see. Interesting. Is there a quick and painless way to extract the firmware blobs from a rom file?
16:18karolherbst: it's part of the vbios
16:18karolherbst: but it's mostly just a vbios parser 🙃
16:19Siggi: so I pulled the image from the card with nvflash
16:19karolherbst: so the BIOS doens't know how to init a GPU, so it executes code from the vbios, which then itself is a vbios parser to parse out a script to execute
16:19Siggi: and re-flashed it
16:20Siggi: I'm curious to disassemble some of this, but how do I extract the vbios routines from a flasrom image?
16:21Siggi: (I've been on a bit of a Ghidra tear for a ... while ... https://github.com/sigurasg/GhidraMC6800)
16:22Siggi: (might look into writing a language spec for the vbios, assuming there's any point)
16:24f_: Siggi: wlr-randr
16:25f_: Siggi: I think there's a vbios copy in sysfs?
16:28Siggi: f_: where do I find wlr-randr? any links?
16:28f_: wlr-randr is just xrandr but wayland
16:29f_: let me actually check my edid
16:30f_: Siggi: karolherbst: it seems my display's EDID says only 1920x1080, either in 60Hz, 50Hz or 48Hz
16:31karolherbst: well changing the refresh rate would cause a modeset for sure
16:32f_: Siggi: so you say adding nouveau.config=NvForcePost=1 would stop the flickering?
16:32f_: Probably worth noting that your GPU is Kepler, mine is Fermi
16:35f_: apart from Kepler obviously being better than Fermi feature-wise, I'm not sure what differs
16:35Siggi: f_: it did for me
16:36Siggi: DTD 1: 1920x1080 59.933878 Hz 16:9 66.587 kHz 138.500000 MHz (475 mm x 267 mm)
16:36Siggi: Hfront 48 Hsync 32 Hback 80 Hpol P
16:36Siggi: Vfront 3 Vsync 5 Vback 23 Vpol N
16:36Siggi: DTD 2: 960x540 59.818217 Hz 16:9 33.259 kHz 37.250000 MHz (475 mm x 267 mm)
16:36Siggi: Hfront 48 Hsync 32 Hback 80 Hpol P
16:36Siggi: Vfront 3 Vsync 5 Vback 8 Vpol N
16:36Siggi: Looks like these are the EDID modes my panel offers
16:36Siggi: I guess I can try to toggle between these two, see whether the artifacts clean up
16:37f_: let me pull out my laptop and check
16:42f_: seems the flickering is gone by changing the refresh rate to 48hz
16:42f_: or at least happens less frequently maybe
16:44Siggi: and if you toggle back?
16:44f_: comes back again
16:44Siggi: K
16:44Siggi: interesting
16:44Siggi: then presumably this isn't "just" a modesetting problem
16:45Siggi: did you try the NvForcePost thang?
16:45f_: no
16:45Siggi: k
16:46Siggi: so I guess a thing I can do is to .... mmmm
16:46Siggi: figure out how to compare mmiotraces between forcing post and not
16:47Siggi: although if this is some residual state from reset/boot time, I guess I'd need to read back the register contents, see what's up
16:47f_: tbh haven't really looked much into the flickering myself because it not all that noticeable, it takes the whole screen with it from time to time but it's rare
16:48Siggi: it's really bad on the iMac
16:48f_: Siggi: uptime here is 4 days
16:48Siggi: heh :)
16:48f_: Siggi: hmm, how bad exactly?
16:48f_: for me it's a huge line only at the top-left corner, sometimes the whole display flickers but as I said it's very, very rare
16:49Siggi: I guess I can capture a video, but there's persistent striping at the right-hand edge of the panel
16:49Siggi: and occasionally the whole panel tears, I'm guessing this is when the underrun kills a while line
16:49mhenning[d]: karolherbst: Is the bios post detection the kind of thing that might still appear in openrm?
16:49Siggi: (assuming it's underrun)
16:50f_: and for the record this happens everywhere - not just wayland but also the fbcon
16:51Siggi: I'm on mint, no wayland
16:51Siggi: though I can try it
16:51f_: I wouldn't be surprised if it happens on x11 for you
16:51Siggi: fbcon I haven't tested
16:51f_: just saying this is not wayland/x11-specific
16:51Siggi: I'll try a wayland session
16:52f_: fbcon is the tty (typically)
16:52Siggi: Cinnamon is not wayland friendly yet, alas
16:53f_: what I'm saying is it isn't something specific to a compositor or desktop environment
16:53f_: it happens literally everywhere I go, wayland, x11, fbcon, everywhere :P
16:54Siggi: ah, gotcha
16:55Siggi: yeah, that sounds like what I see
16:55f_: I like the nouveau folks, but sometimes I wish this laptop had working intel integrated GPU :P
16:56f_: (but I like that my gpu works at all for light desktop use)
16:56Siggi: heh, out of curiosity, your panel isn't flipped?
16:56f_: Siggi: I have no idea
16:57f_: at least to the OS it doesn't look like it, but no idea if there's some rectifying thing going on as is the case on some phones and tablets that have a flipped display panel
16:57Siggi: eDP connected primary 1920x1200+0+0 (0x5b) normal (normal left inverted right x axis y axis) 302mm x 188mm
16:57Siggi: this is what I see in xrandr --verbose
16:58f_: i can try flipping it though
16:58Siggi: I assume it'd have !normal if the panel is flipped
16:58Siggi: well, I'm thinking this has to do with the physical panel and how it's refreshed
16:59Siggi: I tried all 4 orientations with mine, didn't make any difference
16:59Siggi: as (I speculate) it's scanned the same way by the hardware
16:59f_: no diff here either
17:00f_: this is an original panel that has never been replaced (if that's what you mean)
17:00karolherbst[d]: mhenning[d]: nah, it's GSP doing it for us now afaik
17:00karolherbst[d]: I think...
17:01karolherbst[d]: I think with GSP with boot it up and then wait on the boot to complete and that's it then
17:03f_: btw, on another topic, I've been told way before that nvk wasn't coming to fermi, then I've been told that it might come to the fermi
17:03f_: but fermi doesn't support vulkan does it=
17:04karolherbst: depends on how much...
17:04karolherbst: not sure it's practically doable, but might be doable enough to let zink run on top?
17:04f_: ¯\_(ツ)_/¯
17:07Siggi: so, since I can provoke both states with nouveau, I should be able to diff mmiotraces between the two
17:07f_: (I'm not asking because I specifically want nvk as soon as possible btw, just wondering about the future of Fermi support)
17:07Siggi: although how do I prevent loading nouveau at boot, so that ... maybe it doesn't matter
17:07karolherbst: the issue with fermi support is that it's gonna be slow either way
17:08f_: thought of that :P
17:09f_: probably have said it before but I find it impressive that it is actually kinda working at all
17:14f_: slow because can't do reclocking, right?
17:21karolherbst: yeah
17:23f_: shame (on nvidia)
17:25f_: now that I'm around here also, thought I'd ask: it seems the card gets a little unstable when I'm messing with monitors. It doesn't like 3 monitors for sure, but when trying to turn off the internal one to turn on the DP one (1440p) I actually have to do this multiple times, or wait a bit from the point I turn off the internal eDP and when I turn on the external DP
17:25f_: VGA is always there
17:26f_: but if I do this too quickly it ends up just turning off the internal eDP and that's all
17:28f_: it's especially an issue when trying to use kanchi to manage monitors since it does everything instantly in one go, so everything breaks and I have to fix it :P
17:28f_: (and there are no plans for kanshi to introduce a delay between operations..)
18:49jja2000[d]: airlied[d]: If you end up doing anything that would improve things on other Tegra SoCs please let me know. I can test for T210 and T186. If I forward it to Aaron Kling he can test on T194 and T186.
18:49jja2000[d]: (also slight necropost, my bad)
18:52jja2000[d]: (Aaron did leave the discord over the name change of the server unfortunately, but he's not stopping the contribution/testing)
18:56f_: name change?
18:56jja2000[d]: On the discord end yes
18:56f_: here it's still "nouveau", did the purpose of this channel change?
18:57f_: s/purpose/topic/
18:59jja2000[d]: It did not, but the discord __server__ changed from Freedesktop to Queerdesktop
19:01f_: ahh
19:03f_: fun name, because it sounds the same :P
19:08jja2000[d]: I think it's funny aswell
19:31Siggi: I googled for a nouveau discord when I started sniffing about, nothing turned up - you have a link?
19:38f_: it's supposed to be unofficial I think
19:39karolherbst: well after the name change it doesn't matter as much anymore
19:40f_: it's close enough, at least to me still sounds the same
19:41f_: (probably not a coincidence heh)
19:41f_: I wonder why it's not really advertised anywhere that I can find though
19:43f_: I mean I'm not sure many would mind "Queerdesktop" instead of "Freedesktop" as the name, probably "haha funny name, anyway". But even before the name change (assuming it was recent) I was never able to find a discord link anywhere in the wiki
19:46karolherbst: yeah, because it's not official Freedesktop
19:46karolherbst: but also because Discord is like a company and sure is becoming a dumpster fire I'd rather invest in alternatives at this point anyway
19:48Siggi: k, that makes sense
19:53Siggi: mkay, according to https://www.vesa.org/wp-content/uploads/2011/01/ICCE-Presentation-on-VESA-DisplayPort.pdf
19:53Siggi: there is vertical and horizontal blanking on DP
19:54Siggi: though the single-lane bandwidth should support 1920x1080
19:54Siggi: so IDK what could/would be underrunning
19:55Siggi: mmm, am I reading this right?
19:57airlied[d]: jja2000[d]: unlikely I'll do anything for pre-GSP jetson, have enough life problems :-P, though I wonder what architecture thor reports in terms of gp10b/gp20b etc
20:10jja2000[d]: airlied[d]: Absolutely fair, I'm huffing a bit of hopium for the DGX Spark to have the same blockers as GP10b/GM20b/etc. so any fixes for that platform would help :^)
20:10jja2000[d]: But I've also heard they've changed some stuff around to where it doesn't match at all. We'll see
20:12jja2000[d]: Just know if any of the issues you run into match with https://gitlab.freedesktop.org/mesa/mesa/-/issues/14105 and the fix _could_ apply to the older socs, let me know.
20:12esdrastarsis[d]: https://aur.archlinux.org/packages/vulkan-cts 👀
22:37mohamexiety[d]: airlied[d]: Thor is GB10B
22:37mohamexiety[d]: Essentially a smaller version of GB100, except with a 3D engine
22:38airlied[d]: so some of this work should help on thor, I think spark boots the same as thor
22:38mohamexiety[d]: Though I think there’s some ISA incompatibilities with matrix stuff.. iirc GB100/sm100 gets stochastic rounding while Thor/sm110 doesn’t
22:39mohamexiety[d]: airlied[d]: I don’t know if they fixed this but when it came out, Thor was using openrm and running on the GSP but there were a bunch of weird things forcing them to have a dedicated custom openrm for Thor so not sure if Thor needs extra stuff or not
22:39mohamexiety[d]: Spark runs normal openrm tho
22:42mohamexiety[d]: I was planning to get both, got Spark and Thor was next but then certain stuff happened and now shipping things to here became major pain .-.