01:01 airlied[d]: okay got it to work, but it's a bit messy on the meson side
01:20 airlied[d]: https://gitlab.freedesktop.org/airlied/mesa/-/commits/nvk/blackwell-latencies
01:27 HdkR: airlied[d]: Oh snap, you actually got access to those xls files? Finally!
01:28 airlied[d]: RH have had them under NDA for a while, just trying to work out how use them without making mistakes 😛
01:30 HdkR: :D
01:33 HdkR: Are they still hiding the RT instructions from those NDA files? How rude.
01:35 HdkR: Not very hard to RE, just kind of funny.
04:04 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1390181436111327324/image.png?ex=686752da&is=6866015a&hm=27d36ad1336d1641998bfb562c99c5b09709c7ab0ec671761bbf194ab6494e06&
04:04 mangodev[d]: wha…
04:05 mangodev[d]: new error when i tried building as lib32
04:39 mangodev[d]: oh hmmmm
04:40 mangodev[d]: so it breaks when i use rustup instead of system packaged rust
04:40 mangodev[d]: strange
09:27 LinuxLover471: Hello! I use a GT 740 and the performance of the nouveau driver is too bad to use piglit on it, is there any way that I can contribute by using the nvidia binary driver? I don't know C, so I can't be a developer, but I would like to contribute.
09:30 LinuxLover471: I have tried setting up piglit in the past, but I have failed pretty badly, and I would like to help by using the proprietary driver.
10:21 LinuxLover471: how can I contribute while using the nvidia binary driver for my GT 740? I was not able to set up piglit, and nouveau is too slow even for general use.
10:34 machoskraito: hi all
10:38 LinuxLover471: hi
10:41 machoskraito: <machoskraito> hi bkil
10:41 machoskraito: <machoskraito> yay kid i am just been elect back as United Nations Chief Executive Board
10:41 machoskraito: <machoskraito> so how are you all here
10:41 machoskraito: <machoskraito> We are releasing AstaraOS-FreeBSD-v15 now
10:41 machoskraito: <machoskraito> my name is yohanes patra aka skraito
10:41 machoskraito: <machoskraito> nice to meet you all
10:41 machoskraito: hi LinuxLover471
10:41 machoskraito: how life been for you
10:44 LinuxLover471: it's fine, just got braces, kind of painful.
10:45 HdkR: lol
10:45 LinuxLover471: Hey what was that
10:46 karolherbst: spam
10:46 HdkR: I like that they have joined multiple channels for it.
10:47 LinuxLover471: they are talking to me privately telling me to join #exploiter wtf, is it safe?
10:47 HdkR: It's a trap!
10:47 asuasuasu[d]: don't and /ignore
10:47 LinuxLover471: okay.
10:47 karolherbst: dwfreed: ^^
10:48 LinuxLover471: I said I am good in this chat and I won't chat at there
10:48 LinuxLover471: BTW, can I help nouveau by using the binary driver? I can't use nouveau, it's too slow even for general use
10:49 karolherbst: reverse engineering probably
10:49 karolherbst: maybe
10:49 HdkR: I admire the dedication, it's like ye olde time IRC spam.
10:49 karolherbst: thing is.. the blob driver is way less useful to us than it was years ago, because nvidia actually helps us out now
10:51 karolherbst: HdkR: need to stand out in the age of AI
10:52 LinuxLover471: Oh, so Is there any other way that I can help? Setting up piglit is a hassle...
10:52 karolherbst: you probably want to help out with the vulkan driver and make sure you use zink instead of the native gl driver
10:52 karolherbst: ohh
10:52 karolherbst: GT 740
10:52 karolherbst: uhhh
10:52 karolherbst: pain
10:53 karolherbst: LinuxLover471: you aware of the `/sys/kernel/debug/dri/0/pstate` file? You can uhm.. write "0xf" into it as root and you get better perf
10:53 karolherbst: but...
10:53 karolherbst: well.. testing NVK would be helpful
10:53 karolherbst: and report bugs
10:59 LinuxLover471: Oh, I had tested the dri pstate file, but it gave me graphical glitches that literally cooked the pc. Not usable. About NVK, is there any support even available for this gpu? if yes, I would like to help.
10:59 karolherbst: ohh.. shoo
10:59 karolherbst: LinuxLover471: is it just the 0xf one, or did you also try 0xa?
10:59 LinuxLover471: I had used the arch wiki so... let me confirm
10:59 karolherbst: but if the pstate stuff doesn't work for you, then also nvk is going to be slow for you sadly...
11:02 LinuxLover471: It seems the arch wiki got updated, but there were two options, I guess I will try to retry using the perf state, thanks for the response!
11:05 karolherbst: _but_ if it's broken for you on nouveau, you could use the binary driver to figure out what's wrong. Though that's a bit messy to do and might require a lot of time, because the reclocking code is complex and kinda hard to follow
11:06 LinuxLover471: sadly, I don't have coding knowledge, so my ability to contribute is pretty low.
11:10 karolherbst: well.. then finding which games don't run well with latest mesa would be helpful
11:12 LinuxLover471: Hmm, when I had used the latest mesa with azahar, it failed miserably, couldn't load the game with the opengl renderer, the vulkan one gave 1 fps but didn't crash.
11:32 karolherbst: mhhh, not sure you'll get more with default clocks
11:46 LinuxLover471: Okay, I am going to reboot to finish setup of nouveau, and after that I will try to get better clocks.
11:58 LinuxLover471: I just setup nouveau, and I used cat on the pstate, it shows two options, 0f and AC. You told me to use 0xf, and 0xa. I will try using 0f and after that these two.
11:58 karolherbst: AC is just the "current" thing, well AC also says "connected to power"
11:59 karolherbst: LinuxLover471: is there really only 0f? not 07 or 0a?
11:59 LinuxLover471: I didn't know that!
11:59 LinuxLover471: Yeah, only of
11:59 LinuxLover471: I mean 03
11:59 karolherbst: mind pasting the content?
11:59 LinuxLover471: 0f: core 324-993 MHz memory 1334 MHz AC: core 324 MHz memory 648 MHz
12:00 LinuxLover471: Also, inxi reports this GPU as kepler2
12:00 karolherbst: mhhhh
12:01 LinuxLover471: now I will try, let's hope for the best.
12:01 karolherbst: I wonder if we parse something incorrectly, but it could also be that it's just what's in your vbios
12:02 karolherbst: RIP
12:04 karolherbst: LinuxLover471: sounds like it didn't go too well
12:05 LinuxLover471: Failed miserably, when I did this, the screen started glitching in small fragments, freeze lock every few seconds, and after that, firefox crashed, and only the terminal window of console appeared which was also glitching when typing, and making the line I am typing in flash in black.
12:06 LinuxLover471: I was able to type reboot and recover.
12:07 karolherbst: yeah.. sounds like the VRAM clocks aren't correctly configured by the kernel...
12:07 LinuxLover471: I am using arch linux, so the kernels are the latest, stable kernel, and this is not any flavour of kernel, it's the plain, arch kernel.
12:08 karolherbst: did you add the nvboost kernel arg or something?
12:08 LinuxLover471: what's that?
12:08 karolherbst: well if you don't know, it's okay :D It just allows for higher clocks
12:08 karolherbst: mhh
12:08 karolherbst: do you have your kernel logs from your last boot?
12:09 karolherbst: you said you were able to reboot, right?
12:09 mangodev[d]: karolherbst: oh yeah
12:09 mangodev[d]: afaik those cards require manual clocking, right?
12:09 LinuxLover471: Yeah, safely, just give me a moment.
12:09 karolherbst: wondering if "journalctl --dmesg --boot -1" contains any errors at the bottom
12:09 karolherbst: somewhere at the bottom at least.. before the reboot :D
12:11 LinuxLover471: [ak@G31M-ES2L ~]$ sudo journalctl -b 1 | curl -F 'file=@-' 0x0.st [sudo] password for ak: Journal file /var/log/journal/83f118a3cee648d0b7044c373ed77a41/user-1000@0006378b0fa53e5d-32471f6e58fb06ff.journal~ corrupted, ignoring file. http://0x0.st/80py.txt [ak@G31M-ES2L ~]$
12:11 LinuxLover471: https://0x0.st/80py.txt
12:11 LinuxLover471: I am not sure if this is right, as it's showing some sort of error.
12:12 LinuxLover471: http://0x0.st/80pt.txt
12:13 LinuxLover471: This one was the output of the command you requested.
12:13 LinuxLover471: I think these are the wrong ones, let me try again.
12:29 LinuxLover471: How do I keep the logs saved and synced, until my system crashes? All the logs are corrupted.
12:31 LinuxLover471: If I can keep it all synced on a different file in my home folder, then I think I can extract the logs.
12:32 karolherbst: LinuxLover471: the last one you linked looked okay
12:33 LinuxLover471: Did you find anything?
12:35 karolherbst: I see the GPU misbehaving but that's not really helping. I kinda hoped to see some errors from the clocking, but I think this is simply a vbios parsing issues or so.. maybe. It's always a bit hard to tell with those kinds of issues
12:37 karolherbst: LinuxLover471: you could upload the files at /sys/kernel/debug/dri/0/vbios.rom and strap_peek to an file an issue here: https://gitlab.freedesktop.org/drm/nouveau/-/issues
12:39 LinuxLover471: If that's the case, maybe I can try running glxgears, after turning this on, and maybe after that try rebooting, but it's not guaranteed I will be able to reboot normally.
12:42 karolherbst: LinuxLover471: nah, I doubt anything you can do besides providing the vbios.rom file will be able to help
12:43 karolherbst: I kinda hoped there would be an error with setting the voltage or something, because those are easier to fix
12:43 karolherbst: but it looks like that nouveau simply configures the GPU incorrectly
13:03 LinuxLover471: Do I have to upload the vbios normally, or after I have setup the 0f? I think it doesn't matter, right?
13:08 snowycoder[d]: LinuxLover471: Kepler2? GT 740 should have a GK107 chip (kepler 1)
13:28 LinuxLover471: snowcoder[d] : inxi says that my gpu is a Kepler-2, GK 107
13:29 LinuxLover471: snowycoder[d] : ping
13:29 LinuxLover471: Guys how do I ping/reply?
13:34 tiredchiku[d]: just type their username, the way you did
13:36 snowycoder[d]: LinuxLover471: Sorry I was just confused about naimg conventions, thanks for the clarification :3
18:47 gfxstrand[d]: mhenning[d]: dataflow looks really good. Left two total nits.
18:50 snowycoder[d]: gfxstrand[d]: There's a new MR for that??
18:51 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35446
21:12 gfxstrand[d]: For some reason we're not getting kopper with `DRI_PRIME=1`
21:22 gfxstrand[d]: We're not getting Kopper at all. 🤯
21:29 gfxstrand[d]: Okay, I'm neither well slept enough nor drunk enough to look at EGL code.
21:32 zmike[d]: I recommend meth
21:32 gfxstrand[d]: I recommend calling it quits and going home
21:33 gfxstrand[d]: Yeah, everything is in the wrong order.
21:34 gfxstrand[d]: We create the screen after we initialize loader extensions. Which means we have to know we're using Zink before we load nouveau and says "No, actually, use Zink"
21:39 gfxstrand[d]: IDK if X11 has this problem. Probably
21:39 gfxstrand[d]: In order to make this work we have to partially initialize wayland before we decide to use kopper
21:39 gfxstrand[d]: It's gonna be pain
21:40 gfxstrand[d]: Either that or we need to fix all the non-kopper bugs
21:40 airlied[d]: but we do pick zink before loading nouveau
21:41 airlied[d]: it's why it gets picked in the loader not in nouveau
21:45 gfxstrand[d]: But EGL doesn't know that.
21:46 airlied[d]: ah because it has it's own set of hacks even before the loader
21:47 airlied[d]: because it's hacks all the way down instead of designed
21:48 gfxstrand[d]: Yeah, all the Kopper stuff is based on environment variables.
21:49 airlied[d]: yeah checking MESA_LOADER_DRIVER_OVERRIDE is very wrong
21:50 airlied[d]: _eglDeviceRefreshList should probably call into the loader
21:52 airlied[d]: or dri2_query_device_info should
21:52 airlied[d]: hmm that should work, maybe we aren't just checking the results properly
21:53 airlied[d]: dri_get_drm_device_info should get the zink driver name
21:53 gfxstrand[d]: There are layers of bullshit going on. I haven't detailed them yet
21:53 gfxstrand[d]: https://tenor.com/view/onions-have-layers-gif-7154017276425979182
21:54 airlied[d]: something, something, traverse the device list and find a device with zink in it's driver_name, handwave, use zink
21:54 zmike[d]: most of the current mechanism was written before all the dri refactoring
21:54 zmike[d]: seems like it should be simpler to improve things now
21:56 gfxstrand[d]: airlied[d]: Nope. We don't want Iris forced down the Kopper path. We have to base that decision on the DRM device we get back from Wayland or X11.
21:57 airlied[d]: so disp->Options.Zink has to die
21:58 airlied[d]: or at least get chosen much later
21:58 gfxstrand[d]: Yup
21:58 gfxstrand[d]: It needs to be chosen based on actually using Zink
21:59 zmike[d]: it only ever existed originally to be a check for MESA_LOADER_DRIVER_OVERRIDE
21:59 airlied[d]: this begs a question in the prime scenarios whether we can use kopper
22:00 airlied[d]: which isn't a think we should be checking for outside the loader 🙂
22:00 airlied[d]: do we have an EGL display per device? or just one with multiple deices
22:01 airlied[d]: because the EGL display pretty much picks a path and locks in
22:01 gfxstrand[d]: Use Kopper if the render driver is Zink. Vulkan WSI in Mesa can do prime.
22:02 gfxstrand[d]: Which is something we can only only once the display is at least partially initialized.
22:19 gfxstrand[d]: What we need to do is initialize the display far enough to pick a driver and then pick Kopper.