00:53Lyude: skeggsb: looking at nouveau_connector_detect_depth() right now and noticed the "EDID 1.4 is *supposed* to be supported on eDP, but, Apple..." thing - hopefully it hasn't been too long since you added this, but do you think we can get rid of it?
00:54Lyude: I feel like we could just go with what the code currently does and default to 6 bpc if we don't get an EDID anywhere, also I realized that's forcing all laptop displays to 6bpp lol
00:54Lyude: *eDP laptop displays
00:57Lyude: nevermind, completely missed the early return when the edid provides a bpc. that makes a lot more sense :)
01:01imirkin: Lyude: i think that code is from ... name is escaping me, but the one guy who _REALLY_ cares about bpc
01:01imirkin: german-sounding name iirc
01:01imirkin: he basically goes around and fixes _weird_ errors in all the drivers, related to bpc, dithering, vblanks, etc
01:04imirkin: Mario Kleiner
01:05imirkin: i could be wrong. i'm almost sure he had some thing with forcing some Apple eDP thing. maybe it was on intel.
01:05airlied: he's great, esp when he interacts with corp devs, who think they understand vblank
01:06karolherbst: :D
01:10Lyude: imirkin: the authorship in the blame goes to ben-but either way the code actually makes sense now that i'm not missing the if (nv_connector->edid && connector->display_info.bpc)
01:10imirkin: ah ok
10:36AndrewR: hi all
10:39AndrewR: Now I have NVIDIA Corporation GT215 [GeForce GT 240] as secondary GPU :} mplayer + vdpau h264 decoding works (with DRI_PRIME=1, with dri3). But If try to quite mplayer or ffmpeg while they decode some 60 fps 1080p h264 file - I got hang ...something from kernel starts to eat one core of my 4-core AMD processor, it usually timeouts after some time, but then vdpau becomes unusable until reboot ...
11:49imirkin: AndrewR: confirm you're using mplayer and not mpv?
11:49imirkin: AndrewR: i've definitely seen hangs with vdpau ... i think dri3 plays into it somehow. i've never really tried vdpau + prime.
11:49imirkin: i expect that issues exist :)
11:50imirkin: that whole logic has bit-rotted quite a bit
11:54AndrewR: imirkin, I don't have mpv (yet)
11:55AndrewR: imirkin, if I pause mplayer with spacebar and then quit - it doesn't hang :}
12:05imirkin: yeah, dunno
12:05imirkin: can't look now anyways
12:05imirkin: let me know if you track anything down
12:06karolherbst: imirkin: in regards to the tegra modifier bug. Can we create a resource with pt->flags & NOUVEAU_RESOURCE_FLAG_LINEAR when pt->bin doesn't have PIPE_BIND_LINEAR set?
12:06karolherbst: that's the if (count == 1 && modifiers[0] == DRM_FORMAT_MOD_LINEAR) pt->flags |= NOUVEAU_RESOURCE_FLAG_LINEAR; condition inside nvc0_miptree_create
12:06karolherbst: or do we have to check pt->bind as well?
12:07imirkin: karolherbst: iirc the tegra "modifier bug" has nothing to do with modifiers...
12:07imirkin: it has to do with trying to render to a linear color buffer and depth surface
12:07imirkin: the hw can't do that.
12:07karolherbst: right
12:07karolherbst: but the tegra driver force that
12:07karolherbst: *forces
12:07imirkin: also, depth surfaces can't be linear.
12:07karolherbst: right
12:07imirkin: that's just not a thing
12:07karolherbst: but tegra _always_ requests linear for scanout
12:07karolherbst: always
12:08imirkin: as it should.
12:08karolherbst: sure, but we wouldn't grant it if it wouldn't
12:08imirkin: scanout is always linear.
12:08karolherbst: if we call into resource_create instead, we don't set the linear thing
12:08karolherbst: it's only the DRM_FORMAT_MOD_LINEAR which makes it linear
12:09imirkin: scanout has to be used with the linear modifier flag anyways iirc
12:10karolherbst: template= {reference = {count = 0x0}, width0 = 0x12c, height0 = 0x12c, depth0 = 0x1, array_size = 0x1, format = 0x2, target = 0x2, last_level = 0x0, nr_samples = 0x0, nr_storage_samples = 0x0, usage = 0x0, bind = 0x18000a, flags = 0x0, next = 0x0, screen = 0x0}
12:10karolherbst: but mhh
12:10karolherbst: the thing I am wondering about is that if we set MOD_INVALID it just works
12:10imirkin: then it's requesting scanout when it doesn't need to.
12:11karolherbst: yeah.. I will check what we do differently with INVALID
12:11karolherbst: but yeah..
12:11karolherbst: it's just that pt->bind & PIPE_BIND_LINEAR is false
12:12karolherbst: so we don't set NOUVEAU_RESOURCE_FLAG_LINEAR
12:12imirkin: iirc that's a bug
12:12imirkin: i don't think you should be able to set BIND_SCANOUT without BIND_LINEAR
12:12imirkin: anyways, dunno
12:12karolherbst: yeah...
12:12karolherbst: I have no idea either :)
12:13imirkin: it'd be a mistake to assume there's a simple solution here
12:13imirkin: first try to understand what it's trying to do
12:15karolherbst: mhh.. so this comes out of dri3_alloc_render_buffer
12:16AndrewR: imirkin, "ffmpeg: ../src/gallium/drivers/nouveau/nv50/nv98_video.c:56: void nv98_decoder_decode_bitstream(struct pipe_video_codec *, struct pipe_video_buffer *, struct pipe_picture_desc *, unsigned int, const void *const *, const unsigned int *): Assertion `ret == 2' failed."
12:17AndrewR: imirkin, while decoding via ffmpeg 2.8 AND using mplayer + vdpau output ....
12:17karolherbst: imirkin: reading the comment, the tegra driver tries to be smart about things
12:17imirkin: yeah, i definitely don't remember what that means :)
12:18karolherbst: so it gets called into tegra_screen_resource_create, but thinks it knows better requests DRM_FORMAT_MOD_LINEAR and calls into nvc0_resource_create_with_modifiers
12:20imirkin: it _has_ to get a compatible thing for the display side to work with
12:20AndrewR: karolherbst, also, distractor! doesn nv50 part of nouveau kernel driver set also PCI-E width (8x, 16x) ?
12:20karolherbst: nope
12:20karolherbst: apparently no hw is happy with it except.. some laptops
12:21imirkin: AndrewR: i haven't seen a case where pcie width wasn't already set to max anyways
12:21karolherbst: imirkin: macbooks :p
12:21karolherbst: saw them start with x1
12:21imirkin: i stand by my comment :p
12:21karolherbst: :D
12:21imirkin: (a) macbooks don't exist, (b) if they do, i haven't seen them
12:22AndrewR: karolherbst, well ..then it shouldn't limit it (just saw line saying .."[ 3845.050429] nouveau 0000:02:00.0: pci: set link to 5.0GT/s x255" and found it a bit strange ....
12:24karolherbst: ehhh
12:24karolherbst: the width gets ignored anyway
12:24karolherbst: but yeah..
12:24karolherbst: 255 is weird
12:24karolherbst: maybe the vbios specifies that
12:25imirkin: we do force things to PCIe 2.0 if they're not set that way already
12:25imirkin: as many tesla boards aren't
12:27Thog: Hello I have a little question about the acr bootloader blobs that can be found in linux-firmware. Were those extracted from drivers or provided by NVIDIA?
12:27imirkin: Thog: provided by NVIDIA
12:28imirkin: you can see the commits in the linux-firmware git tree
12:28AndrewR: karolherbst, also, I put little patch in 5.8+ kernel for 1) enabling core/shader reclocks on g92 and b) show vdec speeds in same debugfs file as other clocks (in linux-2.6/drivers/gpu/drm/nouveau/nvkm/subdev/clk/g84c, struct g84_clk) ... do you think vdec clocks are important enough for showing them?
12:28Thog: ah right thanks!
12:33imirkin: AndrewR: if it can be done without too much bloat, i think that'd be reasonable
12:35AndrewR: imirkin, I just changed line { nv_clk_src_vdec , 0xff }, into { nv_clk_src_vdec , 0xff, 0, "vdec", 1000 }, (like 3 lines before it) :}
12:42karolherbst: AndrewR: yeah.. I think it's fine, just wondering if we should do it for all gens :p
14:11imirkin: skeggsb: i'm seeing events accumulate in the ddx's "drm events" list over time
14:11imirkin: skeggsb: is there a chance that some events might get missed/deleted/etc by the kernel?
14:11imirkin: (like vblank events, etc)
15:46Lyude: imirkin: how exactly do you get to the admindb page? I thought it was https://lists.freedesktop.org/mailman/admin/nouveau
15:49imirkin: admin -> admindb
15:55Lyude: imirkin: gotcha, thanks!
15:56imirkin: it wasn't clear to me what the difference between those was, but i'm also not going to argue.
15:56imirkin: one is list admin, the other is list other-admin? who knows
15:57imirkin: it's mailman. best to not ask questions and just be happy you can log into it :)
21:57marcheu: daniels: I'm happy to not have to do any mailing list things at all
21:57marcheu: daniels: so yeah happy to move admin to whomever wants to do it