00:17 JoshuaAshton: why did NV even do GL mesh shader
00:17 JoshuaAshton: In fact, why do they keep making new GL exts
00:17 JoshuaAshton: It's just a waste of time because there's literally no users for any of their new stuff... :/
00:18 JoshuaAshton: inb4 one single weird CAD software or something /shrug
00:18 airlied: CAD software is the reason for mesh shaders at all I think
00:18 airlied: so probably for some of those
00:21 airlied: bit also a change they developed the GL ext years ago during bring up to validate the hw :-P
00:51 cmarcelo: karolherbst or rusticl people: is there anything special to run OpenCL-CTS other than entering in meson devenv environment... /me trying to run ./test_basic. (I managed to run some other workload with rusticl, so rusticl itself works).
00:52 karolherbst: not really
00:52 karolherbst: you might have to set the CL device type though
00:52 cmarcelo: and I set RUSTICL_ENABLE=iris
00:52 karolherbst: it refuses to run on CPU devices in case you tried with llvmpipe
00:52 karolherbst: ahh.. that should be enough then
00:54 cmarcelo: I've build my own OpenCL-ICD per OpenCL-CTS instructions, think that could be harmful somehow...?
00:54 karolherbst: uh...
00:54 karolherbst: just use the system provided one
00:54 karolherbst: it's kinda weird.. but there is some differences in how env variables are parsed or something.. dunno
00:55 karolherbst: the devenv handling _might_ need some adjustments
00:56 karolherbst: dunno...
00:56 karolherbst: cmarcelo: you are using https://github.com/OCL-dev/ocl-icd ?
00:57 karolherbst: or https://github.com/KhronosGroup/OpenCL-ICD-Loader ?
00:57 cmarcelo: was using Khronos one. now trying with system
00:57 karolherbst: they do treat `OCL_ICD_VENDORS` differently and I think mesas way of setting it with devenv only works with ocl-icd
00:58 cmarcelo: wait, there are two loaders in CL?
00:58 karolherbst: yeah...
00:58 karolherbst: don't ask me why
00:58 cmarcelo: ok
00:59 cmarcelo: karolherbst: "BINGO!"
00:59 cmarcelo: it works now with system one. thanks :)
05:11 kode54: hmm
05:11 kode54: is anyone eventually going to implement the weird HuC loading that DG2 requires?
05:11 kode54: not-HuC is missing *little tiny things*, like bitrate control
07:37 MrCooper: deathmist1: then the epiphany issue is separate
09:19 jani: mripard: tzimmermann: mlankhorst: ack on merging these via drm-intel? https://lore.kernel.org/r/87wn0ofsba.fsf@intel.com
10:16 tzimmermann: jani, sure
10:16 tzimmermann: ack
10:16 jani: tzimmermann: thanks!
10:29 emersion: any chance to get this reviewed? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23144
11:36 Lynne: Venemo: made any progress with radv's dedicated transfer queue yet?
11:59 Venemo: Lynne: little bit but I don't yet have any code to try yet
12:00 Venemo: Lynne: it needs some refactoring still, and I have done some of that but not happy with the result
12:02 Venemo: my plan is to basically make a mix of SDMA and compute, where the problem cases would be done in compute
12:46 deathmist1: MrCooper: nope it's related, more progress on https://gitlab.freedesktop.org/mesa/mesa/-/issues/9141: disabling glthread for gnome-shell fixes the artifacting
12:47 deathmist1: while leaving it enabled globally otherwise that is
12:47 deathmist1: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19147 already did so for kwin_wayland, at this point I'm wondering if glthread is broken or if these wayland compositors are both doing something wrong?
12:49 Lynne: Venemo: is the problem the way that any non-graphics queue is specialcased in radv?
12:49 Lynne: I remember that was the case when debugging the mesh shader issues
13:58 cwabbott: gfxstrand: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301#note_1921031
13:59 mriesch: peculiar question maybe, but a) what entity allocates memory for an opengl context and b) what memory block size is typically used?
14:44 karolherbst: mriesch: what's the context of this question?
14:47 mriesch: karolherbst: opengl application that exhibits increasing shared memory consumption. i guess there is a memory leak in the opengl context (textures, ...?) but this needs some verification
14:48 mriesch: the stack is qt, weston, mesa, panfrost
14:48 karolherbst: soo, it's about CPU memory and a potential memory leak?
14:48 karolherbst: or well.. might be GPU memory as well
14:49 karolherbst: well.. you could either use a memory leak detector or file a bug or something
14:49 mriesch: i assumed that shared mem rather points to gpu memory, but feel free to correct me
14:49 karolherbst: shared memory as in Linux shared memory?
14:49 mriesch: yes
14:50 karolherbst: it's memory shared by processes
14:52 mriesch: karolherbst: well you can see that this is not exactly my area of expertise :-)
14:52 mriesch: i gave valgrind a shot, but couldn't find anything convincing between all those false positives...
14:53 mriesch: as to "file a bug", i wouldn't know where -> if my app and qt can be ruled out, it could be mesa (or something below), but that's a big if
14:54 mriesch: in order to narrow it down, i am reasoning a bit and came up with the questions above.
14:54 MrCooper: italove: the Gallium HUD changing the application behaviour seems like a bad idea, it means we have to be careful with asking to enable the HUD for narrowing down issues
14:55 mriesch: e.g., if mesa allocates the gl memory and there is a leak, will there be an increase in shared mem?
14:56 karolherbst: no
14:56 karolherbst: as I said, shared memory is memory shared between processes
14:57 karolherbst: just because shared memory is used, doesn't mean there is a leak neither
14:58 mriesch: karolherbst: the usage increases with a rate of approx 30 mb per second until the process is killed
14:58 mriesch: but ok, different question: can the gpu/gl memory usage be monitored somehow?
14:58 karolherbst: what's the application?
14:59 mriesch: a custom video player that takes frames from a gstreamer pipeline and renders them onto a certain geometry
14:59 karolherbst: might want to file a bug against that one
15:01 mriesch: karolherbst: yeah, it's my project, so any bug i'll file lands on my desk ;-)
15:01 karolherbst: would be kinda weird that something trivial like that would trigger memory leaking bugs inside mesa where running weston + other things doesn't?
15:02 karolherbst: but it kinda depends
15:02 karolherbst: I'd still suggest checking with valgrind and/or libasan and figure out any reachable or leaked memory
15:03 karolherbst: and cuming from a project not used by others it's highly likely it's just an application bug
15:04 karolherbst: maybe you are leaking each frame or something?
15:04 karolherbst: or it leaks inside gstreamer or.. somewhere
15:04 mriesch: karolherbst: definitely more likely than a bug in the stack below, but you never know
15:06 mriesch: and i thought that maybe one could trace when gl memory is allocated in order to find out what the application, gstreamer, qt, .. is doing wrong
15:11 robmur01: just an idle musing, but does disabling panfrost's BO cache (PAN_MESU_DEBUG=nocache) make any difference?
15:12 mriesch: robmur01: i can try that (on monday, though, i think i'll call it a week
15:14 robmur01: heh, good plan :)
15:15 MrCooper: mriesch: no matter how exactly "GL memory" is allocated, there's always some corresponding data structures in normal memory, so leaks of the former correspond to leaks of the latter, which can be caught by valgrind or sanitizers
15:18 mriesch: MrCooper: ok, i see. then i'll take another stab at that with valgrind
15:26 mriesch: ok, karolherbst robmur01 MrCooper thanks for your comments and have a nice weekend
15:26 MrCooper: no worries, you too
15:59 italove: MrCooper: I see what you mean, but if we just revert the patch the original problem will still exist: apps that use partial redraw have to disable it if they want to use gallium hud, because otherwise the gallium hud won't be drawn correctly. So, I'm guessing maybe the solution here would be to revert and then print some kind of warning when buffer
15:59 italove: age is queried if gallium hud is active? This way the user can manually override the extension if they want to get rid of the artifacts.
16:00 MrCooper: yeah maybe, or a GALLIUM_HUD option to disable buffer age
16:09 italove: MrCooper: the problem with just making it an option without a warning is that the user will have to first figure out that their artifacts are caused by the gallium hud not being accounted for in the buffer age.
16:12 MrCooper: true
16:28 benjaminl: lol no idea. I've seen exactly one use of this in the wild, which was for a minecraft rendering plugin: https://github.com/MCRcortex/nvidium
16:28 benjaminl: it kinda makes sense in that context, since the rest of the rendering pipeline is GL, and will be forever
16:29 benjaminl: (in response to earlier message about GL_NV_mesh_shader)
17:03 emersion: hwentlan_: might be interesting to you: [PATCH] drm/vkms: Add support to 1D gamma LUT
17:03 emersion: ah you were cc'ed
17:30 sassefa: Is there explicit documentation for libdrm? I see this link for Nvidia's DRM API but I don't see the freedesktop https://docs.nvidia.com/drive/drive_os_5.1.6.1L/nvvib_docs/DRIVE_OS_Linux_SDK_Development_Guide/baggage/group__direct__rendering__manager.html
17:30 sassefa: Trying to learn how to make my own impl of drm_info. So far I'm just browsing xf86drm.h and xf86drmMode.h manually trying to find the funcs I need
17:31 Venemo: Lynne: the current code only anticipates sumbitting graphics+compute together, and this needs to be extended to also support compute + sdma, this is what I meant by refactoring
17:39 benjaminl: sassefa: there are some man pages, but they aren't very comprehensive. I mostly just read the source code
17:39 benjaminl: the kernel docs are also useful
18:15 sassefa: do i respond to someone by putting their name first like this?
18:15 sassefa: benjaminl: thanks!
18:40 hwentlan_: emersion, thanks. that'll be useful
18:41 emersion: i think it's missing interpolation though
18:41 hwentlan_: that shouldn't be hard to add
19:10 gfxstrand: jenatali: RE https://github.com/microsoft/hlsl-specs/issues/30
19:10 gfxstrand: jenatali: We have NIR lowering for most of that stuff.
19:11 gfxstrand: Like the gradient stuff should be covered by the lower_txd_shadow option.
19:20 jenatali: gfxstrand: That requires being able to run calculateLOD on a comparison sampler, which DXIL also disallows
19:20 jenatali: jenatali: See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22839
19:20 jenatali: How did I tag myself... gfxstrand ^^
19:20 gfxstrand: lol
19:21 gfxstrand: IDK. I dropped the j a while ago. :-P
19:21 jenatali: Lol I misclicked I guess
19:21 gfxstrand: jenatali: Okay, that's a bit more nuanced understanding than I picked up elsewhere.
19:21 gfxstrand: Annoying.
19:21 jenatali: Very
19:21 jenatali: Those are our only failures :(
19:21 gfxstrand: So you can do everything, if only you had LOD on shadow samplers :facepalm:
19:22 jenatali: On WARP anyway, I haven't really been trying the hardware vendors since we added so many D3D features that haven't been implemented yet
19:22 jenatali: Yep pretty much
19:22 jenatali: If I turn off DXIL validation, it works fine on WARP, NVIDIA, and AMD, but crashes on Intel...
19:22 gfxstrand: And with limited sampler pools, I don't suppose you want to double up samplers just for LOD.
19:22 gfxstrand: Intel is being dumb. The instruction totally works. Probably something in their compiler.
19:23 jenatali: Yep, exactly
19:23 gfxstrand: Can you rush out a SM 6.7.1 that just adds the LOD thing? ;-)
19:23 jenatali: I take it that this discussion is because our potential waiver request made it to the working group? I hate not being able to participate directly...
19:24 gfxstrand: Yeah, I wasn't paying attention to my e-mail this week and just now saw it fly by.
19:24 jenatali: I tried. Our compiler team doesn't have a way to do that really. SM6.8 is due in the fall and should have these
19:25 gfxstrand: Trying to form an actual opinion based on all the information, not just the existential "OMG is this HW or SW?!?" crisis that the rest of Khronos is having. 😅
19:25 jenatali: :P
19:25 jenatali: I appreciate that
19:26 gfxstrand: I missed our Wednesday meeting where this was apparently discussed. I'll try to make sure I'm in the next one.
19:27 jenatali: Thanks. Hopefully we'll be able to set up a meeting where we can talk to the working group outside of the IP framework that gives our legal group heartburn
19:27 gfxstrand: Yeah. That'd be nice.
19:27 gfxstrand: We can have IP-free portions of WG meetings, they just have to be set up special.
19:27 jenatali: Yeah
19:27 jenatali: We've done it for CL and GL before
19:28 gfxstrand: Unfortunately, now that I do have all the information, you you may not like my opinion...
19:28 jenatali: That's fine
19:29 gfxstrand: On the other hand, if D3D doesn't have those sampler ops, the chances of apps making heavy use of them are low...
19:29 gfxstrand: GL just likes to ADD ALL THE THINGS
19:29 gfxstrand: Not being able to do LOD on a shadow sampler is really annoying, though.
19:30 jenatali: Yep, to all of the above lol
19:30 gfxstrand: IDK that apps want it, I'm just thinking from a layer/workaround perspective.
19:30 gfxstrand: That and TXS are our favorite tools for getting around texop weirdnes.s.
19:30 jenatali: Yeah txs is fine, it's just our shadow samplers that are... weird
19:31 jenatali: Whatever the working group ends up deciding, we'll obviously be beholden to, but I'd be doing us a disservice if I didn't try to plead my case
19:31 gfxstrand: Silly shadow samplers
19:31 gfxstrand: That's totally fair
19:32 gfxstrand: And whatever happens, this problem will eventually be behind us. Everyone can do LOD on shadows in hardware, we just need to bump all the versions of all the things everywhere and that takes time.
19:32 jenatali: Yep
19:35 jenatali: We added a bunch of features to D3D (https://github.com/microsoft/DirectX-Specs/blob/master/d3d/VulkanOn12.md) but modifying DXIL is so much harder for our team to manage since it's a different group :(
19:38 gfxstrand: Yeah
20:41 grillo_0: Hey emersion, I'm the guy from the VKMS 1D LUT patch. I think I can add the missing interpolation. This patch was part of a patchset that I'm working on, the patchset focuses on adding NV12 support to VKMS. The LUT was needed to make the test igt@kms_plane@pixel-format pass on the new format.
20:42 emersion: grillo_0: have you tried other tests with LUTs? are there some failing because of the missing interpolation?
20:43 grillo_0: I tried only the kms_color and pixel-format.
20:45 emersion: i'm not sure interpolation is actually required by the KMS API
20:46 emersion: the docs do mention interpolation
20:47 emersion: but in an indirect manner
20:50 grillo_0: Yeah, I didn't know that the interpolation was mandatory when working with LUTs, I will fix it :).
20:51 emersion: no worries, i'm not sure myself! and thanks for working on this :)
20:55 grillo_0: You're welcome :)