09:22nvuser: 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:26nvuser: Card is evga 780 ti SC btw.. just wondering if someone wanted the values set by the nvidia driver for that level
09:26nvuser: if it's intended to do the same thing, that is
10:21RSpliet: 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:21nvuser: ah I see so that's more or less normal then
10:21RSpliet: Note that the "why" bit of my answer is a bit of speculation based on driver behaviour, I never asked them for reasons
10:22RSpliet: yeah, defo seen it elsewhere
10:23nvuser: ah in nvidia driver it seems to use this for a short moment before maxing out, but at different clock speeds
10:23nvuser: ram is same on both levels
10:23RSpliet: There's a lot more to ram than just a clock frequency
10:24nvuser: ah I see, it did seem a little less heavy on the pwm fan noise on 0d
10:24nvuser: maybe that's why
10:25RSpliet: 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:26RSpliet: That's just a simple example, not quite what's happening here
10:26RSpliet: (Can't remember the difference in DRAM configurations between d and f when I looked at it, been years)
10:26nvuser: ah yeah, fair enough, not exact and so on
10:28RSpliet: Either way, if it works for you there's no need to worry about it :-)
10:28nvuser: any reason why stock (non nvboost) 0f would be set slightly lower than the spec and what nvidia driver sets it to?
10:29nvuser: I'm seeing 1006 MHz on nvidia driver, 1000MHz on nouveau for base clock speed (manufacturer says 1006 MHz also)
10:29RSpliet: 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:30RSpliet: Nouveau has a margin when trying to determine PLL values, it's not exact. 6MHz might be considered "within the margin"
10:30nvuser: Yeah I guessed that would be who to ask, was about to open an issue about it but figured I'd ask first
10:31RSpliet: I don't think with all the perf lost in nouveau, those 6MHz are going to make the difference :-P
10:31nvuser: haha yeah, but hey if it's meant to 1006.. I'm sure us poor users will take what we can get
10:35nvuser: though I'm sure boost=1 is better for the case where I need more perf
12:26karolherbst: RSpliet: nouveau is just more precise in setting the clocks...
12:27karolherbst: 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:27karolherbst: but nvidia usually has a precision for 4-8MHz
12:30karolherbst: updated turing firmware
12:30karolherbst: please all try it if you have nouveau having issues booting on your turing gpu
13:06avoidr: 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:07avoidr: 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:10avoidr: Actually, sorry if it's on the pages, I was too happy and dumb to do that first now. Looking now.
13:18soreau: avoidr: you might have better results with wayland
13:19avoidr: Eh. I heard as much. But that would mean too much change for me.
14:01karolherbst: avoidr: don't use the nouveau ddx
14:01karolherbst: with the nouveau one you _might_ get it not tearing by enabling DRI 3, but... the modesetting even performs better anyway
14:15avoidr: Thank you for your hint, I'll try that out.
15:24nvuser: any chance there's a way to fix missing parts on textures?
15:24nvuser: am I missing some libs maybe
15:26karolherbst: probably a mesa bug
15:26karolherbst: but hard to say without knowing specifics
15:38nvuser: parts of textures just showing up black, or in some cases losing their 'shine'
15:48nvuser: 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:08avoidr: 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:10avoidr: Interestingly, I found that making a video full-screen reduces the tears.
16:11karolherbst: mhh yeah.. that might change things
16:11avoidr: Oh, and what I changed is use modesetting instead of nouveau.
16:12karolherbst: nvuser: what game was that again?
16:12karolherbst: looks familiar
16:12avoidr: Why do you think full-screen(?) change things?
16:14karolherbst: less synchronization required
16:14nvuser: Legend of Grimrock
16:20RSpliet: Wouldn't rule out a texturing issue, but could also be depth testing/discard related
16:20karolherbst: nvuser: do you see any errors in journald either on the kernel or userspace/steam/whatever side?
16:23RSpliet: 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:23RSpliet: Hard to say without knowing the application :D
16:23karolherbst: we know the application, but uhh.. could be anything anyway
16:24RSpliet: karolherbst: What I meant to say is that I know the name of the application, not the application itself ;-)
16:24karolherbst: well, it's a random game, so all bets are off :)
16:26RSpliet: Yeah, sounds like you could have a lot of fun with renderdoc to try and figure out what's happening
16:26karolherbst: 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:28RSpliet: If you're lucky it breaks with AMDGPU too :D
16:28karolherbst: if I'd be truly lucky, I'd have somebody else to work on such issues
16:29RSpliet: Which is significantly more likely if it also breaks with AMDGPU!
16:29RSpliet: Or even better, i915
16:29RSpliet: They have armies of people :-P
16:36nvuser: karolherbst: hmm actually it seems dmesg is filling up with this kind of thing - https://pastebin.com/jVLeX6sH
16:37nvuser: 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:38karolherbst: we kinda have this bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
16:38karolherbst: and still no idea what's causing it
16:39karolherbst: but mhh, shouldn't really affect the game
16:39nvuser: starting from terminal, no errors, it just displays "compiler shader.." etc
16:39karolherbst: yeah, then it's probably just some bug in the driver somewhere, mhh
16:40nvuser: Not sure why it's giving me amd-vi etc.. I have all that virt stuff turned off
16:40karolherbst: apparently it's something AMD generic and enabled on all systems or something
16:41nvuser: ah I'll try to tinker with the uefi, see if I can disable whatever that is
16:44KitsuWhooa: Sounds like the gpu is DMAing somewhere it's not supposed to
16:45KitsuWhooa: That AMD-Vi line is the IOMMU saying "no"
16:47KitsuWhooa: more specifically, because I'm blind
16:47KitsuWhooa: the GPU is trying to access address 0 :p
16:48KitsuWhooa: so perhaps a null pointer is being passed to it somewhere
16:49karolherbst: yeah, I suspect 5728d064190e169f1a42381bd7e5fc4d411f3188 broke it somehow
16:50KitsuWhooa: 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:50KitsuWhooa: never, as in, with a single card
16:51KitsuWhooa: my nouveau + amdgpu setup tears diagonally like there's no tomorrow, but that's different
16:55KitsuWhooa: Unless I'm really misremembering. It's been many years now
17:10nvuser: 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:10nvuser: still hve the graphical bug of course
22:28avoidr: I just had a freeze with modesetting, but I can't reproduce, so I'm back on nouveau for a bit.