00:55joepublic: Is it normal for the display to suddenly show the user where the mouse has been?
00:56joepublic: by normal I don't mean prescribed behavior, but rather "heard of before" because I don't think I personally ever have
01:04RSpliet: joepublic: Heh, last time I delved into NVIDIA hardware I could swear that the cursor was hardware accelerated, like some sort of overlay. In which case this is highly strange behaviour for a correct nouveau set-up...
01:05joepublic: My cat seems to have initiated it by creative keyboard work. I can't explain how. Normally it works perfectly.
01:07RSpliet: Oh heh, there is such a thing in mouse tracks in accessibility options. At least there was on Windows, so I'm sure this exists in several Linux DEs. Don't know yours though, afraid I can't tell you how to en/disable it. Maybe ask the feline?
01:07joepublic: I have asked her to limit keyboard contact through the mantra "no kitty on keys"
11:38prOMiNd: RSpliet, what disadvantages are you talking about overclocking?
11:39prOMiNd: I am exploring GDDR5 limitations currently, with AMD I have been able to surpass 10GBps with slight error rate, while nvidia does that with stock timings :)
11:43karolherbst: prOMiNd: you have to compare the bus width as well
11:44prOMiNd: 256bit both
11:44karolherbst: not fair comparing bandwidth if the width is different
11:44prOMiNd: comparing pure 1070 with rx580
11:44prOMiNd: both with micron memory
11:44prOMiNd: too bad I can´t monitor voltage on nvidia :(
11:45karolherbst: also 10 GB/s is quite slow?
11:45karolherbst: memory voltage is fixed with GDDR5
11:45prOMiNd: not memory voltage, core
11:45karolherbst: that's easy
11:45prOMiNd: how so?
11:46karolherbst: mhh, this is pascal, right?
11:46RSpliet: prOMiNd: our shader compiler missing vital optimisations, our memory allocation scheme not being DRAM partition aware, command stream probably too conservative with barriers, lack of functional zcull, wasted CPU cycles... there's a million areas where we can improve nouveau performance-wise before we get on par with the official driver in most workloads.
11:47karolherbst: prOMiNd: it might be that gk104_volt_get is still valid for pascal core voltage
11:47karolherbst: it's basically something like the vbios tells you a voltage base + range
11:47karolherbst: and two mmio regs tell you the PWM ratio
11:47RSpliet: It's nice that you can get 10% or 20% more memory bandwidth using overclocking techniques, but that buys you nothing if it's not the bottleneck. With the nouveau driver stack, it probably isn't
11:48karolherbst: RSpliet: I am sure it's about the binary driver here
11:48RSpliet: karolherbst: that was RE "RSpliet, what disadvantages are you talking about overclocking?", which inquires about my statement about nouveau
11:49prOMiNd: return bios->base + bios->pwm_range * duty / div;
11:49prOMiNd: should do
11:49prOMiNd: except vbios area is 0x30000
11:49karolherbst: prOMiNd: yeah... issue is, how to parse that from the vbios
11:49karolherbst: they changed a lot there
11:49karolherbst: with pascal
11:49prOMiNd: checking on my p106 :)
11:51prOMiNd: 0xa0 - div, 0x55 - duty
11:51karolherbst: yeah, but that doesn;t help you directly
11:51prOMiNd: no, not at all
11:51karolherbst: there are also 2 PWMs now I think
11:51karolherbst: it's ... complicated, at least more complicated than kepler/maxwell was
11:52prOMiNd: food for thought for the next few month
11:52karolherbst: and kind of pointless for us to dig into
11:52karolherbst: we can't change it anyway
11:52karolherbst: the voltage I mean
11:52prOMiNd: for you - yeah, for me...its a challange :)
11:53prOMiNd: you can actually, but only UP
11:53karolherbst: figuring out the new vbios tables might be worth digging into
11:53prOMiNd: they are public, though
11:55karolherbst: what do you mean? Others fully reverse engineered them already?
11:56karolherbst: I was talking about the tables, not the BIT table
11:57prOMiNd: hehe, no they aren´t public and idk if nvidia are going to reveal those
11:57karolherbst: maybe, maybe not
11:57prOMiNd: but the pointers are there, it might be worth fooling around with them
11:58karolherbst: well... for this you need a way to get the nvidia driver to eat your vbios ;)
11:58prOMiNd: I just parsed 16k of tables...will start chaning bit by bit to find out what changes
11:59karolherbst: and how are you planning to change those?
11:59karolherbst: also, random bit flips will just lead to driver crashes or the driver failing to load
12:00prOMiNd: setting powerlimit lowers voltage, this will reveal the actuall changes to tables, then I´ll start poking it :)
12:00prOMiNd: no worries, its on VM :D
12:01karolherbst: no.. what I meant is, how to you want to get nvidia to load your changes
12:01karolherbst: because... there isn't really a way of doing that
12:02karolherbst: you could probably intercept it through the VM and pass in whatever value, right
12:12prOMiNd: I don´t want to modify the vbios, I want to poke registers realtime
12:13prOMiNd: while running
12:16karolherbst: good luck
12:17karolherbst: keep in mind that some of them might be just locked down and require a signed falcon binary to change
12:17karolherbst: but that doesn't help us with figuring out the vbios tables ;)
12:19prOMiNd: I don´t understand why nvidia keep that secret since you can only flash signed vbios
12:26prOMiNd: karolherbst, you can determine memory vendor by parsing MISC timing set
12:26prOMiNd: its always different for the 3 vendors samsung/micon/hynix
12:26prOMiNd: [0x9a0248] A7442899
12:26prOMiNd: => samsung
12:27prOMiNd: [0x9a0248] 44441414 => micron
21:23karolherbst: imirkin: I got pointed out that we don't really do compression for 32 bit pixelformats.. how much do you know about the things missing to implement it correctly?
21:24imirkin: afaik we do
21:24karolherbst: imirkin: https://github.com/mesa3d/mesa/blob/master/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#L113-L115
21:24imirkin: you mean like rgba8, right?
21:24imirkin: oh, for the no-ms case
21:25imirkin: i know nothing about it.
21:25imirkin: "it was like that when i got here"
21:25karolherbst: I just got that pointed out
21:25karolherbst: mhh, maybe it might be worth to dig into it
21:25imirkin: for all i know, that blurry thing is no longer the case
21:25imirkin: or it could be due to using the 2d engine for blits
21:25imirkin: or due to some wholly other thing
21:32karolherbst: imirkin: okay, so somebody told me that nouveau apperantly normally uses ZBC for the framebuffer, which means that colors aren't compressed except for the clear color. Depth buffers are compressed by a non ZBC thingy. Sadly I don't really know anything in that regards, but it sounds like that if that's the case, spending some time on that could potentially give us a huge benefit
21:33imirkin: my knowledge of such things is limited at best
21:34karolherbst: maybe if I get bored enough I dig into that
22:35karolherbst: sometimes I wished we would get something more meaningful than a "CTXSW_TIMEOUT" if an application hangs :/
23:23imirkin: that means the context-switching firmware fails
23:23imirkin: (or rather, times out)
23:24imirkin: tbh i think with some of the improvements that have happened in the past couple years have made some failures a lot more fatal than they used to be