01:16 tarceri: zmike: will take a look
01:16 zmike: awesome thanks
01:29 tarceri: might just be cts bugs, at least in this first test I'm looking at
01:44 tarceri: hmm fixed in the latest src it seems, let my pull and test again
08:20 sima: tzimmermann, mlankhorst misc pull for both trees?
08:20 tzimmermann: sima, dunno i'm on vacation this cycle
08:20 sima: jani, rodrigovivi, thellstrom intel stuff?
08:20 tzimmermann: nothing happend so far?
08:20 sima: tzimmermann, ah I guess it's on mlankhorst then since mripard doesn't seem around
08:21 chewitt: karolherbst in yesterdays nouveau related chat @lynxeye (not online) mentioned "you can't use a linear frontbuffer with depth"
08:21 sima: tzimmermann, yeah that's why I'm asking, but mlankhorst was here yesterday so I guess he can do the two (since there's a bunch in drm-misc-fixes too)
08:21 chewitt: is that a reference to zpos or using a format with alpha-channel, e.g. ARGB8888?
08:22 tzimmermann: sima, mlankhorst, i'm going to do -misc-fixes now.
08:23 tzimmermann: so that the most important is done at least
08:23 sima: I do have one from agd5f so I'll do a merge window fixes pr anyway later today
08:23 sima: tzimmermann, thx a lot
08:35 mlankhorst: Just contains my patches, I think. :)
08:36 mlankhorst: 'Fix tiled monitor setup on fbdev'
09:05 dj-death: if spirv-tools is too old on the alpine builders, what's the procedure to update it?
09:05 dj-death: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/69886963
09:05 dj-death: SPIRV-Tools doesn't contain https://github.com/KhronosGroup/SPIRV-Tools/pull/5534
09:20 jani: sima: what intel stuff?
09:29 sima: jani, there's not -fixes this week?
09:30 jani: sima: middle of the merge window? I guess could be -next-fixes
09:43 sima: agd5f, missing sob in your pull, only noticed now :-/
09:52 chewitt: lynxeye in yesterdays nouveau related chat you said "you can't use a linear frontbuffer with depth"
09:52 chewitt: is 'depth' referring to zpos or presence of an alpha-channel in the format?
09:53 chewitt: apologies if a dumb Q .. I am learning a whole heap 'o new terminology this week :)
10:19 lynxeye: chewitt: I think it was karolherbst who said that. The limitation on this hardware is that you can not have a linear rendering with a ZS buffer. So if your GBM surface only allows linear (due to missing or unsupported modifiers) things will break if you choose a EGL config with EGL_DEPTH_SIZE or EGL_STENCIL_SIZE > 0
10:20 chewitt: if i'm reading the code right (debatable) Kodi does check for modifiers, but only when atomic modesetting is used
10:21 chewitt: in this case the hardware is too old for that an we fall back to a legacy drm method which makes some assumptions
10:21 lynxeye: chewitt: If the application requires a ZS buffer for proper rendering, you need to supply modifiers that allow for buffer tiling. But honestly I have no idea what's the state of any modifier support on this HW generation in nouveau.
10:21 chewitt: this is the modetest output https://paste.libreelec.tv/sharp-moccasin.log
10:22 chewitt: I see no mention of LINEAR like I see with other devices I have
10:23 chewitt: there has been some fiddling with Kodi to add automatic plane detection/selection in recent times, which has had some fallout
10:24 chewitt: I have a hunch this scenario is one that falls down a crack in the logic and we end up trying to output ARGB8888 not XRGB8888
10:25 chewitt: but I'd be lying big-time if I claimed to understand the code
10:31 MrCooper: without modifiers and without GBM_BO_USE_LINEAR, the tiling parameters are up to the drivers
10:33 sima: chewitt, if I grepped kernel source correctly there's no modifier support for pre-nv50
10:33 lynxeye: But even then nv40 seems to only support linear for scanout. So if you are trying to render directly into the scanout buffer, you can not use depth/stencil.
10:34 MrCooper: wow, that sucks
10:35 lynxeye: Not a problem for weston on GBM, as IIRC it doesn't use ZS. But if Kodi uses ZS for rendering it will crash into the GPU limitation wall.
10:35 sima: lynxeye, oh it's actually the hw that can't do more, not just the kernel?
10:35 MrCooper: if so I'd say the Mesa driver should handle that via an internal tiled buffer, can't really expect apps to handle that
10:36 lynxeye: sima: At least mesa always allocates as linear when buffer usage is scanout.
10:37 lynxeye: Yea, internal shadow tiled buffer is what we do on etnaviv.
10:38 lynxeye: sima: It's more than 10 years since I actively touched any nv40 hardware, but IIRC it's really a limitation of the scanout HW.
10:39 sima: yeah don't see anything in the kernel either
10:39 sima: plus pre-nv50 is all legacy modeset, so extra fun to touch anything in there
10:41 sima: MrCooper, agreed
10:42 sima: mlankhorst, so you'll do a pr for -next-fixes?
10:43 karolherbst: chewitt: there is `nouveau.atomic=1` but not sure it works on that hardware
10:43 karolherbst: sima: ohhh.. right... pain
10:44 chewitt: support starts with nv50 according to chatgpt
10:48 sima: karolherbst, sad trombones for that still not being the default on at least modern chips
10:49 chewitt: I think Kodi is trying to set EGL_DEPTH_SIZE https://github.com/xbmc/xbmc/blob/master/xbmc/utils/EGLUtils.cpp#L304-L305
10:50 chewitt: nb: at some point many years ago this did work - i've used Kodi + nouveau + X11 on the original AppleTV box (GeForce 7300M) before
10:50 chewitt: that was c.2015 though .. there's probably been a few changes since :)
10:51 chewitt: in the Kodi log from the box https://paste.libreelec.tv/literate-mole.log I can also see:
10:51 chewitt: debug <general>: EGL_DEPTH_SIZE: 24
10:51 lynxeye: chewitt: With X11 you've likely got the DDX driver between the 3D rendering engine and the scanout, which might have done a copy between rendering and scanout buffer with the 2D engine. This might have circumvented this issue.
10:51 chewitt: debug <general>: EGL_STENCIL_SIZE: 0
10:52 chewitt: I've also had the user test an X11 image with 'legacy-x11-dri2' set in mesa config
10:53 chewitt: the Kodi and Xor.0.log now look sort of happy/clean, but the system log looks basically the same as the GBM image
10:54 chewitt: x11 image log: https://paste.libreelec.tv/pleasant-yak.log - scroll to "X.Org X Server 1.21.1.15"
10:55 chewitt: (or search for ERROR)
10:58 karolherbst: sima: I think we should just turn it on tho
11:02 sima: karolherbst, yeah probably the only way to find out if there's any issues left
11:02 karolherbst: it's using the same code internally anyway
11:51 pepp: is it correct to expect that a drm_sched_entity is not shared between multiple drm_file?
11:52 pepp: context: https://lists.freedesktop.org/archives/dri-devel/2024-November/477671.html
12:45 FireBurn: Has anyone seen weird rendering with GravityMark on the GL side of things on RadeonSI? The Vulkan stuff works great with Radv
12:55 FireBurn: I'm seeing misrendering on the GL stuff on 1.82 and 1.88 all the way back to 23.1 (I've not tested earlier)
13:57 karolherbst: gfxstrand: any concerns if I'd add a "deref_ptr_cmp"? Atm opt_deref can't handle it, if you compare two generic pointers, and one is global and the other is shared
13:59 karolherbst: not sure there is a better or less painful way of supporting it
13:59 karolherbst: especially if a NULL shared and a NULL global need to compare to equal
13:59 karolherbst: *true
13:59 karolherbst: uhm.. are considered equal I mean
14:00 karolherbst: even thogh their numeric value wouldn't be equal
14:03 karolherbst: mhhh actually.. might be a clang/translator
14:03 karolherbst: bug
14:45 mlankhorst: sima: ok sure, lets do one in a bit
15:04 FireBurn: The GravityMark is a RadeonSI ACO issue, everything works fine on LLVM
15:47 agd5f: sima, fixed up. sorry about that.
15:49 sima: agd5f, no worries and thx a lot
15:49 sima: mlankhorst, thx
16:01 sima: agd5f, aedf498a2c3334a8c1baca107e6f43cb1ca39d9a now has a Fixes: pointing to nowhere, but oh well
16:01 sima: probably need to get some of the dim checks into your workflow
16:06 sima: mlankhorst, you're summary missed the virtgpu and xlnx fixes, I'll add those
16:07 agd5f: sima, ugh, sorry, I can push out a fixed up tree if you like
16:08 sima: agd5f, already pulled
16:32 mlankhorst: sima: yeah, I think I mentioned it in the email?
17:13 alyssa: has anyone seen KHR-GL46.gl_spirv.spirv_glsl_to_spirv_builtin_functions_test fail with
17:13 alyssa: InternalError (Mappings for shader failed. at gl4cGlSpirvTests.cpp:1700)
17:14 alyssa: i'm thinking I have a botched CTS build or something but I'm not sure
17:14 alyssa: CTS commit 4705f248d ("Change GLSL->SPIR-V mapping of notEqual to OpFUnordNotEqual not OpFOrdNotEqual") looks relevant
17:19 alyssa: https://rosenzweig.io/0001-Fix-modf-mapping.patch fixes it for me
17:27 alyssa: not sure if that's already known or not
17:29 DemiMarie: From a compute perspective, how bad is pre-pinned memory management compared to HMM faulting?
18:31 bl4ckb0ne: is there a tool to track leaked resources with GL ?
19:50 pq: I couldn't find any bugs reported on lei anywhere, the Debian version was last updated a couple years ago, and it's warn that it may destroy where it can write to.
19:51 pq: *docs warn
19:52 pq: Would've been nice to have it write to an IMAP folder, but sounds too risky.
19:53 pq: maybe just a local maildir then...
23:28 sima: mlankhorst, I read that only after feeding the entire thing into dim ...