09:22 nvuser: hey. I'm just wondering what option NVClkMode 0d is meant to do with nouveau.. for my card when I set that I get the same values as for 0f
09:26 nvuser: Card is evga 780 ti SC btw.. just wondering if someone wanted the values set by the nvidia driver for that level
09:26 nvuser: if it's intended to do the same thing, that is
10:21 RSpliet: nvuser: it's an intermediate state with a slightly different memory configuration. You shouldn't notice it, but I think it's there because NVIDIA decided it's safer to transition through d to get to f. May have something to do with boost clocks.
10:21 nvuser: ah I see so that's more or less normal then
10:21 RSpliet: Note that the "why" bit of my answer is a bit of speculation based on driver behaviour, I never asked them for reasons
10:22 RSpliet: yeah, defo seen it elsewhere
10:23 nvuser: ah in nvidia driver it seems to use this for a short moment before maxing out, but at different clock speeds
10:23 nvuser: ram is same on both levels
10:23 RSpliet: Yep
10:23 RSpliet: There's a lot more to ram than just a clock frequency
10:24 nvuser: ah I see, it did seem a little less heavy on the pwm fan noise on 0d
10:24 nvuser: maybe that's why
10:25 RSpliet: I can only speculate, but signal integrity is not a simple "on-off" process. If you try to get a PLL running at 100MHz to suddenly lock at 3GHz you might fail, whereas adding an intermediate step of 1.5GHz will make it work reliably.
10:26 RSpliet: That's just a simple example, not quite what's happening here
10:26 RSpliet: (Can't remember the difference in DRAM configurations between d and f when I looked at it, been years)
10:26 nvuser: ah yeah, fair enough, not exact and so on
10:28 RSpliet: Either way, if it works for you there's no need to worry about it :-)
10:28 nvuser: any reason why stock (non nvboost) 0f would be set slightly lower than the spec and what nvidia driver sets it to?
10:29 nvuser: I'm seeing 1006 MHz on nvidia driver, 1000MHz on nouveau for base clock speed (manufacturer says 1006 MHz also)
10:29 RSpliet: I think that's a karolherbst question, he looked at boost back in the days. I remember the VBIOS specifying three ranges of frequencies, one with boost on, one with boost off and one with... idk.
10:30 RSpliet: Nouveau has a margin when trying to determine PLL values, it's not exact. 6MHz might be considered "within the margin"
10:30 nvuser: Yeah I guessed that would be who to ask, was about to open an issue about it but figured I'd ask first
10:31 RSpliet: I don't think with all the perf lost in nouveau, those 6MHz are going to make the difference :-P
10:31 nvuser: haha yeah, but hey if it's meant to 1006.. I'm sure us poor users will take what we can get
10:35 nvuser: though I'm sure boost=1 is better for the case where I need more perf
10:35 RSpliet: yep
12:26 karolherbst: RSpliet: nouveau is just more precise in setting the clocks...
12:27 karolherbst: kinda depends what the nvbios says, but our fractional scaler is more precise.. I have no idea if that's causing issues or not
12:27 karolherbst: but nvidia usually has a precision for 4-8MHz
12:30 karolherbst: https://lore.kernel.org/linux-firmware/1680518599-12748-1-git-send-email-gsamaiya@nvidia.com/T/#u
12:30 karolherbst: updated turing firmware
12:30 karolherbst: please all try it if you have nouveau having issues booting on your turing gpu
13:06 avoidr: Guys, quick question. I use nouveau and I tried to configure vsync, tried to get my screen to stop tearing. But gave up eventually. Very generally, is this possible to do? Does the graphics card model matter? Do I fundamentally need the firmware blobs?
13:07 avoidr: I tried 'Option "GLXVBlank" "true"' in xorg.conf, I installed xf86-video-nouveau, I installed nvidia-firmware-340.32. My question is basically if I should try harder or it's just a missing feature or something.
13:10 avoidr: Actually, sorry if it's on the pages, I was too happy and dumb to do that first now. Looking now.
13:18 soreau: avoidr: you might have better results with wayland
13:19 avoidr: Eh. I heard as much. But that would mean too much change for me.
14:01 karolherbst: avoidr: don't use the nouveau ddx
14:01 karolherbst: with the nouveau one you _might_ get it not tearing by enabling DRI 3, but... the modesetting even performs better anyway
14:15 avoidr: Thank you for your hint, I'll try that out.
15:24 nvuser: any chance there's a way to fix missing parts on textures?
15:24 nvuser: am I missing some libs maybe
15:26 karolherbst: huh?
15:26 karolherbst: probably a mesa bug
15:26 karolherbst: but hard to say without knowing specifics
15:38 nvuser: parts of textures just showing up black, or in some cases losing their 'shine'
15:45 nvuser: https://oshi.at/ists
15:48 nvuser: from a rendered in game cutscene, but should look something like this: https://www.wsgf.org/f/u/contrib/dr/21324/cutscene_4x3.jpg
16:08 avoidr: karolherbst, thank you very much, the tearing isn't 100% gone, but performance is better (more consistent) and I believe there are a bit fewer tears because of that.
16:10 avoidr: Interestingly, I found that making a video full-screen reduces the tears.
16:11 karolherbst: mhh yeah.. that might change things
16:11 avoidr: Oh, and what I changed is use modesetting instead of nouveau.
16:12 karolherbst: nvuser: what game was that again?
16:12 karolherbst: looks familiar
16:12 avoidr: Why do you think full-screen(?) change things?
16:14 karolherbst: less synchronization required
16:14 nvuser: Legend of Grimrock
16:14 karolherbst: ahh
16:20 RSpliet: Wouldn't rule out a texturing issue, but could also be depth testing/discard related
16:20 karolherbst: nvuser: do you see any errors in journald either on the kernel or userspace/steam/whatever side?
16:23 RSpliet: or synchronisation - the gears have some amount of transparency? Idk, maybe their fragment shaders sample the background for blending purposes, which would fail if the background wasn't rendered yet.
16:23 RSpliet: Hard to say without knowing the application :D
16:23 karolherbst: we know the application, but uhh.. could be anything anyway
16:24 RSpliet: karolherbst: What I meant to say is that I know the name of the application, not the application itself ;-)
16:24 karolherbst: well, it's a random game, so all bets are off :)
16:26 RSpliet: Yeah, sounds like you could have a lot of fun with renderdoc to try and figure out what's happening
16:26 karolherbst: yeah I mean.. sure, but there are sadly even more important things to look into :'( so anything not strictly breaking stuff is always kinda low prio atm
16:28 RSpliet: If you're lucky it breaks with AMDGPU too :D
16:28 karolherbst: if I'd be truly lucky, I'd have somebody else to work on such issues
16:29 RSpliet: Which is significantly more likely if it also breaks with AMDGPU!
16:29 RSpliet: Or even better, i915
16:29 RSpliet: They have armies of people :-P
16:36 nvuser: karolherbst: hmm actually it seems dmesg is filling up with this kind of thing - https://pastebin.com/jVLeX6sH
16:37 karolherbst: mhhh
16:37 nvuser: it's really spamming it somehow.. if i look in a moment another 100+ entries like that will be there, just idling on desktop
16:38 karolherbst: we kinda have this bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
16:38 karolherbst: and still no idea what's causing it
16:39 karolherbst: but mhh, shouldn't really affect the game
16:39 nvuser: starting from terminal, no errors, it just displays "compiler shader.." etc
16:39 karolherbst: yeah, then it's probably just some bug in the driver somewhere, mhh
16:40 nvuser: Not sure why it's giving me amd-vi etc.. I have all that virt stuff turned off
16:40 karolherbst: apparently it's something AMD generic and enabled on all systems or something
16:41 nvuser: ah I'll try to tinker with the uefi, see if I can disable whatever that is
16:44 KitsuWhooa: Sounds like the gpu is DMAing somewhere it's not supposed to
16:45 KitsuWhooa: That AMD-Vi line is the IOMMU saying "no"
16:46 karolherbst: right..
16:47 KitsuWhooa: more specifically, because I'm blind
16:47 KitsuWhooa: the GPU is trying to access address 0 :p
16:48 KitsuWhooa: so perhaps a null pointer is being passed to it somewhere
16:49 karolherbst: yeah, I suspect 5728d064190e169f1a42381bd7e5fc4d411f3188 broke it somehow
16:50 KitsuWhooa: Also, going back a bit, I never had tearing with nouveau and compiz. Especially with multiple monitors at different refresh rates, I remember nouveau worked way better than the nvidia blob
16:50 KitsuWhooa: never, as in, with a single card
16:51 KitsuWhooa: my nouveau + amdgpu setup tears diagonally like there's no tomorrow, but that's different
16:55 KitsuWhooa: Unless I'm really misremembering. It's been many years now
17:10 nvuser: Well I tried disabling iommu, that worked.. then I reenabled it, followed by switching to my older kernel.. from 6.2 that displayed the issue, and 6.1 that didn't
17:10 nvuser: still hve the graphical bug of course
22:28 avoidr: I just had a freeze with modesetting, but I can't reproduce, so I'm back on nouveau for a bit.