00:48v4rg4s: hello, I am trying to setup mesa here to learn how to write code for it. I wrote a simple vulkan app and I am trying to use mesa that I built to debug the code with it, so I can follow the logic. I noticed that mesa gives me a compile_commands.json but it does not seem simple to load a clion project with it together with my own sample app. How are people setting clion up?
00:52anholt: I don't think many of us launch stuff out of an ide. generally you meson devenv -C builddir <application> to run stuff.
01:03karolherbst: v4rg4s: you might want to use meson extensions for a more integrated experience, otherwise you'll have to wire up all the custom commands yourself
01:04karolherbst: e.g. the meson VScode extension generates a "meson-vscode.env" file that simulates `meson devenv`
01:04karolherbst: so you can use it as an env file to debug tragets
01:04v4rg4s: thanks anholt, karolherbst. I am investigating anholt suggestion =)
01:05karolherbst: yeah.. not sure if that integrates well with the debugging UI...
01:06karolherbst: all that the vscode extension does is to execute "meson devenv -C builddir --dump --dump-format vscode" anyway
01:06v4rg4s: hmmmmm, let me take a look on it
01:08karolherbst: I'm sure clion allows you to specify a file with environment variables in it. If you use that when debugging your target, it should just load your locally built mesa
01:09karolherbst: for rust code (that mesa also has for some drivers) there is a "rust-project.json" file generated in the build directory you'll need to configure rust-analyzer against
01:09karolherbst: but I think that only matters for actual development
01:10karolherbst: anyway, I'm using vscode and the support might not be perfect, but it's good enough
01:56Company: karolherbst: vscode on Windows or vscode on Linux?
08:18MrCooper: tokyovigilante: assuming you mean the KMS colour pipeline, the idea is that the driver exposes one or multiple pipelines which reflect the HW capabilities; the set of elements which can be in a pipeline and their properties can be extended in the future as needed for that
10:46tokyovigilante: MrCooper: thanks yup I do. there's wlr_gamma_control on wayland but that doesn't look too-well supported
10:49MrCooper: Wayland compositors can make use of the KMS colour pipeline for various functionality, in particular the color-management protocol
10:52phasta: Can someone please review my todo list entries?
10:52phasta: https://lore.kernel.org/dri-devel/20251107135701.244659-2-phasta@kernel.org/ 10:52MrCooper: tokyovigilante: I'm not familiar with the details of wlr_gamma_control, the name suggests it probably doesn't require the KMS colour pipeline but can work with older KMS functionality though
11:09pq: tokyovigilante, wp_color_management_v1 supports custom 1D LUTs only through ICC profiles for now. For the non-ICC interface, it's not difficult to add new parametrized transfer functions, but they will also need implementing in compositors.
11:11pq: tokyovigilante, as for DICOM specifically, the model seems to have many constant parameters and maybe some variable ones? Firefox didn't render the equations unfortunately.
11:13MrCooper: pq: per above, apparently the question was about the KMS colour pipeline
11:15pq: and then they mentioned wlr_gamma_control
11:17pq: Setting up the DICOM gray curve on the display wouldn't do much good if it cannot be communicated to clients, nor if clients cannot tag their surfaces with it. One would need to run the system without color management.
12:42daniels: btw, this contains a bunch of fixups and everything we've been using internally for a while; I'm just trying to reconcile the GitLab CI pipeline with the changes they made in between version 5.1.5 and the different codebase also declared to be version 5.1.5 https://gitlab.freedesktop.org/daniels/gfxbench 13:58tzimmermann: sima, you deprecated kdb support in drm in commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers") i'd like to ask for your ack on the series at https://patchwork.freedesktop.org/series/158031/ so that we can finally remove the code
14:00sima: tzimmermann, oh wow, nice piece of analysis and digging
14:00sima: a-b: me on the entire series
14:01tzimmermann: thank you
14:04sima: tzimmermann, feel free to upgrade to r-b on the last two, I did grep around a bit for that
14:04tzimmermann: i'll do.
14:04sima: and noticed that I think you can also delete the vt code, since fbcon was the only implementation of consw->con_debug_enter/leave
14:05sima: so a bit more code that can be nuked I think, unless I'm blind
14:06tzimmermann: sima, i do have a patch for this. but it's a different subsys, so it's not included
14:06sima: oh ime gregkh is very happy to ack these for merging through drm
14:06sima: between drm and him we defacto maintain that mess more or less
14:06tzimmermann: lol :D
14:06sima: especially if you have the prep patches already merged through drm-misc
14:06sima: yeah, I have regrets
14:07sima: so just ping me with a link so I can stamp that too and then just get an ack from gregkh
16:50robclark: daniels: Oh, https://gitlab.freedesktop.org/daniels/gfxbench .. how did I not see that before
16:57anholt: bsd 3 clause?
17:04alyssa: woah?!
17:07alyssa: checks out https://github.com/Kishonti-Opensource/gfxbench 17:07daniels: pros: you can see the code
17:07daniels: cons: you can see the code
17:07robclark: lol
17:08alyssa: legit
17:09alyssa: I never could get gfxbench running on asahi under any translation layers, this seems fun
17:10daniels: MRs welcome, and happy to move it to gfx-ci namespace or whatever - I only forked it out here because the original repo is read-only, and the announcement was a pretty clear 'we're out, and we're just throwing this over the wall'
17:11alyssa: daniels: congrats you are the new maintainer of gfxbench
17:12daniels: (it really should use ci-templates as well; I only skipped that Collabora's internal GitLab had the runner capacity, and those pipelines ran approximately once every never)
17:12alyssa: incidentally, was it you who told me years ago you were done accidentally becoming maintainer of random old things?
17:12daniels: anholt: there's a MR on the way for https://gitlab.freedesktop.org/nuclearcat/gpu-trace-perf/-/commit/1d5b344994c7653997acdf723dc6915aa01e5c2f as well
17:12robclark: yeah, somewhere more global could make sense.. either way, nice to see this since benchmarking with gfxbench was a pain on !x86 if you didn't happen to have access to the src code via corp license