<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
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
<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
<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]