01:15robink: Hi, not sure where to raise this issue (it could be with Mutter or GNOME-Shell), but since upgrading Mesa & xorg-server (w/ libglvnd support), I've found that I can't get a GLX context from a Wayland GNOME session (XWayland is running), but I can when running GNOME from an Xorg session. Is there something that's likely to be wrong on my end, or is there something I can try to attempt to narrow down the cause?
01:52robink: n/m, someone on #gentoo-desktop figured it out. Seems to be related to bug 721702 (https://bugs.gentoo.org/721702) (upstream's problem, but reflected in the live xorg-server ebuild).
01:54robink: xserver issue at: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1032
02:35robink: Issue has been fixed upstream. xorg-xserver reinstalled from current Git master, GLX context on Wayland reacquired :)
10:08austriancoder: Kayden: so you use perf/tracpoints to see when a job gets executed - I only had a quick view over the sources yet. But how do you do load tracking? I want something like: https://showterm.herokuapp.com/fee222be96c97ebbed2d7#71
10:08austriancoder: I have one idle register where each bit represents one GPU internal component and to do load tracking I need to sample this register 100 times / second to get a nice % value. And this register can not be read via cmd stream.
10:32vsyrjala: austriancoder: the hw has piles of counters which it can sample and write to memory. iirc reporting can happen periodically or can be triggered from the cs
10:33vsyrjala: before this stuff we used to have a tool (intel_gpu_top in igt) that worked by sampling just bit per unit like you want
10:34vsyrjala: but polling those bits could hard hang the machine
10:38austriancoder: vsyrjala: the big problem is that the hw can not write the sampled data to memory - it must be done in sw. I thought about doing the sampling in the kernel and provide the data via a sane interface to the userspace - that would make this data also available to gallium hud and cli tools (without the need to do the sampling spread into different projects).
10:44vsyrjala: i915 exposes the counters are exposed to to userspace as something resembling the normal perf stuff
10:45vsyrjala: there was an attempt to integrate it fully with the perf stuff, but iirc it didn't quite work out
10:45vsyrjala: dj-death knows the full story
10:48vsyrjala: i suppose we could have done the bit sampling apporach safely from the kernel as well. but why bother when the hw has actual counters :)
10:50austriancoder: I think it will give it a try and do the sampling in the kernel and provide the value via perfmon interface (and debugfs)