03:04 imirkin: someone was asking about the h264 issue earlier
03:05 imirkin: rather unexpectedly, there's new information about it. it's very definitely reference frame mishandling.
03:05 imirkin: we ran into the exact same misrendering on the exact same videos on intel/crocus. this was fixed although not 100% clear "how", i.e. in a way that's transferrable to nouveau.
03:06 imirkin: i went back and found some notes that a very helpful nvidia engineer provided back when i was trying to get h264 to work on some of the tesla vp4 boards (which had nothing to do with that issue, ultimately, but is still a lot of useful documentation)
03:06 imirkin: unfortunately i'm not sufficiently strong on some of the details of h264 to make proper use of it
03:06 imirkin: i tried a couple of small things and they didn't work
03:08 imirkin: i've been away from irc for a couple weeks, let me know if i've missed anything else that would benefit from my response.
10:49 RSpliet: imirkin: welcome back! Nothing special I don't think. From my end I made an "interesting" observation on the 17th of December that when I set NvFbBigPage=16 on GK107, everything seems work.... apart from how the cursor is really really weirdly stretched out
10:49 RSpliet: https://imgur.com/a/Gj2UFiD that smudge on the right is my cursos
10:51 RSpliet: I think the short answer is "well, then don't set NvFbBigPage to 16", the default IIRC is 17 (?), but... well I just wonder if that means cursor is the only thing using bigpage (and not full-screen browser windows?) or whether we forget to configure the cursor subengine (?) for big pages of 64KiB rather than 128.
11:29 hell__: wow, poor cursor
11:31 RSpliet: I mean, I'm definitely doing something that nobody is supposed to do. I call it fuzzing :-P
11:31 hell__: do Nvidia GPUs have dedicated "planes" for cursors? that is, small resolution memory buffers used to draw cursors (mouse pointer, or maybe text cursor)
11:31 RSpliet: I believe so yes
11:35 hell__: I imagine that the mouse pointer appears just fine in screenshots
11:41 hell__: I'd take a photo through a magnifying glass to see the actual pixels, in order to try looking for a pattern
13:07 RSpliet: Oh no it's pretty clear that the pitch is just off, and because the cursor buffer is a power of two it shows as vertical gaps. But whether that goes wrong with the upload or with the compositing I don't know..
13:29 hell__: ah, yes
14:22 imirkin: RSpliet: more of an explicit setting ... iirc we just force it to 128kb?
14:25 imirkin: RSpliet: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3999c1f7bbbc100c167d7ad3cd79c1d10446ba2
14:25 imirkin: RSpliet: my guess is 128x128x4 = 64kb?
14:26 imirkin: (yes, it is)
14:26 imirkin: so that cursor uses a large page
14:26 imirkin: and the cursor stuff isn't ready for large pages
14:26 imirkin: RSpliet: if you used xf86-video-nouveau, it'd be fine :)
14:29 RSpliet: Ok, that clarifies a thing or two. The tidy way is to have the fixme be a bit more intelligent at choosing a cursor size (could even pick large page size / 1024 for width and height, but that's a happy coincidence)
14:30 RSpliet: don't think wayland lets me use xf86-video-nouveau. And when I reverted to X.org and xf86-video-nouveau my desktop was hella-slow. Honestly it sound easier to not do the stupid thing of smaller large pages. :-P
14:30 imirkin: hehe
14:30 imirkin: well, if you can convince your compostior to use 64x64 cursors rather than 128x128, that'd also work
14:32 RSpliet: I still remember when I had to convince my compositor that my display shouldn't be driven at 4K@60Hz, because nouveau removed that option from the list for a very good reason.. that reason being GK107 + HDMI.
14:33 imirkin: "oops"
14:33 karolherbst: imirkin: what's the thing we would have to fix in mesa to make it work though?
14:33 imirkin: karolherbst: large page cursors on gk107?
14:33 karolherbst: RSpliet: ahh.. I think that's fixed now
14:33 karolherbst: imirkin: yeah
14:33 imirkin: er, kepler
14:33 imirkin: nothing in mesa
14:33 imirkin: either change the kernel to set the extra bit when a large-page-cursor is supplied
14:33 karolherbst: okay... ohh.. we don't use that huge cursors in the nouveau ddx?
14:34 imirkin: or change the bo allocation to not create large pages when allocating bo's for cursors
14:34 imirkin: but now that i think about it, the latter approach is impossible
14:34 imirkin: so nevermind on that
14:34 imirkin: userspace allocates the bo
14:34 imirkin: (yes, ddx only does 64x64 cursors)
14:35 karolherbst: 64x64 feels.... small, but on kepler you hardly have 4k displays anyway
14:35 RSpliet: can a cursor span multiple pages?
14:35 imirkin: could be a bo allocation hint, of course
14:35 imirkin: RSpliet: sure
14:35 karolherbst: but.. with future gens that will be a problem
14:35 imirkin: 64x64x4 > 4k i think
14:35 imirkin: karolherbst: problem only on kepler
14:35 karolherbst: I mean only having 64x64 cursors
14:35 karolherbst: or is that limited to kepler?
14:35 karolherbst: in the ddx
14:35 imirkin: oh. in the ddx, no
14:35 imirkin: the problem is only limited to kepler
14:36 karolherbst: yeah, I got the kepler part, was refering to the limitation of the ddx here :)
14:36 karolherbst: but I don't know how my cursor is sized here...
14:36 karolherbst: probably quite huge
14:36 imirkin: karolherbst: actually ... not sure that it limits the cursor size to 64x64
14:36 imirkin: would have to recheck
14:36 imirkin: definitely uses a 64x64 one by default
14:39 karolherbst: seems like mine is 24x24, so... it's actually 48x48
14:39 karolherbst: and some set bigger cursors..
14:39 karolherbst: gnome has some defaults here: 24, 32, 48, 64 and 96, and those get scaled up according to display scaling
14:40 karolherbst: so we might want to check if we actually support bigger cursors