03:30 sassefa: So encountering something weird. Still working on my version of drm_info but I'm having an issue. When I'm parsing properties, it seems that atomic values do not show up?https://i.imgur.com/xHKndXa.png
03:32 sassefa: From this line: https://gitlab.com/surafel911/drm-playground/-/blob/main/3-drminfo.c#L573. From looking at the source for drm_info I don't think I'm missing any flags, and drm_info is able to find those properties
03:32 sassefa: https://i.imgur.com/xHKndXa.png https://i.imgur.com/KwTjvd1.png
03:33 sassefa: Can anyone help me figure out what I'm doing wrong?
05:53 linkmauve: sassefa, this repository isn’t available, you probably have it set to private.
08:12 emersion: tzimmermann: i think you missed the overview docs in v2?
08:14 tzimmermann: emersion, i did not see any reference in the overview
08:14 tzimmermann: i grepped for fd_to_handle and handle_to_fd
08:18 emersion: tzimmermann: https://dri.freedesktop.org/docs/drm/gpu/drm-mm.html#overview-and-lifetime-rules
08:20 tzimmermann: emersion, that paragraph had already been cleaned up in v1
08:20 tzimmermann: all i found were references in some function docs, which i fixed
08:24 emersion: tzimmermann: hmm, in which patch? i can't see it :/
08:27 tzimmermann: emersion: https://patchwork.freedesktop.org/patch/542629/?series=119377&rev=1
08:27 tzimmermann: in drm_prime.c
08:27 emersion: oh, burried inside the driver updates
08:28 emersion: good
08:30 tzimmermann: ok :)
08:33 tzimmermann: javierm, i'd like to merge my series for omitting the fbdev userspace interfaces. there's one small patch that still requires an a-b. may i ask you to take a look at https://patchwork.freedesktop.org/patch/542327/?series=118872&rev=3 ?
08:53 mlankhorst: Forwarded drm-misc-fixes. :-)
08:53 mlankhorst: Always great when that happens!
09:15 jfalempe: tzimmermann, I've tested your ast refactoring on AST2600, it works good.
09:16 tzimmermann: jfalempe, great. thanks
09:16 jfalempe: And this Family/chip name refactoring is a big improvement.
09:16 tzimmermann: TBH i expect more refactoring. but hopefully this is a first step
09:16 jfalempe: I remember having an isuse on ast2600 because of this confusion.
09:17 tzimmermann: jfalempe, i've been wondering about this code: https://elixir.bootlin.com/linux/v6.3.8/source/drivers/gpu/drm/ast/ast_main.c#L99
09:18 tzimmermann: it's only on the 2500
09:18 tzimmermann: not the 2400 and not the 2600
09:18 tzimmermann: any idea what it might be for?
09:19 jfalempe: from what aspeed engineer said, P2A is a big security hole, and is not used anymore.
09:20 jfalempe: so it's only for selected motherboard that didn't get a bios update to disable it.
09:21 tzimmermann: i see. no wonder that the 2600 doesn't have it
09:23 tzimmermann: jfalempe, in the long term, i want to split the code by chip generations. so most of these branches will go away. it will become similar to mgag200. then new gens can be added without interfering with the older gens
09:27 jfalempe: tzimmermann, I found the reference: https://www.spinics.net/lists/dri-devel/msg350097.html
09:28 tzimmermann: thanks
15:06 consolers: if i have mesa-22.3.x shouldnt it have GL version 4.4 ? and shouldn't libGL have glGetQueryObjecti64v ?
15:06 psykose: it depends on which driver you are using
15:09 MrCooper: consolers: the libGL.so.1 ABI does not directly expose most non-ancient GL entrypoints, need to use GetProcAddress (and check that the advertised GL version and extensions actually cover the entrypoint)
15:18 consolers: i'm using iris but i'm trying to understand how it works during compile time
15:20 consolers: so I can't just use -lGL
15:20 HdkR: Indeed, need to use GetProcAddress for a bunch of newer entrypoints. libepoxy can help with that.
15:21 jenatali: Out of curiosity, does anybody know the reason why that's true on Linux? I know why it's true on Windows (because we stopped caring about GL after 1.1...) but I don't know that I heard a reason why Linux does that too
15:24 HdkR: Stop people from breaking when they link against NVIDIA's libGL that exposes all symbols and now you get an inexplicable error when the application refuses to run for "no reason"? ¯\_(ツ)_/¯
15:25 HdkR: Always seemed to be the logic to me, but I definitely don't know what the Khronos decision was there.
15:27 jenatali: FWIW I think it's the right move, and it's a bit frustrating that CL/VK didn't follow that approach, which means that you need an up-to-date loader to use new entrypoints, and the loader version is determined by the driver version (on Windows)
15:34 HdkR: I've seen a few games that just ship their own version of the loader so they don't need to care about the driver/OS installing it
15:36 jenatali: Yeah. That's also awful
15:36 HdkR: Definitely adds its own set of problems
15:36 jenatali: Since old loaders won't necessarily be able to find new drivers, meaning they turned a short term compat problem into a long term one :(
15:38 HdkR: Those games end up on my shit-list for it :P
15:38 jenatali: I'm aware of NMS - what others are we going to have to fight with?
15:43 HdkR: Koi Farm, Shapez.io, Jupiter Hell, Darwinia, Transport Fever 2, CrossCode(? This is an html game though...), Terry Poorflyer
15:44 HdkR: SUPERHOT VR as well
15:44 jenatali: Awesome. Thanks
15:46 tleydxdy: does anyone know if calling ttm_resource_alloc with a existing bo->resource is proper? I'm trying to debug a null ptr deref in ttm_lru_bulk_move_del and it seem like that resource was never added to the bulk_move range
17:57 alyssa: jenatali: jinx
17:59 zmike: amazingly there are zero tests for the intersection of GL_CLAMP and txf
17:59 zmike: or maybe not that amazing since it's stupid
18:00 jenatali: Yeah, that kind of negative test is hard to think about writing
18:00 jenatali: "These things that are independent shouldn't interact"
19:08 emersion: sravn: thanks for the reviews!
20:41 karolherbst: Kayden, airlied: I think I want to wire up pipe_grid_info::last_block for iris and llvmpipe. I don't know how hard that would be to implement for iris, but I suspect in llvmpipe it's really just doing it inside the shader or would some shortcut be possible there?
20:48 airlied: karolherbst: is there a good test case for it?
20:49 sravn: emersion: You are welcome - needed some distraction from day-time job
20:49 karolherbst: there is a non_uniform_work_group binary in the CTS, I'll prototype against radeonsi as it already supports last_block
20:50 karolherbst: I still have to wrap my head around on how all has to look like, because it has annoying interactions with subgroups as well
20:50 airlied: karolherbst: I think for llvmpipe you should be able to do it outside the shader
20:50 airlied: cs_exec_fn would need changes I think
20:50 karolherbst: ohh.. by queueing less jobs?
20:50 karolherbst: right...
20:50 karolherbst: should be trivial then
20:51 airlied: job_info->block_size[0], job_info->block_size[1], job_info->block_size[2], would need to be reduced I'd expect for the last blocks
20:51 airlied: won't queue less jobs
20:51 airlied: just gives the cs exec a smaller block size for the last job
20:51 karolherbst: the thing is it's a 3d thing and you can end up with 8 different block sizes in total depending on where you are withing the grid
20:51 karolherbst: but yeah...
20:52 karolherbst: I'll play around with it then
20:54 airlied: yeah hence why I wanted a good test case :)
23:02 karolherbst: airlied: on radeonsi "PASSED 12 of 12 tests." :3
23:02 karolherbst: though I start to hate my function to calculate block and grid size...
23:03 karolherbst: but at least I think I understood what I have to set grid and last_block to
23:13 karolherbst: jenatali: do you have a proper algorightm which properly splits up global_size? Best one which also takes non uniform into account? Mine is kinda bad and I want to ditch it...
23:13 jenatali: We don't support non-uniform
23:16 karolherbst: mhh, should be fine though, depending on the algo it's easy to add
23:16 karolherbst: but yeah.. that kinda stuff is weird and I totally don't understand what e.g. intel is doing
23:17 karolherbst: it's also kinda odd that nobody tries to even consider subgroup sizes or something
23:17 karolherbst: but I guess everybody also just supports non uniform so....