00:58tm512: so Mesa's README pointed me here. does the mesa-amber branch still have any support for old i8xx iGPUs? I'm wondering how much of a pain it will be to get OpenGL working on this old Pentium M laptop (which has Intel Extreme 2 graphics, so i855 I think)
00:59idr: tm512: I think so... that's the i830_dri.so driver.
00:59airlied: find an old distro :-)
00:59tm512: it seems like the i915 DRM driver still supports it, even supports kernel modesetting, but I dunno if that can be taken as any indicator that the i915 driver in mesa-amber would have any support
01:00idr: tm512: I believe there is code. It had not been tested by anyone at Intel for quite some years, so... yeah. :(
01:05tm512: might have some questions later on digging out the driver and getting it compiled, but this thing needs some software updates. I installed NetBSD on it years ago but ran into some issues
01:07tm512: if the code is in the amber branch, it sounds like I need to compile the base mesa installation with the -Damber=true flag? then build the driver I need from the amber branch?
01:07tm512: or would I do everything exclusively with the amber branch?
01:08airlied: everything from amber
01:18tm512: I'm probably going to stick with NetBSD or go with FreeBSD, so in that case I guess I will write my own ports/pkgsrc build script since neither of them provide one for mesa-amber, afaict
01:21tm512: huh, well NetBSD is seemingly still on Mesa 21.3.9, which is before non-gallium stuff was stripped? https://github.com/NetBSD/pkgsrc/blob/trunk/graphics/MesaLib/Makefile#L40
01:34airlied: seems likely
02:37idr: tm512: 21.x.y feels like forever ago... it looks like the 21.3 branch point is the last common point between origin/amber and origin/main, so you should be good.
02:43tm512: just a bit worried about NetBSD finally upgrading the version they ship, though given the project's reputation of running on everything, out of any project they'd probably be most receptive to actually packaging amber separately so that people can continue to get the most out of older machines
02:47tm512: not sure if I'll stick around to push for that though. I'm guessing with this old laptop, I'll find it fun to get things actually working, and then I'll gradually realize that I have no practical use for 20 year old hardware, and shelve it
10:08FLHerne: -+
13:57alyssa: is everyone's UBO-to-push pass unsound??
13:59karolherbst: ours is sound
14:00karolherbst: (because it doesn't exist)
14:02alyssa: :P
14:02alyssa: specifically for evil shaders of the form
14:03alyssa: if (nonuniform_condition_that_is_never_true_but_the_compiler_doesnt_know_that) {
14:03alyssa: load_ubo(big out of bounds index)
14:03alyssa: }
14:03alyssa: can't speculate that load unless you have robust loads to work with
14:07alyssa: maybe that's the real answer
14:13karolherbst: yeah.. maybe only move things into push if you can prove the value is getting used, and if there is still space, fill it with more likely stuff or something :P
15:10karolherbst: is there a way to tell what modes are added by userspace?
15:14_jannau__: karolherbst: DRM_MODE_TYPE_USERDEF or missing DRM_MODE_TYPE_DRIVER
15:15karolherbst: cool. I just stumpled upon that myself as well :)
15:16karolherbst: how can I reject those modes though
15:16emersion: _jannau__: does the kernel check that user-space always sets these?
15:17emersion: I do set them, but in not sure it's a guarantee that the flag is set
15:17karolherbst: soo.. apparently I get a 1920x1080@60Hz HDMI mode wich a clock above 340000 🙃
15:17emersion: karolherbst: reject the atomic commit when checking it
15:17karolherbst: which.. you can guess, doesn't always work
15:18karolherbst: emersion: yeah.. but for silly reasons, nouveau still defaults to non atomic :'( but yeah, we really should just enable it *sigh*
15:18emersion: but ideally drivers would try to apply user-defined modes
15:18karolherbst: but I think our atomic rejection also doesn't properly work
15:18karolherbst: yeah.. just gnome seems to add a lot of broken modes :'(
15:18emersion: I thought nouveau defaulted to atomic now?
15:18karolherbst: nah
15:18karolherbst: they use the atomic API and everything always
15:18karolherbst: but it's not exposed to userspace
15:19emersion: i have a memory of this being changed
15:19emersion: cc Lyude
15:19karolherbst: yeah well.. it's off by default still
15:19karolherbst: `MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");`
15:23emersion: :S
15:23karolherbst: emersion: where in the drm code would a driver have to reject those modes? I always wanted to check if that's all correct in nouveau
15:23karolherbst: because I also see this happening with atomic enabled
15:23emersion: hm, one of the check_ hooks I think...
15:23MrCooper: struct drm_mode_config_funcs::mode_valid
15:24emersion: ah, that sounds better
15:26MrCooper: or other mode_valid hooks
15:27karolherbst: yeah.. also breaks if atomic is enabled in nouveau
15:27karolherbst: guess I really have to fix the atomic side and just enable it
15:27karolherbst: but gnome shouldn't add a 356MHz FHD@60 mode if a 140MHz FHD@60 mode already exists....
15:28agd5f: emersion, IIRC, mode_valid only gets called for the GET_CONNECTOR ioctl. userspace can still specify a bad mode for modeset, at least for non-atomic
15:35_jannau__: drm_mode_setcrtc() might call drm_mode_config_funcs::mode_valid via drm_mode_convert_umode
15:54anholt_: karolherbst: supporting vec2@16 in v3d doesn't seem like it'd be hard to me.
16:13karolherbst: mhh nouveau implements `drm_connector_helper_funcs::mode_valid`
16:14karolherbst: but anyway, the issue kinda is, that userspace can add broken modes and I wonder what's the proper path of rejecting those... mode_valid on the connector doesn't seem to cut it
16:14karolherbst: so I can only reject the atomic commit at that point?
16:14karolherbst: and non atomic is just broken if userspace does stupid things (tm)?
16:19karolherbst: where can I find the selected mode when doing the atomic_check?
16:23zamundaaa[m]: <karolherbst> "and non atomic is just broken if..." <- You can, at least in theory, reject DRM_IOCTL_MODE_SETCRTC. I can't speak for other compositors, but in KWin that ioctl failing gets handled somewhat gracefully
16:27emersion: I think mode_valid is what you want, from reading the docs
16:27karolherbst: on the connector or the drm_device one?
16:27karolherbst: because the connector one doesn't work
16:31karolherbst: anyway... I kinda want to verify user added modes are sane, or is that the device global mode_valid hook?
17:05eric_engestrom: PSA: reminder that in Mesa we have a script to run only the job you care about in the CI, to avoid wasting resources that others could have used: https://docs.mesa3d.org/ci/index.html#running-specific-ci-jobs
17:05eric_engestrom: (we currently have a lot of overwhelmed runners, and looking at the pipelines they are running for, several of those definitely didn't need to run all the jobs)
17:16agd5f: karolherbst, the connector one only gets called for GET_CONNECTOR. not for MODE_SETCRTC. So yeah, userspace can throw something else at you and you'd need to check again in MODE_SETCRTC, but maybe that is sort of what you want assuming it's only used for overriding purposes
17:17agd5f: ideally userspace would stick to what is available from GET_CONNECTOR
17:29karolherbst: where does MODE_SETCRTC end up in the driver?
17:38karolherbst: I'm not really familiar with the drm api as much, so I kinda still have to figure things out, but could I potentially just reject the modes earlier? though dunno mhh... in atomic_enable maybe? Though I think atomic_check would be fine, I just need to figure out how to fetch the selected mode or something...
17:38karolherbst: or just store it coming from atomic_enable...
17:44agd5f: karolherbst, IIRC, drm_crtc_helper_funcs and drm_encoder_helper_funcs
18:38karolherbst: agd5f: right... I mean, I know where to put stuff, I'm just missing the bigger picture of how drivers should handle modelines not working on hardware. Both in an atomic and non atomic context.
18:39alyssa: Could I interest anyone in an egl/wayland bug? (~:
19:14bl4ckb0ne: yes
19:16alyssa: bl4ckb0ne: ( https://gitlab.freedesktop.org/mesa/mesa/-/issues/9276 )
19:17bl4ckb0ne: i think thats compositor specific
19:18bl4ckb0ne: could you link me the tests pls
19:18alyssa: bl4ckb0ne: failing on all of weston/mutter/wlroots
19:19bl4ckb0ne: have you tried vk or gl for wlroots
19:19alyssa: this is gles, I don't have vk drivers
19:19alyssa: and this is failing across multiple drivers.
19:19jannau: failing on kwin as well
19:19alyssa: the fabulous 4
19:19alyssa: :p
19:22HdkR: Oh no, wide colour
19:25jannau: problem for fp16 on agx is that the results are clamped to [0.0, 1.0]
19:37anholt_: daniels: how has occupancy of stoney and tgl runners been? looking at angle ci again, wondering if I should pick different boards or adjust fractions
20:40alyssa:hoists v3d_nir_lower_robust_access into common code
20:44daniels: anholt_: the HP grunts we do radv testing on have a bit of headroom, the Acer ones we do radeonsi on none
20:45daniels: anholt_: the volteers we do anv-tgl are a bit bursty but we have enough devices that I think it should be fine on the whole - I think just put it in and we can see what it looks like
21:13tm512: so yesterday I was asking about support in amber for this old i855 iGPU, but I'm also kinda curious about this other (even older) machine I have. anyone know if nouveau in amber still has support for the Geforce 2 MX? I've got an old PowerMac G4 that has one
21:14tm512: I think I remember nouveau at least sorta being functional back in like 2014-2015, back when Debian still supported ppc32
22:57idr: tm512: That should be working in amber. I tested that more recently than I tested i8xx.
22:57idr: Now... there could be byte ordering issues on PPC.