ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
kts has joined #dri-devel
smiles_1111 has joined #dri-devel
idr has quit [Quit: Leaving]
kts has quit [Quit: Konversation terminated!]
smilessh has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
yyds has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
ecm has joined #dri-devel
<ecm> hello
<ecm> shouldn't the 23.1.4 mesa version fix GLXBadFBConfig errors ?
<ecm> they still persist after updating to it for me
<ecm> i can't do MESA_GL_VERSION_OVERRIDE=4.4 to fix it as my gpu is at 3.3 only
yyds has quit [Remote host closed the connection]
ecm has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)]
yyds has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
Lyude has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Ping timeout: 480 seconds]
Lyude has joined #dri-devel
ecm has joined #dri-devel
agd5f_ has joined #dri-devel
libv has joined #dri-devel
libv_ has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
aravind has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
leo60228- has quit [Ping timeout: 480 seconds]
leo60228 has joined #dri-devel
bgs has joined #dri-devel
Duke`` has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
bgs has quit [Remote host closed the connection]
Lyude has quit [Remote host closed the connection]
Lyude has joined #dri-devel
ecm has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
carbonfiber has joined #dri-devel
godvino has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
gdevi has quit [Quit: Client limit exceeded: 20000]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
rasterman has joined #dri-devel
fab has quit [Quit: fab]
kts has joined #dri-devel
sima has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
ella-0 has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
kchibisov has joined #dri-devel
ella-0 has joined #dri-devel
kennylevinsen has joined #dri-devel
sumoon has joined #dri-devel
ifreund has joined #dri-devel
rpigott has joined #dri-devel
rosefromthedead has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
fab has joined #dri-devel
frieder has joined #dri-devel
yyds has quit [Remote host closed the connection]
tursulin has joined #dri-devel
godvino has quit [Quit: WeeChat 3.6]
frankbinns has joined #dri-devel
rgallaispou has joined #dri-devel
yyds has joined #dri-devel
rmckeever has quit [Quit: Leaving]
swalker_ has joined #dri-devel
swalker_ is now known as Guest7119
swalker__ has joined #dri-devel
lynxeye has joined #dri-devel
schaeffer has quit [Quit: well, bye]
Guest7119 has quit [Ping timeout: 480 seconds]
schaeffer has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Haaninjo has joined #dri-devel
Company has quit [Quit: Leaving]
jfalempe_ is now known as jfalempe
tzimmermann has joined #dri-devel
<tzimmermann> mripard, thanks for taking care of last week's drm-misc-next PR
mvlad has joined #dri-devel
<tzimmermann> sima, airlied, hi. if you have a minute, please merge last week's PR for drm-misc-next. see tags/drm-misc-next-2023-07-21
<sima> oops, will do
<sima> rodrigovivi, dolphin no intel pulls while I'm at it, correct? just want to make sure I'm not missing anything
<dolphin> sima: tursulin should be preparing one, however it looks like no rebase to -rc has happened?
djbw has quit [Read error: Connection reset by peer]
<mripard> tzimmermann: you're welcome, do you want me to do this week too?
<tzimmermann> i'll take care of it, thank you
<mripard> ack :)
<sima> dolphin, drm-next is at -rc2
<sima> or maybe I screwed up something
<sima> nah I didn't fail to push
<sima> dolphin, but maybe wait a bit until I pushed out the latest drm-misc-next merge
godvino has joined #dri-devel
lplc has joined #dri-devel
<dolphin> sima: uh, but kernel.org is at -rc3
<dolphin> also, I was referring to -fixes :)
alpalcone has quit [Ping timeout: 480 seconds]
<sima> dolphin, yeah but we don't do backmerge every -rc
<sima> dolphin, oh I was talking about -next
<sima> I'll roll -fixes forward
<dolphin> ok, well that clarifies things a bit
phasta has joined #dri-devel
aravind has joined #dri-devel
<tursulin> sima: you should have drm-intel-fixes pr arrive shortly, thanks!
<sima> tursulin, drm-fixes at -rc3 now
Haaninjo has quit [Quit: Ex-Chat]
kts has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
kts has quit [Quit: Konversation terminated!]
jkrzyszt_ has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
sgruszka has joined #dri-devel
godvino has joined #dri-devel
Leopold__ has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
Leopold has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
yyds has quit [Remote host closed the connection]
RSpliet has quit [Ping timeout: 480 seconds]
<cwabbott> gfxstrand: you may want to take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24318
<cwabbott> through a series of unfortunate events `shader_info::clip_distance_array_size` is broken with glslang output when xfb is used, it's 1 when gl_ClipDistance isn't declared
<cwabbott> the only option we can see is to make every driver use the helper in the MR or add something to try to detect when ClipDistance is never written and make sure the array size is 0
cmichael has joined #dri-devel
kts has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
<sima> tzimmermann, mripard's drm-misc-next pr is pushed out
heat_ has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
fab has quit [Quit: fab]
godvino has quit [Quit: WeeChat 3.6]
<alyssa> karolherbst: what are the rules around variable_shared_mem?
<alyssa> I'd like to insert shared mem stuff in the compiler for internal use
<alyssa> in GL/VK that's safe -- I can look at the existing shared_size, compare it to the maximum, and if there's room add my stuff on top (and if not bail, it's for an optimization)
<alyssa> in CL, I don't know if that can possibly be safe unless there are statically no shared mem accesses at all
godvino has joined #dri-devel
<alyssa> or maybe that can be relaxed to no indirect shared mem access, and we can teach nir_gather_info to max shared size with the direct offsets+1
fab has joined #dri-devel
cmichael has quit [Quit: Leaving]
<mripard> sima: thanks :)
<karolherbst> alyssa: variable_shared_mem is shared mem added on top of all in shader declared one on launch_grid time
kts has quit [Ping timeout: 480 seconds]
<karolherbst> e.g. if the shared memory required by the launch is bigger than what the declared shared_mem of the nir_shader requires
<rodrigovivi> sima: welcome back, and no pr from my side yet... coming soon
<karolherbst> *shared_size
<sima> rodrigovivi, just pushed out another merge to drm-next
<sima> airlied, ^^ did some -next pr handling, should be all caught up as of now
<karolherbst> alyssa: so if you add shared memory blocks of known sizes at compile time, simply make sure that shared_size gets updated properly
cmichael has joined #dri-devel
<sima> agd5f, robclark, dolphin, tursulin, jani, anyone else who needs to do some backmerging or whatever ^^
fab_ has joined #dri-devel
fab_ is now known as Guest7139
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
godvino has quit [Quit: WeeChat 3.6]
fab has quit [Ping timeout: 480 seconds]
Guest7139 is now known as fab
fab is now known as Guest7140
ahajda has joined #dri-devel
<alyssa> karolherbst: the problem is that there is a hw limit to shared mem and we need to be sure not to exceed it by adding our own blocks
Company has joined #dri-devel
<karolherbst> alyssa: might have to limit the max size exposed through APIs then or something?
<karolherbst> variable shared mem can't really help with that anyway, because it still has to all fit within hardware limits
<karolherbst> it's more like a thing that if you have 1k of shared mem, the application might allocate 512b statically, and 512b dynamically at launch time
<karolherbst> but it still has to fit within hardware limits
<alyssa> right..
<DavidHeidelberg[m]> anyone annoyed by KDL verbosity at the end of the job can give ack on: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24348 ?
smiles_1111 has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
<haasn> is there anything special an application needs to do to support VRR? my understanding was that I can just present frames whenever they're ready and they will become visible as soon as possible?
<emersion> yes
<haasn> how quickly can the display/implementation respond to framerate changes? say I have a display with 1 Hz minimum framerate, can an unpredictable input event (e.g. moving cursor) instantly end the 1000ms vblank period?
<emersion> right now, yes… it kind of depends on compositor policy
<haasn> hmm okay; so at a low level, the duration of a frame does not need to be known in advance?
<emersion> the compositor can choose to go to highest refresh rate, or to lock the cursor refresh rate to the app's
<haasn> e.g. say I get frames at unpredictable times from a network source, I can just present them whenever they happen to arrive over the network and it should all work fine without any special handling or thinking?
<haasn> even if I don't know anything about how long each frame will last
<haasn> right, I'm assuming a best case scenario in which VRR is active and the app is in fullscreen and the only thing driving the display
<emersion> yeah, as long as you submit a frame before the max refresh period (min refresh rate), then it'll make it
<haasn> hmm
<emersion> if you miss the max refresh period, it's just like fixed refresh rates again: the compositor will wait for the next vblank to display the frame
<haasn> if the minimum refresh rate is 30 Hz and I'm trying to present a 24 Hz stream, it will introduce input latency corresponding to the difference between 30 Hz and 48 Hz?
<haasn> (assuming display/GPU does LFC)
<emersion> hm, would need to draw a diagram to figure this out
<emersion> but yeah, you'd sometimes miss frames, sometimes not, and the presentation time of your frames would be a bit unpredictable
<haasn> e.g. at t=0ms I submit the first frame, then at t=33.3ms max vblank is reached so the display re-submits this frame
godvino has joined #dri-devel
MrCooper has joined #dri-devel
<haasn> actually, wouldn't it then depend on what the display's _maximum_ refresh rate is?
<haasn> say my display has an exceptionally good max refresh rate of 240 Hz
<haasn> if at t=35ms (2ms after max vblank caused the previous frame to get-resubmitted) I suddenly try to present a new frame, shouldn't it respond to the new frame within 4ms?
<haasn> (because of max being 240 Hz)
<haasn> in that case it seems like what would happen is that the framerate would appear to 'alternate' between 30 Hz and 240 Hz
<haasn> because the new frame would always interrupt the previous vblank period right after it started but then max out the next vblank period
peelz has joined #dri-devel
<zamundaaa[m]> Not necessarily. LFC is a thing, and amdgpu implements it
peelz is now known as Guest7146
<zamundaaa[m]> So you'd actually get 48Hz, if you're presenting at a somewhat predictable rate
Guest7146 has quit []
phasta_ has joined #dri-devel
phasta_ has quit []
<haasn> then I must be misunderstanding how LFC works
<haasn> seems to me like the obvious implementation of LFC would be to just re-submit the previous frame shortly before max vblank is reached, no?
<haasn> without making any assumptions about how long to present it for
<haasn> probably time to do some experiments
<zamundaaa[m]> That wouldn't be LFC
<haasn> ..and add a better timing core to plplay / libplacebo
<zamundaaa[m]> LFC multiplies the refresh rate by an integer if you drop below the minimum refresh rate, so that you stay in the VRR window
bgs has joined #dri-devel
<haasn> but I don't understand how this can work if it doesn't know the duration of a frame
<haasn> unless it adds 1 frame of latency to do the calculation
<zamundaaa[m]> No, it more or less just guesses
<haasn> ugh
<zamundaaa[m]> yeah. FYI we could maybe improve on this in the future, as LFC might get implemented in compositors instead of the kernel
phasta has quit [Ping timeout: 480 seconds]
<zamundaaa[m]> With a Wayland protocol to tell the compositor that you have a predictable refresh rate, it could be done in a nicer way (at least for video players)
rasterman has quit [Quit: Gettin' stinky!]
<javierm> tzimmermann: thanks for your suggestion. I already was testing that but it was good to have confirmation that it was what I missed
<javierm> tzimmermann: so silly, I was sure that was testing one thing and was not testing at all
<tzimmermann> javierm, i saw you already have a patch. never mind then
<javierm> tzimmermann: yes, but it was great to have a validation from you that I understood correctly :)
<javierm> tzimmermann: I looked at drivers/gpu/drm/tiny/cirrus.c as a reference btw
<rodrigovivi> airlied: sima: interesting discussion on xe patch made me think if we shouldn't get entirely rid of the drm->date https://lore.kernel.org/all/xh23li7qzshcuheqlaue2pbwtfzdm7uygowpkovtgc52r6y2tp@apdgbzgegvpy/ thoughts?
<rodrigovivi> demarchi: ^
kzd has joined #dri-devel
<sima> rodrigovivi, yeah the drm driver date is a bit lolz
<sima> it made sense when drm was out-of-tree developed, but that stopped being a thing for almost 2 decades now
<sima> rodrigovivi, we might need some patches to make sure drm core and userspace can cope with no date, but sounds good otherwise to abandon this
<sima> and update kerneldoc and all that ofc
<javierm> tzimmermann: I saw that you sent a PR for drm-misc-next, would there be another one once this fix lands or would be a -fixes ?
<sima> -rc6 is usually the cut-off, so there should be plenty more
<javierm> sima: Ok, cool
cheako has joined #dri-devel
<sima> drm-next cutoff of "you need a seriously good excuse for pr with code that landed after that"
<rodrigovivi> sima: true... there might be some uapi around the date... need to take a careful look
<sima> so anything that landed in drm-misc-next up to -rc6 should still make it
<javierm> sima: nice, thanks for the info
<sima> rodrigovivi, yeah some quick grepping shows that all the drivers I checked set it to some nonsense
<sima> rodrigovivi, a full audit to see where it's used and then aggressively replace it with NULL or outright retire might be good
<sima> drm core could just return a date that appeases existing userspace enough to not break things
<sima> and we'd ditch drm_driver.date outright from the code
<rodrigovivi> yeap, this seems the way to go
kasper93 has joined #dri-devel
<sima> rodrigovivi, at least libdrm seems to be able to cope wiht a zero date_len even
<sima> and all the code I've found only printfs it :-)
<sima> but yeah would need to check the usual ddx, -modeset, mesa, libva
<sima> it's a bit of digging
<sima> rodrigovivi, if the digging indicates we could just set date_len = 0, then patch to drm_ioctl.c to do that first
<sima> plus a todo to delete all the date entries a few releases later maybe
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
phasta has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
pzanoni` has joined #dri-devel
mattrope_ has joined #dri-devel
godvino has quit [Quit: WeeChat 3.6]
notpeelz has joined #dri-devel
<tzimmermann> javierm, that fix goes into -misc-next
<javierm> tzimmermann: Ok
mattrope has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
pzanoni has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
kts has joined #dri-devel
ahajda_ has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
ahajda_ is now known as ahajda
RSpliet has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<karolherbst> airlied: mind upstreaming this patch to llvm? I couldn't figure out how to submit patches through phabricator.... https://github.com/karolherbst/llvm-project/commit/184c97f254dc9d21891c4a64d504940fcf5f3c5f
<karolherbst> never mind.. it was this tiny button nobody finds
<rodrigovivi> sima: cool! I will take a look on those
<psykose> i don't think they're doing more 16.x branch releases so it would have to go to master only, and there they probably won't take it
<karolherbst> yeah..... annoying
<karolherbst> can only suggest distributions to take it
pzanoni` is now known as pzanoni
yyds has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
djbw has joined #dri-devel
benjamin1 has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
aravind has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
agd5f has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
i-garrison has quit []
i-garrison has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
junaid has joined #dri-devel
bgs has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
iive has joined #dri-devel
<Kayden> zmike: by the way, I was seeing a ton of zink failures with anv on your branch for moving VB strides
<zmike> 🤔
<DavidHeidelberg[m]> eric_engestrom: i'm suspecting that Sergi sent the KDL to background with some purpose, I would wait jntil he gets back from vacation tk ask about it
<Kayden> zmike: https://mesa-ci.01.org/dev_kwg/builds/2601/group/63a9f0ea7bb98050796b649e85481845 has a partial list but unfortunately it seems it failed to copy the individual test output dEQP-GLES2.functional.buffer.write.random.0 for example just has bad results, no asserts or anything
<eric_engestrom> DavidHeidelberg[m]: ack; reassigned reviewing to him
<eric_engestrom> (also, I have a feeling the reason was that it made sense in an earlier revision)
<DavidHeidelberg[m]> Could be. He'll say his intentions :D
<zmike> Kayden: they all pass for me ?
<zmike> on icl too
<Kayden> zmike: all good then, it's possible something just hosed here
<zmike> 😬
agd5f has quit [Ping timeout: 480 seconds]
Lucretia has quit []
greenjustin has quit [Remote host closed the connection]
greenjustin has joined #dri-devel
idr has joined #dri-devel
agd5f has joined #dri-devel
rz_ has quit [Remote host closed the connection]
rz_ has joined #dri-devel
junaid has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
ngcortes has joined #dri-devel
Peuc_ has quit [Quit: Peuc]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Peuc has joined #dri-devel
the_sea_peoples has quit [Quit: WeeChat 2.8]
the_sea_peoples has joined #dri-devel
rz_ has quit [Remote host closed the connection]
rz_ has joined #dri-devel
Kayden has quit [Quit: office]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<zmike> since when is mesa main using clang-format?
<psykose> i think it was some parts since a few months ago?
<zmike> I thought it was just for specific drivers
<zmike> toxic
<psykose> your 3-space indents have been vanquished!
junaid has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
fxkamd has quit []
ngcortes has joined #dri-devel
Guest7140 has quit [Quit: Guest7140]
tursulin has quit [Ping timeout: 480 seconds]
lstrano has quit [Quit: WeeChat 3.5]
Ryback_ has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
kts has quit [Quit: Leaving]
lstrano has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
DottorLeo has joined #dri-devel
ngcortes has joined #dri-devel
DottorLeo has quit [Quit: Konversation terminated!]
<haasn> emersion: the flipside of cursor being redrawn at max fps means that touching your mouse will introduce frame stutters during video playback :^)
<haasn> as I discovered through debugging
<haasn> because in my case it pushes the monitor to 175 Hz which is not a clean multiple of most source framerates (24 Hz, 60 Hz)
<haasn> probably an implementation could be smart enough to measure the vsync timings of the "primary" application and only redraw at clean multiples.. :shrug:
<haasn> this is all voodoo territory
<haasn> even having a terminal printing log messages in the *background* while watching a video fullscreened in mpv is enough to destroy the fragility of VRR on wayland (kde plasma)
<haasn> so in conclusion, to get working VRR you must killall -9 all other processes, unplug your mouse, run mpv with --really-quiet, or indeed, just uninstall the compositor and watch in DRM
<haasn> year of the linux desktop 2023 celebration party when
<psykose> in 2024
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<emersion> this is a difficult problem to solve
<emersion> even if the compositor had all of the information
<Nefsen402> I must have bad eyes then. I don't notice any stutter when my monitors shoot up to 160hz after moving the mouse even with video playback with adaptive sync definitely working. I'd prefer to get a smooth cursor in these scenarios. Although maybe something could be done for notifications demons and such to prevent the sync rate of the monitor going out of whack
<Nefsen402> it might be caused by the monitor. Many monitors have problems with them changing sync rates ubruptly and causing brightness changes
sarnex_ has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
rmckeever has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<zamundaaa[m]> haasn: now you know why vrr is only enabled with fullscreen by default
<robclark> sima, airlied: re: drm/ci, so one upshot of moving everything into drm/ci instead of having all most of the yml+scripts in a different git tree is that I can't actually run CI without landing drm/ci (ie. the previous trick of configuring gitlab repo to use a URL to find gitlab-ci.yml doesn' t work). Which kinda makes me favor having the drm/ci patch on a branch that I can merge into msm-next (and any other drivers can do as
<robclark> well if they wish) for v6.6. Otherwise my CI setup is broken for the v6.6 cycle :-/
<Nefsen402> zamundaaa[m]: This isn't true. wlroots wayland compositors have VRR enabled in all situations. But this is a policy of the compositor, it's possible to implement what you have but it's definitely not a hard and fast rule
<sima> robclark, drm-tip integration tree? git merge doesn't really care much if a commit exists twice ...
<sima> or I'm kinda lost on context
<robclark> could be in drm next and I'll backmerge.. the issue is that the drm/ci commit actually needs to be in the branch that I want to run CI on
<sima> robclark, also I thought that for upstream the initial drm/ci should be a separate branch anyway, with separate pr to linus or something like that
<robclark> so however you accomplish that is ok
<sima> robclark, yeah the transition is a bit wonky
<sima> robclark, can't you just keep using the gitlab.yaml url setup trick until it's landed in enough branches, and then switch over for your driver's ci?
<sima> getting the foot into this door has taken forever, so what's another few weeks
<robclark> I should have written down the various gitlab repo settings I had to change
<sima> maybe :-)
<robclark> I guess I can figure it out again
<robclark> but pita
<sima> maybe #freedesktop can dig out a log?
<robclark> oh, and also I have to go back to v5 or so of the drm/ci patch
<sima> but yeah I think this issue is just another one to have it as a separate branch
<robclark> before everything was pulled in-tree
<sima> unless airlied wants to go real frisky :-)
<sima> hm
<sima> annoying
<robclark> yeah
<zamundaaa[m]> Nefsen402: I'm talking about KWin specifically, because haasn is using it for these tests. Obviously, other compositors can have different defaults
<sima> robclark, temporarily stuffing your branches into drm-tip + that branch (should be there anyway once we do the drm.git topic branch) to pave over the wobbly times?
<sima> and doing ci on drm-tip during those times I mean
<sima> or hand-roll the same I guess
<sima> or wait until airlied shows up, since I'm kinda falling asleep here ...
<robclark> I guess we could just manually cherry-pick the drm/ci patch as last patch on the branch to run CI.. and then just tag HEAD~1 for MR
<robclark> no worries, don't have to solve it tonight.. just wanted to point out that the workaround for drm/ci out of tree stops working with the in-tree version ;-)
<sima> yeah hand-rolling for now is probably best
<sima> I guess more important is to make sure this doesn't stick around for too long as an annoyance
<robclark> so I either keep testing the old version for a few more years, or we just decide to go ahead and land it and fix as we go ;-)
<robclark> yeah
<sima> yeah I'd say help collect acks on the current patch asap from everyone
<sima> and then airlied can stuff it into a drm.git topic branch
<sima> or me
<sima> airlied, dim help create-branch
<sima> dim create-branch drm/topic/ci v6.5-rc3
<sima> probably, didn't test it without --dry-run
<robclark> amdgpu, i915, mediatek, meson, and rockchip are the other ones (beyond msm) that have CI setup so maybe we can get acks from some of those drivers, I guess
<sima> robclark, yeah that'd be great
<sima> robclark, also acks from any other stakeholders
<sima> anyone else who cares
<sima> anyone who feels like this is cool
<sima> the more the merrier :-)
<sima> I can pile on too ofc
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
iive has quit [Quit: They came for me...]
pcercuei has quit [Quit: dodo]
konstantin has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
konstantin_ has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
* dottedmag wonders how macOS and Windows handle VRR
<dottedmag> The easy cop-out is enable it when there is a fullscreen application with direct scanout, and lock overlay updates to the refresh rate of main plane, of course.
illwieckz has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest7180
rsalvaterra_ is now known as rsalvaterra
Guest7181 has quit [Ping timeout: 480 seconds]
loki_val has joined #dri-devel
Kayden has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<jenatali> That's pretty much what Windows does, yeah