<Mary>
DavidHeidelberg: yeah I never gave midgard opencl a try and don't really have anything to test it sadly
digetx has joined #dri-devel
krei-se- has quit []
krei-se has joined #dri-devel
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
<DavidHeidelberg>
Mary: you have my sword... Ehm, you can use the CI :D
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
<mairacanal>
jani, I believe so, as we are using C11
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
odrling has quit [Remote host closed the connection]
odrling has joined #dri-devel
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
nerdopolis has joined #dri-devel
fab has quit [Quit: fab]
vliaskov has joined #dri-devel
guludo has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
<jani>
mairacanal: but it was possible with gnu c way before, but the direction from Linus was no
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
chamlis has quit [Remote host closed the connection]
chamlis has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
guludo has quit [Ping timeout: 480 seconds]
<ManMower>
sima: (or anyone else for that matter...) can I bother you for a quick knee-jerk stink check on https://pastebin.com/t8JjGNiK ?
<sima>
ManMower, looks like a good idea, assuming we're somewhat consistent with gating magic hdmi connector behaviour on connector->funcs.hdmi ...
<sima>
but I think this is more for mripard to judge
fab has joined #dri-devel
<mripard>
On principle, I'm fine with trying to streamline it as much as we can, but it's inconsistent with how other properties are typically handled
<mripard>
so the discussion (and the solution) feel much larger to me
<ManMower>
my specific problem is using a bridge, not really wanting to write all my own vfuncs and do "all that connector work", but the bridge code provides its own connector_reset helper which doesn't reset the hdmi properties. so maybe I've presented the wrong X for this X/Y problem. :)
<ManMower>
wrong Y, even.
<mripard>
the bridge stuff should deal with hooking everything for you to leverage the HDMI infrastructure code already
<mripard>
if it's missing a call to that reset, then it's indeed a bug and should be fixed in the bridge code
<ManMower>
I can do that - I think I still need the code motion from the front end of my pastebin though
<ManMower>
as simply calling the function where it is now results in a module dependency loop
<mripard>
I think lumag has fixed that one already?
<mripard>
I think it would be worth sending the last patches as is without the immutable discussion
<ManMower>
that definitely looks like it fixes my problem
<mripard>
lumag: ^
<lumag>
mripard, yep. I was OoO for three weeks. Now I hope to get back to the patches
guludo has joined #dri-devel
jkrzyszt has joined #dri-devel
<mripard>
lumag: welcome back :)
jsa has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
epoch101 has joined #dri-devel
epoch101 has quit []
jsa has joined #dri-devel
guludo has quit [Quit: WeeChat 4.3.6]
guludo has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<ManMower>
mripard: oh, I have another question... when hdr_output_metadata changes, I need a mode change to cause the new DRM infoframe to be written. is that something I should handle in my encoder atomic check function, or is that generic enough that it could happen in drm_atomic_helper_connector_hdmi_check?
<mripard>
both would be acceptable, but I'm not sure which one is best
<mripard>
I'm not familiar enough with HDR metadata to tell
hansg has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
<sima>
ManMower, so the idea is that if connector props have changed that require a full modeset you set crtc_state->connectors_changed from your connector's atomic_check
<sima>
drm_atomic_helper_check_modeset should have enough retry trickery to cope with that kind of stuff from the connector's ->atomic_check
i-garrison has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
i-garrison has joined #dri-devel
Blase82 has quit [Ping timeout: 480 seconds]
<sima>
ManMower, I think for bridges there's no other way to update connector stuff than full modeset, so yeah I think unconditionally doing that makes sense
<sima>
if people are unhappy about that we'd need to add more callbacks to adjust that without a full modeset
<sima>
e.g. i915 can fix up infoframes without a full modeset
<ManMower>
I think for HDR10 it's probably legit to require a modeset. HDR10+ or DV or something with the dynamic metadata... I have noooo idea
<ManMower>
well, "legit" is doing a lot of heavy lifting. I don't expect my display not to flash once at the start of an hdr10 movie. but that's subjective and personal.
<sima>
yeah for dynamic infoframes updates we might need to add them to the right states, make sure they're computed correctly and then that there's functions to update them on the right vblank
<sima>
it's all a bit a mess and requires a lot of hw specific knowledge, so for bridge chains I'd say we skip this for now and just force a full modeset
<ManMower>
it appears I'm setting crtc_state->mode_changed and not crtc_state->connectors_changed from my bridge atomic check function, is that ok?
<MrCooper>
you're saying a modeset would be required for changing HDR metadata, even if HDR was already enabled?
<sima>
you need ->connectors_changed
<sima>
they all get reflected in drm_atomic_crtc_needs_modeset, but each bit is owned by different parts
<sima>
mode_changed is for the crtc
<ManMower>
MrCooper: me? I'm more asking than saying... and specifically static metadata like HDR10
<sima>
connectors_changed for connectors
<sima>
and active_changed is very specific
<MrCooper>
FWIW, that would seem bad from a Wayland compositor PoV
<sima>
ManMower, the thing is that drivers can assume that they own mode_changed and some reset it, if the mode change can be done without flickering at the crtc level
Daanct12 has quit [Quit: WeeChat 4.4.1]
<sima>
so you can't touch that from non-crtc code
<sima>
docs could maybe be a bit improved
yyds has joined #dri-devel
yyds has quit []
<ManMower>
sima: oh dear. we're calling drm_atomic_helper_connector_hdmi_check() from drm_bridge_funcs->atomic_check in our drive. the former sets mode_changed for some common state change patterns...
<ManMower>
I guess we can't call that from a bridge vfunc
<sima>
yeah that should all be connectors_changed I think
<sima>
hm wait
<ManMower>
I suppose my move here is to messily refactor the guts of drm_atomic_helper_connector_hdmi_check(), or open code a copy that sets connectors_changed?
<ManMower>
or waiting, I can wait
<ManMower>
MrCooper: that's good to know, but can you tell me why?
bolson_ has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
<sima>
ManMower, ok so correction, you can set connectors_changed from encoder and hence also bridge functions
<sima>
it does fall apart on hw that supports cloning, i.e. more than one connector
<sima>
so maybe we should encode that with a WARN_ON check, but ... eh
<sima>
you really shouldn't touch mode_changed, but as long as your bridge chain never runs on a driver that does touch mode_changed in that driver's crtc code, you are fine
<ManMower>
so I *can't* just set mode_changed, but I *should* set connectors_changed
<ManMower>
hehe, that's probably a safe assumption, but nasty to make
<sima>
yeah I think you should just change that code to set connectors_changed instead
<sima>
since that's officially your own turf as a bridge/connector/encoder thing
<sima>
so maybe also a doc patch that bridge_funcs->atomic_check can set this to true
coldfeet has joined #dri-devel
<sima>
and maybe that mode_changed really shouldn't be touched by bridges who can't make assumptions about what the crtc code does
<ManMower>
if I was writing connector code and not bridge code, would mode_changed be ok? (ie: drm_atomic_helper_connector_hdmi_check is doign the right thing, I just ought not call it from where I am)
<sima>
also mode_valid should maybe check that drm_atomic_add_affected_connectors wouldn't add anything if connectors_changed changed
<sima>
it's all a bit a convoluted mess
coldfeet has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<zamundaaa[m]>
ManMower: changing the transfer function and setting / unsetting the metadata should require ALLOW_MODESET from the compositor, because some displays don't handle it very nicely
<zamundaaa[m]>
Changing the other bits should not require it though
Blase82 has joined #dri-devel
<ManMower>
zamundaaa[m]: that seems very reasonable to me. the display I'm using falls into the "not very nicely" category. :)
Schrostfutz has joined #dri-devel
<ManMower>
zamundaaa[m]: so some changes of the content of the DRM infoframe should be ok without a modeset?
<ManMower>
this causes me a problem on the bridge side, because I need to disable/enable to get the DRM infoframe to write. :/
Company has joined #dri-devel
<zamundaaa[m]>
If you can't do it without a modeset, then you just can't do it and compositors will need to handle that
<zamundaaa[m]>
FWIW KWin never changes the contents without a modeset anyways, dunno about other compositors though
<ManMower>
I'm most familiar with weston, and I think it currently only sets it once at startup. not the best test case. :)
vliaskov has quit [Remote host closed the connection]
<MrCooper>
ManMower: specifically, mutter/gnome-shell generally doesn't want to do any modesets outside of the user explicitly changing display settings (normally in gnome-control-center), presumably it'll want to change HDR metadata on the fly though
<ManMower>
MrCooper: I have a display in the other room that blacks out for 7 seconds when you change the transfer function. it might be best to limit on the fly changes.
<Company>
if a display blacks or not depends on which properties you change
<MrCooper>
then compositors might want a way to detect that ahead of time, so they can pick suitable static metadata instead
<Company>
however, I don't think it's documented anywhere which properties do or do not black
<Company>
what I expect to happen is that compositors figure out a set of properties that can be changed at runtime and use those
rasterman has quit [Quit: Gettin' stinky!]
<ManMower>
I think wanting to change static metadata dynamically may lead to sadness.
epoch101 has joined #dri-devel
kzd has joined #dri-devel
<Company>
depends - when you want to watch a movie, switching to the movie's tf is kinda useful, especially on a long flight - but for compositing your regular desktop you might want to use a different tf
<Company>
and now you have the problem where (un)fullscreening your video player is the time when you want to switch
<gfxstrand>
bbhtt: I'm not seeing the error in that log
<Company>
or when you want to overlay the "low battery" warning over the movie
<gfxstrand>
Oh, I see it now
<gfxstrand>
Yeah, I have no idea
<ManMower>
Company: yes, but wanting those things doesn't make my display not blank for 7 seconds when you try to do them. :)
<Company>
yeah, but now what?
<ManMower>
interact with hardware in a way that your users don't hate, I guess?
<Company>
you mean run out of battery?
<Company>
or blank screen for 7s?
<ManMower>
you could name the buttons in the configuration dialog exactly that :)
<Company>
users want the "do the right choice automatically" button
<bbhtt>
gfxstrand: Might be some sort of race condition or something in CI, I just tried mesa 24.2.1 in our master branch and it worked
<Company>
ManMower: is that really 7s btw? My monitors manage in 1-2s so 7 is substantially worse
<ManMower>
I think we're a bit off in the weeds now. if displays exist that take a long time (I'll concede 7s is pathological, but someone built it, and it exists), then you'll probably want that to be protected by the mode set flag
<bbhtt>
gfxstrand: I'll trigger the CI again on that branch, although both branches have same mesa, bindgen and rust
<ManMower>
it's probably closer to 8, but yeah, it's obnoxious
<gfxstrand>
Could be? Seems odd, though, because I don't think bindgen should be depending on any other generators
kts has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
dsimic is now known as Guest1814
dsimic has joined #dri-devel
Guest1814 has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
<MrCooper>
ManMower: what I mean is: at least some compositors will want to change metadata dynamically; when that's not possible though, they might want to use static metadata which differs from the one they'd start with assuming they could change dynamically
<MrCooper>
hence the need for a way to detect ahead of time, before trying to actually switch on the fly
<ManMower>
MrCooper: isn't that what the mode set flag is for?
<ManMower>
it's kind of a blunt instrument, especially if you're going to try every possible hdr_output_metadata blob you can build and find they all fail
<ManMower>
but I think (and I'm literally just making this up) it'll come down to: someone has a monitor somewhere that can't change *any* HDR10 static metadata settings without a lengthy resync.
<MrCooper>
good point though, I guess a TEST_ONLY commit which changes only metadata could work
<sima>
imo we should first do correct, we means more modesets with bridges involved
<sima>
then make stuff more dynamic, assuming compositors, hw, drivers and displays can cope
<ManMower>
I love that answer because it's easy for me in the short term. :)
<MrCooper>
if that happens once at session startup, that's "fine", since I understand something like that might happen when enabling HDR anyway; if it happens in the middle of the session though, not great
<ManMower>
and I have a limited collection of HDR capable displays to test on
<sima>
MrCooper, compositors can at least figure that out with TEST_ONLY and then bail
<ManMower>
the problem with static metadata is you'll almost certainly want to change it if you start playing a video
<sima>
which maybe not great, but at least correct (I think)
<MrCooper>
yeah, sorry, didn't think of that obvious solution :/
<sima>
ofc this might mean that we needless run the color pipeline with maybe a gpu mapping job while playing video, wasting power, but I think it should at least all ok
<sima>
and it's too hot here, can't english anymore
<ManMower>
the run out of battery button.
<ManMower>
but everything looks correct
<zamundaaa[m]>
ManMower: that "almost certainly" isn't true for KWin
<Company>
has anybody ever figured out if monitors take more energy in HDR modes?
<ManMower>
Company: almost certainly has to be true for a monitor with zoned backlights?
<Company>
dunno - I'm assuming you have equivalent brightness and display only SDR content
<ManMower>
I don't think I can just crank my brightness settings to the max and have them light up in SDR mode
<ManMower>
zamundaaa[m]: are you saying KWin users won't want to / be allowed to purchase such a display?
<zamundaaa[m]>
what? I'm saying that it never changes the hdr metadata
<ManMower>
ah, I context switched. fwiw, I like your design.
<zamundaaa[m]>
It just wouldn't be a good user experience if a video or game looked different fullscreen vs windowed
mripard has quit [Quit: mripard]
Blase82 has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
jsa has joined #dri-devel
<ManMower>
Company: anecdotally, the monitor I have on my desk seems to consume a maximum of around 60 watts in SDR mode with the brightness cranked, but will hit almost 90W in "HDR 600" mode, depending on content.
<Company>
yeah, I expect massively more usage for high brightness situations
Duke`` has joined #dri-devel
<Company>
what I'm wondering about is how many nuclear plants you need extra when you just switch all monitors into HDR at boot
<ManMower>
for equivalent brightness, this seems about the same
<ManMower>
so you could switch this into HDR at boot and render a desktop that doesn't make your eyes bleed, and you probably aren't destroying the planet
<Company>
if that is true - and so far I haven't seen anything indicating it isn't - it would make a lot of things a lot easier
coldfeet has joined #dri-devel
<Company>
I mean, it's not there yet because compositors and KMS need to drive those monitors properly in HDR mode without wasting tons of energy doing the color conversions in the wrong place
<Company>
but it'd make the end goal clear
Schrostfutz has quit [Ping timeout: 480 seconds]
<ManMower>
depends on a lot of things. you could still end up with a display that only supports static metadata, and a desire to play a video with a different MaxCLL/MaxFALL than what you set your GUI up for
<zamundaaa[m]>
KWin doesn't really use any more energy or noticeable amount of GPU power for HDR
<zamundaaa[m]>
The problem for enabling HDR by default is more that many drivers are still broken, and probably some displays just have really terrible behavior
<zamundaaa[m]>
Afaik MS is solving the latter problem for Windows by checking the certification of the display
<ManMower>
is that exposed through EDID? or are they expecting "monitor drivers" from manufacturers?
mbrost has joined #dri-devel
<zamundaaa[m]>
I would expect VESA to have a database for which displays have which VESA certification
kzd has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
<ManMower>
zamundaaa[m]: interesting, thanks. apparently I have a display that's in the vesa certification table, has windows "drivers" for calibration profile etc, but shows "HDR cerification: not found" in the display app. I wonder if it's even a vesa certification, or if they have their own certifaction program. :)
Kayden has quit [Quit: -> JF]
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
chamlis has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
chamlis has joined #dri-devel
warpme has quit []
Duke`` has joined #dri-devel
Kayden has joined #dri-devel
rasterman has joined #dri-devel
tobiasjakobi has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
raki has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
mrkajetanp has joined #dri-devel
kaiwenjon has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Blase82 has joined #dri-devel
fossdd has quit [Remote host closed the connection]
greenjustin has joined #dri-devel
fossdd has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
fossdd_ has joined #dri-devel
warpme has quit []
fossdd is now known as Guest1823
fossdd_ is now known as fossdd
raki_ has joined #dri-devel
Guest1823 has quit [Ping timeout: 480 seconds]
raki_ has quit [Remote host closed the connection]
warpme has joined #dri-devel
raki has quit [Remote host closed the connection]
raki has joined #dri-devel
warpme has quit []
rasterman has quit [Quit: Gettin' stinky!]
mbrost has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
libv has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
libv has joined #dri-devel
kaiwenjon has quit [Quit: WeeChat 3.8]
libv_ has joined #dri-devel
libv is now known as Guest1832
libv_ is now known as libv
Guest1832 has quit [Ping timeout: 480 seconds]
epoch101 has quit []
LeviYun has joined #dri-devel
mszyprow has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
hansg has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
jerrynemo has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
mrkajetanp has joined #dri-devel
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
LeviYun has joined #dri-devel
ellyq has quit [Remote host closed the connection]
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
ellyq has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
cheako has quit [Quit: Connection closed for inactivity]