ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
thellstrom1 has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
Haaninjo has quit [Quit: Ex-Chat]
benjamin1 has joined #dri-devel
columbarius has joined #dri-devel
ced117 has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
kzd has quit [Quit: kzd]
benjamin1 has quit [Ping timeout: 480 seconds]
ced117 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
penguin42 has quit [Remote host closed the connection]
Leopold__ has quit [Remote host closed the connection]
benjamin1 has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
tm512 has joined #dri-devel
<tm512>
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)
redeeman has joined #dri-devel
<idr>
tm512: I think so... that's the i830_dri.so driver.
<airlied>
find an old distro :-)
<tm512>
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
<idr>
tm512: I believe there is code. It had not been tested by anyone at Intel for quite some years, so... yeah. :(
benjamin1 has joined #dri-devel
<tm512>
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
<tm512>
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?
<tm512>
or would I do everything exclusively with the amber branch?
sassefa has quit [Ping timeout: 480 seconds]
<airlied>
everything from amber
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
<tm512>
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
<idr>
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.
aravind has joined #dri-devel
<tm512>
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
benjamin1 has joined #dri-devel
<tm512>
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
Zopolis4 has quit [Quit: Connection closed for inactivity]
benjamin1 has joined #dri-devel
hikiko has quit []
benjamin1 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
thellstrom has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
Ultra has quit [Remote host closed the connection]
Ultra has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
fab has quit [Quit: fab]
benjamin1 has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
is everyone's UBO-to-push pass unsound??
<karolherbst>
ours is sound
<karolherbst>
(because it doesn't exist)
benjamin1 has quit [Ping timeout: 480 seconds]
<alyssa>
:P
<alyssa>
specifically for evil shaders of the form
<alyssa>
if (nonuniform_condition_that_is_never_true_but_the_compiler_doesnt_know_that) {
<alyssa>
load_ubo(big out of bounds index)
<alyssa>
}
<alyssa>
can't speculate that load unless you have robust loads to work with
<alyssa>
maybe that's the real answer
<karolherbst>
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
krushia has joined #dri-devel
jewins has joined #dri-devel
kzd has joined #dri-devel
benjamin1 has joined #dri-devel
Ultra has quit [Remote host closed the connection]
Ultra has joined #dri-devel
fab has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
Company has joined #dri-devel
pochu has quit [Quit: leaving]
benjamin1 has quit [Ping timeout: 480 seconds]
grillo_0 has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<karolherbst>
is there a way to tell what modes are added by userspace?
<_jannau__>
karolherbst: DRM_MODE_TYPE_USERDEF or missing DRM_MODE_TYPE_DRIVER
<karolherbst>
cool. I just stumpled upon that myself as well :)
Duke`` has joined #dri-devel
<karolherbst>
how can I reject those modes though
<emersion>
_jannau__: does the kernel check that user-space always sets these?
frieder has quit [Remote host closed the connection]
<emersion>
I do set them, but in not sure it's a guarantee that the flag is set
<karolherbst>
soo.. apparently I get a 1920x1080@60Hz HDMI mode wich a clock above 340000 🙃
<emersion>
karolherbst: reject the atomic commit when checking it
<karolherbst>
which.. you can guess, doesn't always work
<karolherbst>
emersion: yeah.. but for silly reasons, nouveau still defaults to non atomic :'( but yeah, we really should just enable it *sigh*
<emersion>
but ideally drivers would try to apply user-defined modes
<karolherbst>
but I think our atomic rejection also doesn't properly work
<karolherbst>
yeah.. just gnome seems to add a lot of broken modes :'(
<emersion>
I thought nouveau defaulted to atomic now?
<karolherbst>
nah
<karolherbst>
they use the atomic API and everything always
<karolherbst>
but it's not exposed to userspace
<emersion>
i have a memory of this being changed
<emersion>
cc Lyude
<karolherbst>
yeah well.. it's off by default still
<karolherbst>
yeah.. also breaks if atomic is enabled in nouveau
<karolherbst>
guess I really have to fix the atomic side and just enable it
<karolherbst>
but gnome shouldn't add a 356MHz FHD@60 mode if a 140MHz FHD@60 mode already exists....
<agd5f>
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
<_jannau__>
drm_mode_setcrtc() might call drm_mode_config_funcs::mode_valid via drm_mode_convert_umode
kts has quit [Ping timeout: 480 seconds]
<anholt_>
karolherbst: supporting vec2@16 in v3d doesn't seem like it'd be hard to me.
pallavim_ has joined #dri-devel
pallavim has quit [Read error: Connection reset by peer]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
Sopa has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
leandrohrb55 has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<karolherbst>
mhh nouveau implements `drm_connector_helper_funcs::mode_valid`
leandrohrb55 is now known as leandrohrb
<karolherbst>
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
<karolherbst>
so I can only reject the atomic commit at that point?
<karolherbst>
and non atomic is just broken if userspace does stupid things (tm)?
cmichael has quit [Quit: Leaving]
<karolherbst>
where can I find the selected mode when doing the atomic_check?
<zamundaaa[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
<emersion>
I think mode_valid is what you want, from reading the docs
<karolherbst>
on the connector or the drm_device one?
<karolherbst>
because the connector one doesn't work
pallavim has joined #dri-devel
pallavim_ has quit [Read error: Connection reset by peer]
<karolherbst>
anyway... I kinda want to verify user added modes are sane, or is that the device global mode_valid hook?
tango_ has quit [Ping timeout: 480 seconds]
gcarlos has joined #dri-devel
idr has joined #dri-devel
benjamin1 has joined #dri-devel
Sopa has quit [Ping timeout: 480 seconds]
swalker__ has quit [Remote host closed the connection]
kasper93 has quit [Remote host closed the connection]
<eric_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)
djbw has joined #dri-devel
twinblade has joined #dri-devel
Sopa has quit [Ping timeout: 480 seconds]
<agd5f>
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
<agd5f>
ideally userspace would stick to what is available from GET_CONNECTOR
twinblade has quit [Quit: Konversation terminated!]
kasper93 has joined #dri-devel
<karolherbst>
where does MODE_SETCRTC end up in the driver?
i509vcb has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<karolherbst>
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...
<karolherbst>
or just store it coming from atomic_enable...
JohnnyonF has joined #dri-devel
<agd5f>
karolherbst, IIRC, drm_crtc_helper_funcs and drm_encoder_helper_funcs
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jfalempe has quit [Read error: Connection reset by peer]
thellstrom has quit [Ping timeout: 480 seconds]
Nirvin[m] has left #dri-devel [#dri-devel]
<karolherbst>
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.
<alyssa>
Could I interest anyone in an egl/wayland bug? (~:
<alyssa>
bl4ckb0ne: failing on all of weston/mutter/wlroots
<bl4ckb0ne>
have you tried vk or gl for wlroots
<alyssa>
this is gles, I don't have vk drivers
<alyssa>
and this is failing across multiple drivers.
<jannau>
failing on kwin as well
<alyssa>
the fabulous 4
<alyssa>
:p
<HdkR>
Oh no, wide colour
<jannau>
problem for fp16 on agx is that the results are clamped to [0.0, 1.0]
kasper93 has quit [Remote host closed the connection]
<anholt_>
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
alyssa has left #dri-devel [#dri-devel]
Ahuj has quit [Ping timeout: 480 seconds]
cwegener has joined #dri-devel
cwegener1 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
cwegener has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
cwegener1 has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
Haaninjo has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
* alyssa
hoists v3d_nir_lower_robust_access into common code
<daniels>
anholt_: the HP grunts we do radv testing on have a bit of headroom, the Acer ones we do radeonsi on none
<daniels>
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
Duke`` has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<tm512>
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
<tm512>
I think I remember nouveau at least sorta being functional back in like 2014-2015, back when Debian still supported ppc32
thellstrom has joined #dri-devel
alarumbe has quit [Ping timeout: 480 seconds]
kxkamil2 has joined #dri-devel
cwegener1 has joined #dri-devel
kxkamil has quit [Ping timeout: 480 seconds]
cwegener1 has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
cwegener1 has joined #dri-devel
f11f12 has quit [Quit: Leaving]
vliaskov has quit [Remote host closed the connection]
sukrutb has quit [Remote host closed the connection]
sukrutb has joined #dri-devel
<idr>
tm512: That should be working in amber. I tested that more recently than I tested i8xx.
<idr>
Now... there could be byte ordering issues on PPC.