02:16 imirkin: karolherbst: linear depth buffers aren't a thing
02:17 imirkin: RSpliet: yes
02:17 imirkin: nv3x is GL 1.5, nv4x is GL 2.1
02:17 imirkin: both covered by the "nv30" driver
02:17 imirkin: nv3x is missing NPOT textures, which are a must for GL 2.0
02:17 imirkin: (and some other rather minor bits)
02:19 imirkin: Lyude: we support GL on all NV4 and up.
02:19 imirkin: nv4 - nv2x is covered by nouveau_vieux, nv3x/nv4x are covered by nv30
09:56 karolherbst: imirkin: mhh.. right
10:41 tagr: karolherbst: not sure if you're awake yet after that late night you pulled
10:41 karolherbst: I am...
10:42 tagr: karolherbst: oh... good =)
10:42 tagr: karolherbst: I was told that you may be looking at adding support for gv11b (for Tegra194)
10:43 tagr: I just wanted to mention that I had spent some time on that a couple of months ago and I do have patches that get the kernel driver to at least probe
10:43 karolherbst: yeah..
10:43 tagr: there's a few oddities in gv11b that are different from earlier chips that my patches addressed
10:43 karolherbst: I doubt I phrased it like that, but my intention was, that once we have firmware $somebody would be able to write patches :)
10:44 tagr: I didn't get all that far because I didn't know how to tackle the firmware loading, so I wasn't actually able to do anything useful with the kernel driver
10:44 karolherbst: ahh, right
10:44 karolherbst: but the firmware should be fairly identical to desktop voltas, no?
10:44 karolherbst: (ignoring different driver versions for now)
10:45 tagr: to be honest, I don't know
10:45 karolherbst: mhhh
10:45 karolherbst: anyway, now that we have volta/turing pretty much wired up I think it's just figuring out what interface the firmware binaries implement
10:45 tagr: I suspect that the steps to implement firmware loading would be similar to desktop GPUs, since my understanding is this used to be the case for earlier generations as well
10:45 karolherbst: meaning from which version they come from
10:46 karolherbst: but I think we should get to the point where the firmwares are just identical between desktop and tegra
10:46 tagr: karolherbst: ah... alright... back at the time I don't think there was much Volta support at all
10:46 karolherbst: and they just differ in from blob branch they come from
10:47 karolherbst: anyway.. I don't think it would be a huge problem now, just somebody needs access to the hardware and convince people to release the proper firmwares :D
10:47 tagr: do you mean the firmware interfaces should be identical between desktop and Tegra? I'm fairly sure that the firmware will have to be different in some aspects of the implementation, but I agree, it seems like a good idea to make the interface and loading code similar
10:48 karolherbst: yeah.. I don't think they were different in the past
10:48 karolherbst: they just came from different driver versions
10:48 karolherbst: but we have this issue anyway
10:48 tagr: I do have a local set of files that I previously extracted from the Android files, but yeah, it'd be best if we could have something officially released via linux-firmware.git
10:49 karolherbst: I think the issue is that the firmware files itself won't tell us? dunno
10:49 karolherbst: right
10:49 karolherbst: and if they are made public and they say "it's from the 450 driver branch, go nuts" that would be fine :D
10:50 karolherbst: but maybe we can also just use the firmware we already have?
10:50 karolherbst: I just don't know
10:50 karolherbst: with volta we don't have this PMU problem anymore
10:50 karolherbst: so things could just work
10:50 tagr: I think I've seen internal discussions around the firmware release for gv11b, but I don't know what the latest status is
10:51 karolherbst: tagr: you could maybe just wire secboot up like we do with gv100 and see how that ends up? although I can imagine that things are different enough between gv100 and gv11b :/
10:51 tagr: yeah, I'll try that
10:52 karolherbst: I suspect the firmware might load, but the runtime just crashes.. or the hw needs different signing keys or whatever...
10:52 tagr: karolherbst: I just sent out the new ABI proposal that I was talking about the other day, the one that allows synchronization to properly work between Nouveau and Tegra DRM
10:52 karolherbst: ahh, cool
10:53 tagr: I've accumulated a whole stack of Nouveau patches that I really want to flush out
10:53 tagr: seems like a bit of a waste to have done all that work and then not see it go upstream =)
10:53 karolherbst: yeah, quite so :D
10:54 karolherbst: mhhhh...
10:54 karolherbst: but... mhh
10:54 tagr: the new PUSHBUF2 seems a bit wasteful because it's basically the old PUSHBUF IOCTL, with just a bit added on top
10:54 karolherbst: yeah...
10:54 tagr: but I couldn't think of anything else that would be good to add
10:54 karolherbst: I think you want to sync up with skeggsb
10:55 karolherbst: the entire API will be reworked anyway
10:55 karolherbst: so we might want to consider this use case from the start
10:55 tagr: karolherbst: when I first proposed this a few years ago (looks like the original patch is from 2017!), Ben seemed to be roughly okay with the approach since it was reusing most of the PUSHBUF IOCTL code in the kernel
10:56 tagr: and, you know, it's useful by itself for this specific purpose
10:57 tagr: Ben had also mentioned that he was working on a new ABI, but like I said this was a long time ago and nothing happened, so I'm not sure if I should push for this or wait some more for something new in the hopes that it would solve the same issue
10:58 karolherbst: well, that's why I suggested to sync up with Ben :)
10:59 tagr: karolherbst: I haven't seen him around here in a while (though I guess that could just be because of the timezone delta), is there any better way to get in touch with him?
11:00 karolherbst: email
11:01 karolherbst: I suspect skeggsb will see your patches though :)
11:16 karolherbst: tagr: btw, I think I slowly understand why this depth/stencil bug is happening
11:16 karolherbst: we probably expose the wrong visuals
11:16 karolherbst: so the application requests a framebuffer with depth stencil
11:17 karolherbst: not sure if we could prevent that from happening
11:18 karolherbst: but getting rid of that should solve the issue. I just don't know if X applications require this
11:18 karolherbst: or if they just end up with this by coincidence
11:40 karolherbst: tagr: soo.. yeah.. what's happening is that clients just go with whatever visual and that happens to be one with depth or stencil bits, but we can obviously not scanout or use them as shared buffers if mesa ends up allocating a framebuffer based on such a visual
11:40 karolherbst: soo.. do you think it would be a viable alternative solution to just don't give such visuals to clients being modifier unaware?
11:41 karolherbst: that would probably just solve the entire issue without having to rely on detiling or whatever
13:45 karolherbst: tagr: yeah... so that works...
13:46 karolherbst: just rendering is broken.. mhhh :/
13:52 karolherbst: but anyway..I think I slowly start to fully understand the overall problem
14:31 tagr: karolherbst: I don't think the problem is that we can't scanout from buffers with depth/stencil bits
14:31 tagr: I think the problem is just that we can't render to buffers that are pitch-linear and that also have depth/stencil bits
14:32 tagr: karolherbst: I've just uploaded these: https://gitlab.freedesktop.org/tagr/kmscube and https://gitlab.freedesktop.org/tagr/mesa/-/tree/implicit-framebuffer-modifiers
14:32 tagr: those basically implement what I had proposed in the review of the X modesetting patches
14:33 tagr: I plan on also proposing the same changes to the X modesetting driver, which should be fairly minimal
14:33 tagr: karolherbst: I think this would be the ideal solution because it basically lets split render/scanout setups work very similarly to discrete GPU drivers
14:35 tagr: karolherbst: basically the semantic change would be for applications to allocate using gbm_bo_create_with_modifiers(..., NULL, 0) instead of gbm_bo_create(...) so that the driver understands that they can pick a modifier and that it will end up associated with the KMS FB
14:35 tagr: karolherbst: so that's basically the "implicit modifiers" support but in a way that gives the driver a hint to make the right decision
14:36 tagr: gbm_bo_create() always ends up calling ->resource_create(), and that has to always assume DRM_FORMAT_MOD_LINEAR for scanout because it doesn't know if any implicit framebuffer modifiers will still be passed on
14:37 tagr: so the idea is that ->resource_create_with_modifiers() will now always get called, even in the case where the application doesn't want to select a framebuffer modifier
14:37 tagr: but, the application can then allocate with gbm_bo_create_with_modifiers() nonetheless and just not specify any modifiers (NULL, 0) which tells the driver to pick whatever modifier it wants
14:37 tagr: but by doing so the application also signals that it will query the modifier from the allocated buffer/surface and then pass it on to KMS
14:38 tagr: which is what makes all the difference compared to the gbm_bo_create() case where basically the DRI driver doesn't have a clue about what's going to happen
14:39 tagr: with all of that in place, it should be a matter of a one-line fix here and there in some compositors to make this work properly
14:39 tagr: so it's not entirely a no-brainer, but I think it makes everything much more consistent than it now is
14:59 karolherbst: mhhhh
15:25 karolherbst: tagr: yeah.. I think I just wished there would be a fix not involving having to fix all users of the API :/
22:11 AndrewR: imirkin, will you merge those patches for dri3 cpu consumption (after dpms) ddx bug?
23:12 imirkin: AndrewR: yeah. first i want to test them out on my primary X server
23:12 imirkin: and i just haven't had a chance yet
23:12 imirkin: will try this weekend
23:12 imirkin: if all goes well, i'll push them out and make a release
23:13 AndrewR: imirkin, ok, and thanks for them!