<jenatali>
zmike: ugh. Disable the test I guess? I won't be able to take a closer look for a few weeks. If you do disable it, file an issue for me to re-enable it?
<zmike>
uhhhhhhh
fahien has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
ella-0_ has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
ella-0- has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
sarahwalker has quit [Remote host closed the connection]
ella-0_ has quit [Read error: Connection reset by peer]
devilhorns has quit []
mszyprow has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
fahien1 has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
<zmike>
dcbaker: \o/
* dcbaker
is just glad to have it done
gouchi has joined #dri-devel
gouchi has quit []
kem has joined #dri-devel
fahien1 is now known as fahien
<MrCooper>
ajax: tried bisecting the commit from that MR which triggers the timeout?
lemonzest has joined #dri-devel
mbrost has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
ybogdano has quit [Remote host closed the connection]
mattst88 has quit [Read error: Connection reset by peer]
mattst88 has joined #dri-devel
kem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
MajorBiscuit has joined #dri-devel
ngcortes has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: fahien]
pendingchaos has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
Haaninjo has joined #dri-devel
kts has quit []
kts has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
<mdnavare>
vsyrjala: jadahl: One of the concerns in Mutter community expressed about enabling VRR in this MR https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 was that since VRR enabling needs a full modeset to program VRR regs, this will blank the screen everytime VRR is enabled. What are your thoughts on addressing this?
<mdnavare>
vsyrjala: One of the solutions we discussed earlier was change the kernel code to always compute and configure VRR parameters when supported by panel , just dont enable it in atomic commit until requested by userspace. So then in that case we dont need a full modeset when requested by userspace. Is this a good approach forward, jadahl, would this address your concern expressed in this Mutter MR?
<mdnavare>
MrCooper: Do you know if AMD enables the VRR in the same way where always the VRR params are computed and committed only when requested by userspace?
<agd5f>
mdnavare, we even use vrr to do seemless mode switches between different refresh rates. E.g., for media apps that want to change from 60 to 24 fps during playback
<mdnavare>
agd5f: And that is requested through any property from userspace ?
<mdnavare>
agd5f: That would be I guess the fixed average refresh rate mode right?
<agd5f>
you just do a modeset and it will use vrr to change the refresh rather than doing a full modeset so the screen doesn't blank
<mdnavare>
I am guessing for that use case the VRR_enabled CRTC property stays false right? That sets to tru only for a true variable refresh for full screen games
<agd5f>
right.
<mdnavare>
agd5f: And thats only for DP 2.0 and HDMI 2.1 onwards correct?
<mdnavare>
agd5f: But wont it still need a full modeset to recompute new parameters for different refresh rate?
<agd5f>
mdnavare, any DP that supports variable refresh rate
<agd5f>
IIRC pre DP 2.0 supported it as well
rgallaispou1 has joined #dri-devel
<agd5f>
I guess we calculate for the max refresh and then at modeset time, if we see that the rate is within the range of the monitor, we just change the rate
<agd5f>
hwentlan_, ^^^ do you remember the details?
rgallaispou has quit [Ping timeout: 480 seconds]
<mdnavare>
agd5f: Yes that sounds correct, but then at modeset to change to that different rate, would need to reprogram VRR params which would need a full modeset I believe
mvlad has quit [Remote host closed the connection]
<agd5f>
I think you just set the min and max and you are done, at least on our hw
<tleydxdy>
on my monitor at least the vrr range only go down to 90hz, so it would still blank out?
<tleydxdy>
say if the desktop is 60hz
<agd5f>
if the refresh rate is outside of the vrr range, then it would need a full modeset, but is that actually a thing?
<tleydxdy>
or in this case the desktop will always run at the max refresh rate, and it's allowing fullscreen apps to go below that?
kts has quit [Ping timeout: 480 seconds]
<mdnavare>
agd5f: Thanks for the inputs, on our HW we need to program a few more params that are derived from min and max , but I think we can change the code a bit to always program these so we wont need a full modeset and then when requested we just commit it
<mdnavare>
vsyrjala: Do you agree?
fab has quit [Quit: fab]
MajorBiscuit has joined #dri-devel
<vsyrjala>
yeah, i think we should be able to at least some stuff with the vrr hardware
<vsyrjala>
i think tgl+ can also repgram the normal vtotal register on the fly. i guess you can think of that as basically a totally manual vrr mode or something
<vsyrjala>
i just wish someone figured out what's causing that vrr black screen bug
<vsyrjala>
not really motivated to add stuff on top of a buggy foundation
<mdnavare>
vsyrjala: So I will start writing up patches then toc hange our vrr_compute_config to always compute vrr parameters and then writing to regs in commit tail only when vrr crtc property set
Duke`` has quit [Ping timeout: 480 seconds]
<mdnavare>
vsyrjala: The other thing I wanted to clarify is how should we handle a scenario where userpsace requests VRR on a non VRR panel, currently we dont reject or throw a warning we just continue without vrr, but that is not something that userspace expects, so how do we communicate that to userspace
<tleydxdy>
maybe just have a way to check if vrr is actually enabled?
<tleydxdy>
so apps that didn't care continue to work
<mdnavare>
so for that we will need to expose the actual vrr crtc state back to userspace through a prop or debugfs
ybogdano has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]