00:55 joepublic: Is it normal for the display to suddenly show the user where the mouse has been?
00:56 joepublic: https://freworld.info/campaigns/random/mouse-tracks.png
00:56 joepublic: by normal I don't mean prescribed behavior, but rather "heard of before" because I don't think I personally ever have
01:04 RSpliet: 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:05 joepublic: My cat seems to have initiated it by creative keyboard work. I can't explain how. Normally it works perfectly.
01:07 RSpliet: 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:07 joepublic: I have asked her to limit keyboard contact through the mantra "no kitty on keys"
11:38 prOMiNd: RSpliet, what disadvantages are you talking about overclocking?
11:39 prOMiNd: 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:43 karolherbst: prOMiNd: you have to compare the bus width as well
11:44 prOMiNd: 256bit both
11:44 karolherbst: not fair comparing bandwidth if the width is different
11:44 prOMiNd: comparing pure 1070 with rx580
11:44 prOMiNd: both with micron memory
11:44 prOMiNd: too bad I can´t monitor voltage on nvidia :(
11:45 karolherbst: also 10 GB/s is quite slow?
11:45 prOMiNd: 10GH
11:45 prOMiNd: sorry
11:45 prOMiNd: autocorrect
11:45 karolherbst: memory voltage is fixed with GDDR5
11:45 prOMiNd: not memory voltage, core
11:45 karolherbst: ahh
11:45 karolherbst: that's easy
11:45 prOMiNd: how so?
11:46 karolherbst: mhh, this is pascal, right?
11:46 prOMiNd: yep
11:46 RSpliet: 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:47 karolherbst: prOMiNd: it might be that gk104_volt_get is still valid for pascal core voltage
11:47 karolherbst: it's basically something like the vbios tells you a voltage base + range
11:47 karolherbst: and two mmio regs tell you the PWM ratio
11:47 prOMiNd: sec
11:47 prOMiNd: checking
11:47 RSpliet: 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:48 karolherbst: RSpliet: I am sure it's about the binary driver here
11:48 RSpliet: karolherbst: that was RE "RSpliet, what disadvantages are you talking about overclocking?", which inquires about my statement about nouveau
11:49 prOMiNd: return bios->base + bios->pwm_range * duty / div;
11:49 prOMiNd: should do
11:49 prOMiNd: except vbios area is 0x30000
11:49 karolherbst: prOMiNd: yeah... issue is, how to parse that from the vbios
11:49 karolherbst: they changed a lot there
11:49 karolherbst: with pascal
11:49 prOMiNd: checking on my p106 :)
11:51 karolherbst: mhh
11:51 prOMiNd: 0xa0 - div, 0x55 - duty
11:51 karolherbst: yeah, but that doesn;t help you directly
11:51 prOMiNd: no, not at all
11:51 karolherbst: there are also 2 PWMs now I think
11:51 karolherbst: it's ... complicated, at least more complicated than kepler/maxwell was
11:52 prOMiNd: food for thought for the next few month
11:52 prOMiNd: months*
11:52 karolherbst: and kind of pointless for us to dig into
11:52 karolherbst: we can't change it anyway
11:52 karolherbst: the voltage I mean
11:52 prOMiNd: for you - yeah, for me...its a challange :)
11:53 prOMiNd: you can actually, but only UP
11:53 karolherbst: figuring out the new vbios tables might be worth digging into
11:53 prOMiNd: they are public, though
11:55 karolherbst: what do you mean? Others fully reverse engineered them already?
11:56 prOMiNd: BIT_PERF_PTRS
11:56 karolherbst: I was talking about the tables, not the BIT table
11:57 prOMiNd: hehe, no they aren´t public and idk if nvidia are going to reveal those
11:57 karolherbst: maybe, maybe not
11:57 prOMiNd: but the pointers are there, it might be worth fooling around with them
11:58 karolherbst: well... for this you need a way to get the nvidia driver to eat your vbios ;)
11:58 prOMiNd: I just parsed 16k of tables...will start chaning bit by bit to find out what changes
11:59 karolherbst: and how are you planning to change those?
11:59 karolherbst: also, random bit flips will just lead to driver crashes or the driver failing to load
12:00 prOMiNd: setting powerlimit lowers voltage, this will reveal the actuall changes to tables, then I´ll start poking it :)
12:00 prOMiNd: no worries, its on VM :D
12:01 karolherbst: no.. what I meant is, how to you want to get nvidia to load your changes
12:01 karolherbst: because... there isn't really a way of doing that
12:02 karolherbst: you could probably intercept it through the VM and pass in whatever value, right
12:12 prOMiNd: I don´t want to modify the vbios, I want to poke registers realtime
12:13 prOMiNd: while running
12:16 karolherbst: good luck
12:17 karolherbst: keep in mind that some of them might be just locked down and require a signed falcon binary to change
12:17 karolherbst: but that doesn't help us with figuring out the vbios tables ;)
12:19 prOMiNd: I don´t understand why nvidia keep that secret since you can only flash signed vbios
12:26 prOMiNd: karolherbst, you can determine memory vendor by parsing MISC timing set
12:26 prOMiNd: its always different for the 3 vendors samsung/micon/hynix
12:26 prOMiNd: [0x9a0248] A7442899
12:26 prOMiNd: => samsung
12:27 prOMiNd: [0x9a0248] 44441414 => micron
21:23 karolherbst: 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:24 imirkin: afaik we do
21:24 karolherbst: imirkin: https://github.com/mesa3d/mesa/blob/master/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#L113-L115
21:24 imirkin: you mean like rgba8, right?
21:24 karolherbst: yeah
21:24 imirkin: oh, for the no-ms case
21:25 imirkin: i know nothing about it.
21:25 karolherbst: :)
21:25 karolherbst: okay
21:25 imirkin: "it was like that when i got here"
21:25 karolherbst: I just got that pointed out
21:25 karolherbst: mhh, maybe it might be worth to dig into it
21:25 imirkin: for all i know, that blurry thing is no longer the case
21:25 karolherbst: ahh
21:25 imirkin: or it could be due to using the 2d engine for blits
21:25 imirkin: or due to some wholly other thing
21:26 karolherbst: mhhh
21:32 karolherbst: 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:33 imirkin: my knowledge of such things is limited at best
21:34 karolherbst: mhhh
21:34 karolherbst: maybe if I get bored enough I dig into that
22:35 karolherbst: sometimes I wished we would get something more meaningful than a "CTXSW_TIMEOUT" if an application hangs :/
23:23 imirkin: that means the context-switching firmware fails
23:23 imirkin: (or rather, times out)
23:24 imirkin: 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