00:13 Lynne: JoshuaAshton: any reason you wouldn't want to use ffmpeg as a library to handle this?
00:38 JoshuaAshton: Lynne: I wanted to learn about this and encode seemed actually feasible to do myself, unlike decode
00:40 JoshuaAshton: I also have some other code which is a direct nvenc backend that I want to attempt to mirror the configuration of
00:40 JoshuaAshton: It's also doing direct Vulkan interop
00:44 JoshuaAshton: I also don't need anything else other than just nv12 -> bitstream
00:44 JoshuaAshton: such as audio or container or whatever
00:58 Lynne: ah, header parsing
02:41 karolherbst: is it a known issue that x86_64_test_base can't be rebuilt? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/53363448
02:51 karolherbst: DavidHeidelberg: ^^
04:24 JoshuaAshton: Lynne: I also wanted to manage slices directly and such, to do constrained encoding
04:24 JoshuaAshton: Not sure how to do all of that yet in vk video, just getting started ^^''
04:25 JoshuaAshton: There's also some weird requirements for stuff I need in the VUI params that are technically incorrect/weird but end up giving better results e_e
08:34 tzimmermann: javierm, since you offered to look over screen_info patches. maybe take a look at https://patchwork.freedesktop.org/series/128150/ and https://patchwork.freedesktop.org/series/128155/
09:59 airlied: sima: I might have dropped the ball on a tip merge, see imre patch, if you have a minute could you check
10:01 sima: airlied, I thought we've baked that one into a stable drm.git branch already, how is it back?
10:01 sima: also still very much in vacation mode, not sure the brain is much use ...
10:01 sima: but I distinctively remember having handled that one before holidays for some merge
10:02 sima: or at least looked at it
10:02 sima: airlied, maybe just time for some backmerging if this is a whack-a-mole one?
10:03 airlied: yeah I might have screwed it somehow today
10:03 airlied: when I merged fixes
10:04 sima: ah no I guess it's just a new conflict due to new patch, just looks exactly like one I've handled already
10:06 sima: airlied, if you're still awake enough, this should get it sorted https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html#removing-a-wrong-conflict-resolution
10:06 sima: otherwise I guess I'll try to boot the coding brain here for a bit
10:07 sima: at least from a quick non-awake check it doesn't look like one of the more tricky cases of butchered drm-tip
10:09 javierm: tzimmermann: sure, I will
10:10 tzimmermann: thanks
10:13 Lynne: JoshuaAshton: the API doesn't do slice encoding
10:19 karolherbst: need some review of CI related patches here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24386
13:03 aleasto: hi any idea why i wouldn't be getting emails about mesa activity on gitlab.freedesktop.org anymore? my notification settings look fine and haven't changed in forever
14:14 mort_: How does the whole GPU driver discovery thing work..? I have rockchip's libmali installed, so /usr/lib/lib{EGL,gbm,mali,GLESv2}.so is from libmali, yet glxinfo and chromium still claims that the OpenGL provider is llvmpipe
14:19 kwizart: mort_, what is eglinfo output ?
14:20 mort_: https://p.mort.coffee/ejY
14:20 mort_: those warnings are potentially interesting
14:22 mort_: no, the errors are all about NPU stuff which isn't interesting
16:08 alyssa: jenatali: ugh.. why is the polygon stipple lowering like this..
16:08 jenatali: alyssa: I didn't write it, Collabora wrote that for us
16:08 alyssa: kusma: zmike: is there any prior art for polygon stipple in zink? if not, patch probably coming from me, I'm annoyed by TGSI code again
16:09 zmike: I think only line
16:10 alyssa: that's what I thought. guess I'm going to become a zink developer then (-:
16:10 zmike: welcome aboard
16:11 alyssa: choo choo
17:57 YaLTeR[m]: oh, I got nickserved
17:57 YaLTeR[m]: Hi, is there some existing bug for AMD-specific modifiers seemingly not matching between AMD iGPU and dGPU on the same laptop (lenovo legion 7 gen 7 amd)? Clients glitch out pretty hard in wayland compositors for me when sampled from a different device and not using a Linear modifier (i.e. iGPU client sampled on dGPU or vice versa)
18:03 mort_: I love that glmark2-es2 causes X to segfault in OsLookupColor now that I have mali drivers
18:08 MrCooper: YaLTeR[m]: it could be that the modifier involves some metadata such as DCC, which would need to be resolved before the other GPU samples from the buffer, but this isn't happening; does AMD_DEBUG=nodcc avoid the issue?
18:09 MrCooper: mort_: OsLookupColor is likely a red herring, it's the symbol which tends to get picked up in xserver backtraces when it's actually unknown where it is
18:10 mort_: oh, good to know
18:11 mort_: looking at it with gdb, it seems like somewhere in libmali.so.1 tried to jump to address 5
18:12 YaLTeR[m]: MrCooper: I set AMD_DEBUG=nodcc on both the compositor and the clients, didn't seem to affect anything
18:16 mareko: AMD_DEBUG doesn't affect modifiers
18:18 mareko: driver bugs with modifiers are likely
18:19 mareko: this needs to be a bug report, describing the specific GPUs used
18:21 YaLTeR[m]: Alright, I can open one, presumably in drm/amd. Anything else I should mention/attach?
18:21 mareko: under mesa would be better
18:21 mareko: screenshots or photos of the problem
19:20 YaLTeR[m]: filed: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10390
19:45 mihir: Hello
19:45 alyssa: zmike: Who's responsible for the GL CTS?
19:46 alyssa: It appears to be impossible to submit bug fixes for bugs older than 7 years :clown:
19:47 zmike: "responsible" is a very strong word
19:47 zmike: what is the issue you are having
19:48 mihir: I am Mihir, from India. I want to contribute to Xorg under Piglit for OpenMAX and Piglit for VA-API for EVoC. Where cam I find the maintainer and start contributiong, Is there anything I should know beforehand ? Thanks a lot for any help...
19:48 alyssa: opengl-cts-4.6.0 (from 2017) is not withdrawn, so bug fixes have to be targeted there
19:48 alyssa: but that branch no longer builds because of externals 404'ing
19:49 zmike: "have to be" is a strong interpretation
19:49 zmike: my understanding is it's not possible to withdraw GL CTS versions
19:49 zmike: like...ever
19:50 zmike: so each branch is effectively its own thing, and it's a best-effort kind of thing as far as backports go
19:50 alyssa: I'm just reading what the cts wiki says..
19:50 zmike: yeah, but I think that wiki is mostly targeted at current khronos api cts
19:51 zmike: i.e., not ones that are in maintenance mode
19:51 alyssa: ..alright
19:51 alyssa: what branch do I target then?
19:51 zmike: the earliest one that's viable
19:52 zmike: I'll try and raise a thing for updating the 4.6.0 branch I guess since in theory it should work
19:52 alyssa: TBH I don't understand the CTS release model, at all
19:52 zmike: it's not the most uh...
19:52 zmike: intuitive model
19:53 glehmann: does intel have public ISA docs?
19:53 alyssa: zmike: I'll target 4.6.3 I guess and hopefully nobody complains
19:55 zmike: generally speaking, I think everyone who's anyone is doing their conformance runs against the latest version
19:55 alyssa: Yep
19:56 zmike: ...potentially because it's the only one that builds
19:56 alyssa: Yep
19:56 zmike: very GL
19:56 alyssa: Maybe we should just update the wiki then?
19:57 zmike: that's not an update that can be made without due process
19:57 zmike: I'm starting the wheels in motion to see whether it's possible, but I don't imagine we'll have a concrete answer before 2030ish
20:00 cmarcelo: glehmann: https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/overview.html and the same docs organized differently are in https://kiwitree.net/~lina/intel-gfx-docs/prm/
20:00 cmarcelo: glehmann: the "Render Engine" pdfs will have higher level descriptions, the detailed descriptions of Instructions and Structures are in the respectively named PDFs.
20:01 alyssa: zmike: understood
20:05 glehmann: cmarcelo: thanks