02:13luc: karolherbst: hi, could you please explain a bit what's mean by "<karolherbst> but if you installed it yourself, you have to enable the spirv-llvm-translator tooling before handling libclc", i suppose i encounter the same issue as FireBurn's before: there's no spirv-mesa3d-.spv and spirv64-mesa3d-.spv under my llvm install path /usr/local/share/clc,
02:13luc: i have managed to compile SPIRV-LLVM-Translator as llvm subproject following its readme, but still nothing but .bc files under /usr/local/share/clc, is there something i'm missing?
02:16luc: here's how i build llvm-19.1.0: cmake .. -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD=“BPF;AMDGPU;host” -DLLVM_ENABLE_PROJECTS="clang;libclc“ -DLLVM_BUILD_RUNTIME=OFF -DLLVM_USE_LINKER=mold -DLLVM_ENABLE_DUMP=ON -DCMAKE_INSTALL_PREFIX=/usr/local
07:00mlankhorst: Gah, forgot to actually send the pull-request yesterday..
08:56karolherbst: luc: need to enable the spirv libclc target
08:58karolherbst: https://github.com/llvm/llvm-project/tree/main/libclc
09:08luc: karolherbst: yes, but in my case, -DLIBCLC_TARGETS_TO_BUILD="spirv-mesa3d-;spirv64-mesa3d-" still fails.
09:08karolherbst: how does it fail?
09:09luc: it ends up the problem is cmake
09:10luc: when SPIRV-LLVM-Translator is built as LLVM subproject, its cmake project name `LLVM_SPIRV` and libclc's cmake `find_program(LLVM_SPIRV llvm-spirv PATHS ...)` seem to have cmake confusing, in my case, cmake always failed to find llvm-spirv. the workaround is renaming LLVM_SPIRV to LLVM_SPIRV_XXXX in libclc CMakeLists.txt
09:12luc: as long as rename LLVM_SPIRV in libclc find_program, it works
09:17tzimmermann: javierm, jfalempe, thanks for reviewing
09:17jfalempe: tzimmermann: you're welcome.
09:18tzimmermann: jfalempe, have a minute?
09:18jfalempe: Sure,
09:19tzimmermann: jfalempe, i've recently tried to untangle the POST code in the ast driver. specifically the file https://elixir.bootlin.com/linux/v6.15.3/source/drivers/gpu/drm/ast/ast_post.c
09:19tzimmermann: and i've notived that some code does not seem to handle AST2600 at all
09:19tzimmermann: even though it should
09:20tzimmermann: in ast_set_de_ext_reg(), there are special cases for AST2300 to AST2500. but AST2600 then uses values for old AST2000
09:20tzimmermann: https://elixir.bootlin.com/linux/v6.15.3/source/drivers/gpu/drm/ast/ast_post.c#L43
09:21tzimmermann: it's the 'if (IS_AST_GEN)' cases
09:22tzimmermann: ans the same happens in the dram-post code, which handles AST2500 but uses old values for AST2600
09:22tzimmermann: https://elixir.bootlin.com/linux/v6.15.3/source/drivers/gpu/drm/ast/ast_main.c#L213
09:22tzimmermann: jfalempe, i've reached out to aspeed but got no answer so far. should we attempt to fix this?
09:24jfalempe: tzimmermann: I think the ast2600 support was a bit hacky when added, and I remember there was already other places when it was not handled properly.
09:24tzimmermann: right IIRC
09:25javierm: tzimmermann: you are welcome. I still have a couple of your patch series in my TODO to review. At least I could go through some of them
09:25jfalempe: So the choice is to risk some regression by fixing the code.
09:25tzimmermann: javier, yeah there's a vesadrm series :)
09:27tzimmermann: jfalempe, i'd send out my cleanup first. on top of that, a 'fix' could be done easily on top without Fixes tag or backports. we could revert that as needed
09:27tzimmermann: would that work for you?
09:27jfalempe: tzimmermann: I can help to test on a few ast2600 model, to spot regression early.
09:28tzimmermann: sure, that's welcome. i do have a dev board as well
11:36zamundaaa[m]: <Xan[m]> "this is the correct room to..." <- This can be the right place to talk about such problems, but an issue on the relevant kernel driver's gitlab repo is better
12:44zamundaaa[m]: It's not a single bug, it's the end result of multiple hard to debug issues
12:48MrCooper: FWIW, not seeing their messages on IRC
13:33karolherbst: probably needs to authenticate on the IRC side
13:50dwfreed: indeed, this channel is +M and they are not identified
13:50karolherbst: I wished the matrix bridge would tell users :)
13:51dwfreed: I wish the matrix bridge would do a lot of things, but at this point my biggest wish is that it would just die
13:51karolherbst: you have the power to just block it tho :P
13:51ukleinek: then all the people who wail about it should better die, too I guess :-)
13:52karolherbst: the bridge has many issues and apparently they are ignored and I don't have enough spoons dealing with it myself
13:54karolherbst: like imagine you have a chat room, and then some software (e.g. facebook) bridges it and lets its user interact. But your moderation tools don't work on the some software (e.g. facebook) side, so now you are forced to deal with spam there. That's the matrix bridge.
13:55karolherbst: anyway... if there is _anybody_ willing to fix those issues, please you'll get my infinite gratitude. Heck, I'd even pay for it.
13:57dwfreed: karolherbst: people tend to get cranky when we do things unilaterally, though
13:57karolherbst: yeah I mean.. for sure
13:58karolherbst: people are also being cranky having to deal with the bridge... like I have nothing against it if it would have been opt-in from the start with a disclaimer on what additional obligations that comes with
13:58karolherbst: or well... seeing issues being addressed
14:01dwfreed: You're not wrong; and I think at this point most of our communities that have a larger matrix presense are no longer using the matrix.org bridge
14:01dwfreed: I'll probably bring it up in a month ish after my vacation
14:03karolherbst: at least the spam issue is hopefully? solved? Dunno who keeps an eye on it
14:04dwfreed: It isn't, we still regularly get matrix spam
14:04karolherbst: I thought a spam bot was set up on the matrix side to deal with it, though no idea how reliable that one is
14:05dwfreed: some communities run mjolnir on their matrix rooms
14:05karolherbst: yeah, I think somebody set it up for this channel, but I forgot who that was
14:32robclark: daniels: I guess __DRI_IMAGE_FORMAT should == PIPE_FORMAT these days? So should I just remove the dri format from dri2_format_mapping before adding new entries?
14:50MrCooper: I suspect so, see also the thread starting at https://gitlab.freedesktop.org/mesa/mesa/-/issues/12626#note_2785947
14:58robclark: hmm, BE strikes it's head again.. maybe the format table needs to have some ifdef for BE vs LE.. but since the __DRI_IMAGE_FORMAT_x's are 1:1 with PIPE_FORMAT_x it seems to be fine to drop that and simplify the table.
14:59robclark: (also the reverse component order in the naming between drm and pipe is giving me a headache ;-))
15:01MrCooper: per my comments re this topic, different variants per endianness shouldn't be necessary
15:02MrCooper: since there are endianness-invariant mappings between DRM & pipe formats (at least the common ones)
15:05robclark: hmm, ok, so as long as we don't use the "native endian" variants of PIPE_FORMATs (ie. PIPE_FORMAT_BGRA8888_UNORM, etc) we should be good
15:08robclark: hmm, but the format table is currently using PIPE_FORMAT_BGRA8888_UNORM, etc :-/
15:12robclark: hmm, and also the __DRI_IMAGE_FORMATS only match for rgb, it is kinda a miss-mash for yuv
16:40robclark: hmm, https://patchwork.freedesktop.org/series/130386/ appears to have been dropped. Any volunteer to push it to drm-misc?
20:51karolherbst: zmike: there ya go, I did it, probably in the worst possible way: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35806
21:46Wolf480pl: noob question about MR workflow: when I push a "v2" of a patchset, should all commits have "v2" in their name, even ones that I didn't change, and ones that did not exist in v1? Or do I version each commit separately?
21:56austriancoder: how should I handle this xfb case? output1: buffer=1 offset=0, location=2, component_offset=2, component_mask=0xc, stream=0
21:57austriancoder: component_mask of 0xc with an offset of 2?
22:06austriancoder: I see this pattern with dEQP-GLES3.functional.transform_feedback.array.separate.points.lowp_vec2
22:09zmike: karolherbst: thanks I hate it
22:10karolherbst: runs unigine heaven, I think my job here is done :P