01:08bi11y: hello, i am trying to trouble shoot an issue with my laptop screen flickering. I referred to this documentation (https://nouveau.freedesktop.org/wiki/TroubleShooting/#index8h3) and was referred here
01:08bi11y: this does seem to be my issue, i.e. high resolution monitor (3840x2160) and a 1050ti
01:09bi11y: do i need to up my clock rate for my GPU in bios or something similar?
01:13bi11y: most of the solutions i see online are 'install nvidia drivers' which i don't want to do
01:26gnarface: aw damn, i was too slow to save billy
12:49diogenes_: Hello guys, when i update iniramfs, i'm getting this: /lib/firmware/nvidia/gv100/sec2/sig.bin for module nouveau
12:49diogenes_: what does it mean? anything i need to install?
12:50karolherbst: diogenes_: I guess you don't have that file?
12:50karolherbst: maybe updating linux-firmwares helps
12:50diogenes_: karolherbst, i will show yoi the full output
12:50karolherbst: but this file is only relevant for volta cards which I assume you don't have
12:51diogenes_: karolherbst, here is the putput, it's MX-Linux, kernel 4.19: http://dpaste.com/2R5TN8M
12:52karolherbst: ah, yeah
12:52karolherbst: an updated linux-firmware package should help
12:52karolherbst: but you won't need it
12:52diogenes_: oh, so it's irrelevant to my case, thank you very much :)
12:53karolherbst: yeah, it's only needed for gv100 cards
12:53karolherbst: and I am 99.9% sure you don't have such
12:54diogenes_: karolherbst, i've got GK107M [GeForce GT 650M]
13:38chillfan: Is NvPmEnableGating useful for performance on kepler gpus?
13:38karolherbst: chillfan: it depends
13:39karolherbst: chillfan: it can reduce GPU temperature, which can also mean higher clocks could be reached... but currently we assume a worst case temperature anyhow
13:39karolherbst: but... you still end up with lower power consumption/heat
13:39chillfan: does it have a performance penalty for using it?
13:40karolherbst: I have some patches to turn that on (checking temperature and adjust the clock if needed)
13:40karolherbst: chillfan: I don't think so
13:40chillfan: assuming gpu temp is ok I mean
13:41chillfan: ah I may have to try it then
13:42chillfan: also does NvMemExec automatically change memory frequencies?
13:46RSpliet: chillfan: it shouldn't come with a noticable penalty. Under load it shouldn't do anything. It's just a miniscule latency when starting heavy duty applications (like a handful of clock cycles), you won't notice
13:47RSpliet: as for NvMemExec: no, you need to manually set higher frequencies. There's some missing bits before that can be made automatic (the main issue being a screen flicker every time you change frequencies on GPUs that drive your displays. Not seen on Optimus set-ups where displays are driven by Intel)
13:48chillfan: ah ok, any usage guidelines for setting the memory clocks?
13:48RSpliet: chillfan: /sys/kernel/debug/dri/<number>/pstate
13:48RSpliet: cat will list the available options, echo into it to select one
13:48RSpliet: On Kepler that should just work(tm)
13:48chillfan: ah right so enabling that just adds the memory frequencies to the clock profiles?
13:49RSpliet: NvMemExec is a safeguard preventing people from trying to change memory frequencies on GPUs where this is known to be a bad idea (Fermi, older generation Tesla and before, anything beyond Maxwell 1st gen)
13:49RSpliet: I think for Kepler it's superfluous, but don't take my word on that
13:50chillfan: I'll give it a try, thanks
13:52chillfan: I just gained a little extra performance from mesa upgrade with my distro, but sadly it wasn't enough for a particular game
13:52chillfan: so will see how I do with those options
13:52RSpliet: If you're running a discrete GPU, make sure to write to that debugfs file (as root!) only when your GPU is doing things. There used to be a lock-up when it was fast asleep, and I'm not sure whether karolherbst or anyone else already looked into fixing/working around that issue
13:52RSpliet: Clocks make a massive difference
13:54RSpliet: pardon, if you're running a discrete GPU in an Optimus laptop system
13:54RSpliet: is what I meant to say
13:54chillfan: ah, no it's a 780ti. I think things work nice here mostly
13:55RSpliet: Yeah, no need to worry then, it's always awake ;-)
13:55karolherbst: RSpliet: the lockup should be fixed by now
13:56RSpliet: karolherbst: Thanks! I'm glad to hear about that
13:56chillfan: nice to see nouveau coming along, shame about nvidias signed firmware thing
13:57RSpliet: I'm embarrassingly out of touch with the current status.
13:57chillfan: though I'd take SLI 780tis over newer gpus any day :D
13:57RSpliet: chillfan: I did some experiments with clock changing a 780Ti a few years ago, nouveau had it working like 90% back then, I think we ironed out most of the final details, so I'd expect that to work nicely and make a hige hige difference :-)
13:58RSpliet: *huge huge
13:58chillfan: Great, gonna have a little reboot then now grub is setup. Will tell you what the clocks look like
14:03chillfan: that's strange.. no effect and grub command line is apparently not including that
14:03chillfan: nouveau.config=NvBoost=1,NvClkMode=15,NvMemExec=1 < looks about right?
14:08chillfan: ok having another try then brb
14:18HdkR: karolherbst: Sadly it is going to become more and more likely that people are going to hit TU1xx issues as the lower end gets fleshed out D:
14:19RSpliet: chillfan: what's the output of cat /sys/kernel/debug/dri/<number>/pstate (fill in the number...)
14:20karolherbst: chillfan: you won't need to specify NvMemExec
14:20karolherbst: also NvBoost=1 might be too high, you should check your GPU temperature
14:20karolherbst: you can also set it to NvBoost=2, but then you have to be even more careful
14:20chillfan: well just the usual clocks, with 7000 MHz which is normal for this card
14:21karolherbst: that's memory ;)
14:21karolherbst: boost only affects core
14:21chillfan: yes 2 is too high for me, 1 is ok
14:21karolherbst: your core clocks should be lower than the 0xf pstate one
14:21chillfan: so no way to tweak the clocks a little more?
14:22karolherbst: not really
14:22chillfan: for the memory I should say
14:22karolherbst: you could adjust your vbios and mess up the values a bit
14:22karolherbst: but that could lead to instabilities
14:22karolherbst: chillfan: what game is running to slow for you?
14:23karolherbst: maybe we could tweak some shader optimizations... or maybe even the nir stuff could help here a lot... dunno, isn't shipped yet :D
14:23chillfan: it's an updated version of urbanterror running ioquake3 using the newer opengl2 renderer
14:23chillfan: let me see if i can find the repo
14:23karolherbst: yeah, that should reach good enough though
14:24chillfan: with a mesa upgrade it runs ok, but does not really feel smooth. Last mesa version I had it wasn't
14:26chillfan: most of their options are just enabled by default. I guess disabling some works, just trying to see if I can't get bit more out of the driver first
14:54chillfan: nvboost=2 shows a slight improvement to the game
14:55chillfan: but I won't keep it on for long
14:56karolherbst: chillfan: mhhh, might be worth collecting the shaders and see what we can do
14:56chillfan: how to collect them?
14:56karolherbst: chillfan: mind building mesa from one of my branches?
14:56karolherbst: I have a nouveau_nir_v9 branch
14:56chillfan: any debian package?
14:57chillfan: I guess I can build, but wont it mean building xorg etc.. or maybe breaking something?
14:57chillfan: ah, ok. If you show me the branch, I will try it out later on
14:57chillfan: are there instructions with it?
14:58karolherbst: I think I will check it out myself and test it locally first
14:58karolherbst: shouldn't be too hard to test the game
14:58chillfan: yeah it's just make and libsdl2-dev, libcurl-dev
14:59chillfan: can I just 'collect' the shaders in the shader cache? Is that how you mean?
15:00karolherbst: yeah... but you won't be able to share them publicly sadly :/ and then I wouldn't be able to tell if any change helps
15:00karolherbst: it's open source, right?
15:01karolherbst: anyway.. I can just do that locally
15:02karolherbst: and the shaders are here anyway: https://github.com/travmon/ioq3-m9/tree/rsm/code/renderergl2/glsl
15:02karolherbst: chillfan: ohh.. tried with disabled ssao?
15:02karolherbst: ssao i usually a perf nightmare
15:04chillfan: hm I will try that, maybe it's what's making it feel 'clunky'
15:10chillfan: ah anyway, seems like no negative issue from enabling clockgating, benchmarks look the same as always
15:16karolherbst: yeah, but your GPU shoulw be slightly cooler ;)
15:16karolherbst: or at least the power consumption lower
15:16chillfan: seems to be doing ok on nvboost=2 for the moment, but I haven't done anything really intensive yet
15:17karolherbst: run furmark
15:17karolherbst: that is intense
15:17karolherbst: its from gputest
15:17karolherbst: I was able to max out everys GPUs power budget with that one
15:17chillfan: ah lets see then
15:18karolherbst: be careful though
15:18karolherbst: nouveau doesn't really protect you from going over budget
15:18karolherbst: you should start with boost=0
15:18karolherbst: and check the power consumption
15:18karolherbst: chillfan: does sensor report the max consumption for you?
15:18karolherbst: should be arond 250
15:19chillfan: power1: 89.59 W (crit = 265.00 mW)
15:19chillfan: so if that number reaches 250 something.. time to stop?
15:21chillfan: will make sure I have debugfs in my custom kernel first.. was not built with it hah
15:22karolherbst: ahh, crit is 265
15:22karolherbst: so 265W :)
15:22karolherbst: chillfan: is that with powergating enabled? intense
15:22karolherbst: full idling or is something running?
15:22chillfan: nvboost=2 + powergating
15:23karolherbst: allthough I am not quite sure if our power readings are actually accurate
15:23karolherbst: I have a laptop where I can get to 150W with furmark... for a 80W GPU
15:23karolherbst: but it doesn't fit with what the battery tells me the discharge rate is
15:23karolherbst: need to check what's going on there
15:24chillfan: well also i had increased the fan a little just in case
15:26karolherbst: huh? manual fan control?
15:26karolherbst: normally the driver does it automatically
15:26chillfan: little extra on manual
15:27chillfan: back on auto now.. it's increasing fan speed quite quick
15:28chillfan: hm 300w so just stopped it
15:29karolherbst: with boost=2?
15:30karolherbst: yeah.. that benchmark really knows how to use the GPU
15:31chillfan: that was windowed mode
15:31karolherbst: yeah.. doesn't matter which mode
15:31karolherbst: boost=1 should be close to 265W
15:31karolherbst: boost=1 is kind of the safe in 99% of all cases setting
15:32karolherbst: boost=2 is the full power mode, but still respects voltage and stuff, but requires to monitor power consumption and so on :/
15:32chillfan: in my case, boost=1 is also the factory boost clock. 1072 MHz
15:32karolherbst: boost=2 is what works on top of that
15:32karolherbst: highly depends on the board quality and other factors
15:32karolherbst: no way to tell upfront
15:33karolherbst: except plugging the GPU in
15:33chillfan: but boost=2 feels nicely smooth. Maybe if I could adjust clocks to 1100 or 1125 it's fine
15:33karolherbst: shouldn't change _that_ much
15:35chillfan: well 1125 would be 5% OC for me
15:35chillfan: brb tho
15:38chillfan: ah the boost clock isn't far off what I would set on my own, it's at 1137
16:06chillfan: hm any quick hack I could do to change that number or would it be more involved?
16:10karolherbst: chillfan: would involve compiling your own nouveau module or kernel
16:11chillfan: well I can compile it, I just wouldn't know where to change the value
16:11karolherbst: it's not that easy
16:11chillfan: catch 22
16:11karolherbst: it's probably easier to just hack the vbios and pass that in.. but it's not that easy to setup with an initramfs
16:11karolherbst: anyway, there is no simple solution for it
16:12karolherbst: and going above boost=1 without any kind of protection from the driver side might be too dangarous
16:12karolherbst: might be okay in your case if the PSU is able to deliver the power
16:12karolherbst: and the GPU board is fine with 10% more power usage over the budget
16:12karolherbst: but generally...
16:13karolherbst: also I have to figure out why the sensor readings isn't correct
16:13chillfan: well in the first case I think so. motherboard has a secondary independent power supply for the pci express slots to provide more power
16:14karolherbst: sure... but it still depends on the PSU
16:14karolherbst: the slot can only provide 75W
16:14karolherbst: so everything else has to come through the other PINs
16:14chillfan: hm PSU is 620w but very high quality one that probably provides in reality 700 or 750w
16:15chillfan: well probably closer 700
16:15chillfan: but I do not meet the other criteria as you say anyway
16:17chillfan: I have no way to know for sure anyway
16:17karolherbst: anyway, if the GPU says that 265W is the max, we shouldn't draw more
16:17karolherbst: that's why we default to boost=0, because that's the most safe option
16:21chillfan: ah. Well thanks for all the great info
16:42pmoreau: karolherbst: I don’t (re: check for a function called "main"), and I don’t remember anything in the spec saying it is illegal.
16:42karolherbst: pmoreau: well, it's illegal in clc afaik
16:45karolherbst: pmoreau: 6.9 in the clc 2.2 spec: "u. A function in an OpenCL program cannot be called main"
16:46karolherbst: the opencl spir-v env spec doesn't have such a clause, but I'd assume it's still valid? dunno
16:46pmoreau: Okay; I would assume so? Might be good asking the Khronos people. And that check should be in spirv-val rather than clover imho.
17:11RSpliet: pmoreau: I suspect that constraint exists because there used to be OpenCL compilers targeting Intel/AMD CPUs and their SIMD extensions. Linkers would hate having a CL kernel called main.
17:11RSpliet: Sounds hacky, but... *shrug*
17:12karolherbst: RSpliet: there are same constraints with C though ;)
17:12RSpliet: I would never dare to claim C isn't hacky :-D
17:12karolherbst: I think __main is reserved in the same manner
17:13RSpliet: Anyway, bbl