00:20 imirkin: skeggsb: i'm planning on piping drm_connector_state through to nv50_sor_enable
00:20 imirkin: maybe use it instead of the encoder arg
00:21 imirkin: the docs say that atomic drivers aren't supposed to look at encoder->crtc
00:21 imirkin: which we currently do
00:22 imirkin: and i want some of the various bits of state stored in drm_connector_state for the infoframe
00:39 imirkin: skeggsb: any objections if i add drm_connector_state * into nv50_outp_atom?
00:40 skeggsb: hmm, probably no objection, that whole area is a bit sketchy anyway
00:41 imirkin: yeah, i'm having a bit of trouble grasping the concepts
00:41 imirkin: but i'll work it out
00:41 imirkin: in part, i don't understand the lifetime of drm_connector_state :)
00:42 imirkin: which has little to do with nouveau, more with my inexperience
01:36 imirkin: skeggsb: btw, any thoughts on how https://hastebin.com/raw/ajexitiwux could happen?
01:37 skeggsb: not really. is it reproducible though?
01:37 imirkin: happened once :)
01:37 imirkin: but it's not like the system had a ton of uptime
01:37 imirkin: it might have had something to do with enabling rotation
01:37 imirkin: (on fbcon)
01:38 skeggsb: wondering about that "reason 82".. going to assume we don't mask enough bits off and it's actually "2" (PTE), we could write off the end of the fb somehow when rotation?
01:39 imirkin: well, the rotation is handled by fbcon
01:39 imirkin: but perhaps some dims are messed up? dunno
01:40 skeggsb: yeah, nvgpu indicates "reason" (they call it type) should be &0x1f
01:43 skeggsb: oh, dear. and we're a bit wrong in other ways there too on pascal
01:50 imirkin: well, you probably know i'm not quite on pascal :)
01:50 imirkin: although i do have a GP108 board nowadays
03:01 imirkin: change of plan ... going to try to get 1024-sized luts next. seems like that should be easy. and semi-useful.
05:10 vicky__: Hi.I'm seeing this issue https://paste.debian.net/1087682/. Connected the hardware to monitor with hdmi cable. Is this related to https://www.spinics.net/lists/dri-devel/msg186875.html ? Thanks
05:11 imirkin: vicky__: which gpu?
05:13 imirkin: looks like when gr comes up, it fails bigtime. you can mitigate this by booting with nouveau.nofbaccel=1 nouveau.noaccel=1
05:13 imirkin: (but then you obviously lose acceleration)
05:18 karolherbst: imirkin: looks like a pascal one "gp100_gr_init"
05:20 karolherbst:thinks it would be probably best to just "optimize" secboot away as far as possible...
05:21 vicky__: imirkin: I was getting this error first
05:21 vicky__: [ 6.652669] nouveau 0000:06:00.0: Direct firmware load for nvidia/gp107/gr/sw_nonctx.bin failed with error -2
05:22 vicky__: I installed firmware-misc-nonfree from stretch-backports. Using a debain 9 system with 4.14 RT kernel
05:22 vicky__: Then the error was not seen. But ran into this backtrace
05:23 imirkin: yeah. it's a known issue.
05:23 imirkin: i think karolherbst has some patches
05:24 vicky__: imirkin: Okay thanks. Are the patches upstream? Similar issue was seen in https://www.spinics.net/lists/dri-devel/msg186876.html
05:24 imirkin: not upstream
05:25 imirkin: still trying to figure out when to do it, i guess
05:25 vicky__: imirkin: Okay
05:25 karolherbst: more like this: https://github.com/karolherbst/linux/commit/5f6bdd8f1cb0113ae54094f8b9aa7dac06f8b0e8
05:26 karolherbst: I wish I knew why it helps
05:26 karolherbst:can't even remember how he came up with that idea
05:27 vicky__: karolherbst: Thanks. Do you suggest to test with this one?
05:27 karolherbst: sure. Worst case, nothing changes
05:27 vicky__: karolherbst: Okay. Will test and update you.
08:00 pmoreau: karolherbst: I’ll rebase against tonight, so that it applies cleanly.
08:02 vicky__: karolherbst, imirkin : The patch worked. Not seeing the backtrace and display is seen in monitor. Thanks
08:02 vicky__: karolherbst: Would you upstream it?
11:47 minicom: Is there some good explanation how the proprietary driver interacts, in overview? I read there is some userspace library and a GPL kernel module that interact with some blob which resides in kernel space, but it's not really clear to me how it all works
11:49 diogenes_: also it provides VDPAU
12:33 RSpliet: minicom: The components are largely the same as nouveau has, but without the open-sourceness. The kernel driver handles hardware, and provides a per-context abstraction to any module that requires it.
12:33 RSpliet: Any consumer (be it the OpenGL userspace module, the VDPAU module, the X.org display module, OpenCL, CUDA,...) will communicate with that kernel part through what I presume is a combination of I/O through virtual filesystem nodes and systemcalls (IOCTLs) as customary in UNIX land.
12:35 RSpliet: Because a driver needs to be linked against a kernel, and NVIDIA doesn't want to ship a binary driver for every kernel out there in the wild, they provide a universal closed-source binary and a little bit of GPL "glue logic" to glue together the Linux mechanisms and their internal APIs.
12:35 RSpliet: Carefully crafted so that the glue logic can be linked against most kernels as part of the installation procedure while having to give away as little internal workings as possible.
12:49 kwizart: Hello, FYI, I've made this patch for 5.1x 4.19x 4.14x, but it seems like the issue I have will be fixed in another way:
12:49 kwizart: https://paste.fedoraproject.org/paste/V7L5Lpm5cUqaG1bLU6SSeA
12:49 kwizart: As https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.19.y&id=6687f3879fbb93a277f36dabe9298ca3367112e1
13:01 minicom: RSpliet: thanks for explaining :)
15:11 imirkin_: rhyskidd: https://envytools.readthedocs.io/en/latest/hw/pciid.html -- somehow the pci id table lists TU116 before TU117 in the pci id ordering?
18:49 pmoreau: karolherbst: You didn’t push any of the clover branch, did you?
18:50 karolherbst: pmoreau: nope
18:50 pmoreau: Okay, I’ll run the rebase now
19:07 pmoreau: karolherbst: Could you please check that the rebased “gallium: add blob field to pipe_llvm_program_header” for radeonsi still does what it’s supposed to do?
19:08 pmoreau: I had a merge conflict on that one; I think I ported all the changes I could find, but I’d like for you to check, to be certain.
19:24 karolherbst: pmoreau: looks fine
19:24 pmoreau: Thanks!
21:10 rhyskidd: imirkin_: yes. i understood that table (of late at least), listed parts within a family in numerical order, not release order.
21:10 rhyskidd: or have i missed the point of your question?
21:28 imirkin_: rhyskidd: i thought that table was in pci id order
21:30 imirkin_: which, coincidentally, frequently corresponds to family numerical order :)