sdutt has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
piggz has joined #dri-devel
srslypascal is now known as Guest3571
srslypascal has joined #dri-devel
mhenning has quit [Quit: mhenning]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
piggz has quit [Ping timeout: 480 seconds]
Guest3571 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: hi, are you planning to merge back drm-fixes into drm-misc-fixes? Asking because mairacanal[m] wanted to push a fix for a patch that landed in v6.1-rc1
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
mvlad has joined #dri-devel
bbrezill1 has quit []
bbrezillon has joined #dri-devel
<tzimmermann>
javierm, is it a drm fix?
rasterman has joined #dri-devel
<javierm>
tzimmermann: yes, it's in drm-misc-next but not in drm-misc-fixes
<javierm>
tzimmermann: it's a fix for commit 453114319699
<tzimmermann>
what's the git hash?
<javierm>
tzimmermann: the one I shared ^
<tzimmermann>
i mean, what's the git hash of the fix?
<tzimmermann>
i wanted to send drm-misc-fixes today
<tzimmermann>
i can cherry-pick if it's not too large
<javierm>
a kunit test is broken when KASAN is enabled. But I think that we can wait for the next drm-misc-fixes batch
<javierm>
tzimmermann: are you going to merge back after this PR? I still don't quite understand at what point of the -rc cycle drm-misc-{next,fixes} are moved forward -rc1
<tzimmermann>
javierm, the commit 453114319699 isn't in upstream yet. so the bug fix probably doesn't go into drm-misc-fixes
Surkow|laptop has quit [Ping timeout: 480 seconds]
<tzimmermann>
'git tag --contains 453114319699' says that the commit is in drm-next. please put the bugfix into drm-misc-next and we should be fine
<javierm>
$ git tag --contains 453114319699 | tail -n1
<javierm>
v6.1-rc1
<tzimmermann>
ah, my git repo is outdated
<tzimmermann>
javierm, i'll backmerge drm-fixes and let you know when it's ready
tursulin has joined #dri-devel
<javierm>
tzimmermann: perfect, thanks!
fab has joined #dri-devel
fab has quit []
itoral has joined #dri-devel
fab has joined #dri-devel
Surkow|laptop has joined #dri-devel
MajorBiscuit has joined #dri-devel
chipxxx has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
hansg has joined #dri-devel
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
camus has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
fab has quit []
Ristovski has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
swalker_ has joined #dri-devel
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
swalker_ is now known as Guest3577
oneforall2 has quit [Remote host closed the connection]
fab has joined #dri-devel
oneforall2 has joined #dri-devel
fab has quit []
<tzimmermann>
javierm, drm-misc-fixes is now at v6.1-rc1
<tzimmermann>
javierm, i'll wait with today's pull request util you added your patch
<tzimmermann>
mairacanal[m] ^
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
jani_ has joined #dri-devel
oneforall2 has quit []
oneforall2 has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
<javierm>
tzimmermann: I think she is based in brazil so probably too early for her. I'll just go ahead and push that fix
fab has joined #dri-devel
<tzimmermann>
ok
fab has quit []
fab has joined #dri-devel
jani has quit [Ping timeout: 480 seconds]
fab has quit []
Guest3577 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
frankbinns1 has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
<javierm>
tzimmermann, mairacanal[m]: done
<tzimmermann>
thanks
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
<pq>
emersion, awesome that you are looking into the blind KMS prop save/restore!
<emersion>
:)
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
Ristovski has joined #dri-devel
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
<pq>
danvet, my immediate feeling about ATOMIC_RESTORE flag, if the semantics are "silently ignore bad values", is "no".
fab has quit []
fab has joined #dri-devel
fab has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
<pq>
zamundaaa, every KMS client is already relying on the initial state to be correct for all properties it does not explicitly understand.
fab has quit []
fab has joined #dri-devel
<pq>
zamundaaa, the default state idea is nice, and AFAIK not rejected, but needs someone to work on it in both kernel and userspace and actually define what that state is. That last bit is the difficult one.
<pq>
karolherbst, throw the official C/C++ extension out of your VScode, install the clang plugin instead, install the clangd from your distro, and then compile_commands.json will be enough.
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
<emersion>
pq, i was under the impression danvet didn't like the default state idea
fab has joined #dri-devel
<emersion>
in any case, i don't like ATOMIC_RESTORE either
<pq>
karolherbst, FWIW I do not use the Meson extension for anything but syntax (do not let the extension configure project). It doesn't suit the way I build stuff.
<danvet>
pq, well not "bad" values, but more "be slighty more lenient and guarantee that you can always write back what you've just read"
fab has quit []
<danvet>
because we managed to create a few very funny properties where that's not the case :-/
fab has joined #dri-devel
fab has quit []
<emersion>
i'd prefer to just fix our uAPI with quirks for the funny properties inside the kernel
<danvet>
so it would be more a w/a flag for kernel people merging bad uapi
<danvet>
emersion, but how do you want to fix them without adding a flag or something?
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
<danvet>
pq, my concern with the default state is more about who actually decides what the state should be
<emersion>
DPMS: mark it as immutable for atomic client
<danvet>
and where do you store it
<emersion>
CP: degrade enabled to desired
fab has joined #dri-devel
<danvet>
and aside from "works for me in this specific setup" I don't think the kernel is the right place in general
<emersion>
just like we do for link-status already
fab has quit []
<danvet>
hm yeah I guess that could work
<emersion>
danvet, i think all/most properties have a reasonable default value?
<danvet>
emersion, no
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
<danvet>
well they have "a" default value
<emersion>
which ones are problematic?
<danvet>
whether reasonable as in, "the user wont file a bug report" probably not
<emersion>
CTM/GAMMA_LUT have zero
<danvet>
anything around the fb has nothing
<danvet>
well, "it's complicated" at least
<danvet>
screen rotation I think is the big one
<emersion>
FB_ID has 0
<danvet>
which actually might mean you need to render rotated in software
<emersion>
rotation has 0
<danvet>
emersion, yeah but is that useful
<emersion>
yes, it's useful, user-space can always override it with a FB in the same commit if it wants to
<emersion>
we just need a "disable everything" thing
<danvet>
I guess the question is also what exactly do we want to achieve with the default state
<danvet>
like should the default state match what you get at boot-up for fastboot
<danvet>
or should it match something that guarantees backward compat when new properties get added
<danvet>
you can get bug reports either way
<danvet>
e.g. for hdr panels probably not the best idea to toss the lut
<pq>
danvet, my feeling against ATOMIC_RESTORE flag is that the state restoring atomic commit is practically never a pure restore commit but always includes some altered new state to get the desired image out at the very first commit after coming back.
<emersion>
the goal here is to just be able to get a sane state, instead of "oh the previous master left an overlay plane or HDR on and the output is all messed up"
<danvet>
pq, hm yeah, so emersion's idea of fixing the semantics probably better
<pq>
yup
<danvet>
emersion, yeah but what do you define as sane
<emersion>
IMHO sane is "everything disabled"
<danvet>
like if your colors are all gone to shit now I can expect bug reports
<danvet>
and people want to file patches to make the default state match what they want
<danvet>
*bam* bikeshed
<danvet>
so one set of drivers has the default state as "turn lut off"
<danvet>
the other set has it as "match the boot-up hdr lut because we have a customer who really wanted that and we don't have a team that works on userspace plumbing anymore so we fixed it in the kernel"
<emersion>
that's not what GAMMA_LUT=0 means?
<danvet>
yeah they'll keep a gamma table around as default state or something
<emersion>
if you want to retain a prop, you can read it back and include it in your first commit
<danvet>
and for developers "reload module" is usually good enough to beat kms back into a working state
<emersion>
but it's opt-in
<danvet>
emersion, yeah which is a way to implement default state, but in userspace
<emersion>
user-space cannot have default state
<danvet>
which is kinda why I lean towards keeping that entire default state business in userspace
<danvet>
why?
<emersion>
kernel can add props without updating user-space
<danvet>
if we go with the save restore then logind can sample the state at boot-up
<danvet>
and call that "default"
<danvet>
or well, default enough, for some value of default
<pq>
emersion, danvet, the content protection KMS prop is probably the reason why I have been strongly recommending to never use KMS props that can be modified by both userspace and kernel. That kernel feedback props should always be immutable and separate. ISTR I was too late for the content protection prop. :-/
MajorBiscuit has joined #dri-devel
<danvet>
ofc people will also be unhappy about default choices logind does
<danvet>
but at least it's not subject to the 10 year stable uapi gaurantee of the kernel
<emersion>
this just moves the problem from the kernel to user-space
<danvet>
and also everyone can have their own if they feel like
<danvet>
yeah, which is a Good Thing
<danvet>
imo
<emersion>
not from my PoV
<emersion>
it's convenient from the kernel dev PoV :P
<danvet>
yeah we both like to pass this bucket since it looks a bit nasty :-)
jkrzyszt has joined #dri-devel
<danvet>
I think we can expose the default prop value as in "if you don't know this prop, then setting this value will result in no chances compared to kernel which don't have this prop"
<danvet>
i.e. the "i'm oblivious" default
<danvet>
but it won't necessarily be the "my users are going to be happy" default
<emersion>
"no chances"?
<danvet>
because you might thrash some state that the kernel spend effort to careful inherit from the fw
<danvet>
and blindly setting it might still cause some regressions
<pq>
I think danvet typoed "no changes"?
<danvet>
and then we have to adjust this default state to also match the fw state, which wreaks driver load order
<danvet>
ah yes :-)
<pq>
The HDR panel case is an interesting anecdote, assuming the panel + driver circuit is physically incapable of displaying traditional SDR. The EDID would forbid SDR mode, HDR_OUTPUT_METADATA would have to be pre-set to the one HDR mode that works, and likely some LUT somewhere need to be pre-set to one that translates SDR to something tolerable on the panel.
<pq>
plus maybe backlight level
<danvet>
maybe I'm also just freaking out for no reasons and it never happens
<danvet>
pq, more thinking of some dumb panel that an oem hacked up and shipped with "works for me don't touch it"
<pq>
danvet, that's the same, isn't it? :-)
<danvet>
well might not even have infoframes or anything :-)
itoral_ has joined #dri-devel
<danvet>
emersion, so I think I'm warming up to your "fix the properties" idea for restore
<danvet>
trying to do the right thing there (and as much as we can fix it retroactively) sounds like a good idea irrespective of the default state discussion
<emersion>
cool!
<pq>
that just drops the HDR_OUTPUT_METADATA off that equation, but the LUT remains
<swick>
danvet: I think "if you don't know this prop, then setting this value will result in no chances compared to kernel which don't have this prop" is exactly what we want from the kernel
<swick>
solving flicker-free boot and smooth hand-off still requires user space coordination and that's completely fine
<danvet>
emersion, pq ^^ I'm happy to get overruled if there's solid consensus that this is useful and we should expose it in the getprop ioctl or wherever
<swick>
but there is no way we can deal with new kernels with new properties which change something
<danvet>
well just don't ever touch them and you should be fine
<emersion>
the problem is when someone else touches them before you
<swick>
even more horrible: rgb/yuv quantization range can be inferred from the mode so if we do that in user space and then a driver adds support for the broadcast rgb property it suddenly expects full range all the time and now everything is broken
<tleydxdy>
only consensual touches
pcercuei has joined #dri-devel
<pq>
Let's say I'm cautiously positive about swick's quote. It's not obvious to me that that's the best definition, but it sounds good.
<lygstate>
What's the point of st_gl_api_create, how about remove this indirection but replace it with st_gl_api_get, as it indeed create nothing
kts has joined #dri-devel
Company has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
itoral_ has quit [Remote host closed the connection]
ahajda has joined #dri-devel
devilhorns has joined #dri-devel
alarumbe has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
alarumbe has joined #dri-devel
Major_Biscuit has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
ppascher has joined #dri-devel
off^ has quit [Remote host closed the connection]
kem has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
zehortigoza has joined #dri-devel
fxkamd has joined #dri-devel
yuq825 has quit []
mbrost has joined #dri-devel
fab has quit [Quit: fab]
srslypascal has quit [Remote host closed the connection]
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
srslypascal has joined #dri-devel
MrCooper has quit [Quit: Leaving]
srslypascal is now known as Guest3587
srslypascal has joined #dri-devel
MrCooper has joined #dri-devel
srslypascal is now known as Guest3588
srslypascal has joined #dri-devel
Guest3587 has quit [Ping timeout: 480 seconds]
Guest3588 has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
sdutt has joined #dri-devel
<lina>
Is there a convention/trick for setting the stride of buffers where stride has no meaning (e.g. tiled)? alyssa and I were using 0 originally, but that fails with some code paths (e.g. Wayland dma-buf buffer import, because the EGL codepath treats a specified-but-zero stride as an error).
srslypascal has quit [Quit: Leaving]
<daniels>
lina: stride does very much have meaning for tiled buffers!
<daniels>
lina: I assume you've defined new DRM modifier codes for AGX tiling?
<lina>
I have (I actually just defined a real one just yesterday, we'd still been using the dummy one alyssa had for macOS use until then)
<daniels>
that's cool :) you'll just have to pick a convention to use for stride then; a common one is 'distance in bytes between vertically-adjacent tiles, divided by number of rows within the tile'
<daniels>
which is the closest analogue to the linear definition of stride, and similarly allows for horizontal padding
<daniels>
(nice work on Glamor btw - that's pretty much the end boss of GL users)
flto has quit [Remote host closed the connection]
jewins has joined #dri-devel
<lina>
I think the driver doesn't have a way to use it on the other end though, so I guess it would just be informative?
<lina>
Also Glamor is still broken, it's just not totally crashing X ^^
<lina>
Plain Xorg/xterm still glitches hilariously
<lina>
But at least now Xwayland starts up and doesn't crash, so KDE-wayland works
<daniels>
lina: hm, what do you mean by the driver not being able to use it? are you not able to map a (a,b)->(c,d) view of an image, where (a > 0 || b > 0 || c < w || d < h)?
srslypascal has joined #dri-devel
<lina>
The tile size depends on image size at smaller sizes, and there's also mipmapping to worry about, so I don't think that works in the general case...
<lina>
I'm not even sure if the hardware supports a concept of stride for images with this layout? Alyssa would know...
<daniels>
lina: gotcha :) so, the good news is that you don't have to worry about mipmaps, because you only use modifiers to exchange 2D, single-sample, single-LoD images
<lina>
Yeah, that makes sense
<daniels>
tile size vs. image size makes sense - tile size is something you'd encode into the modifier though
flto has joined #dri-devel
<daniels>
Broadcom/NV/AMD/AFBC modifiers are an example of this - you have a base modifier and then use a range of bits as a field to specify the tile size
<lina>
We don't specify that. The hardware just takes w/h and automagically computes everything.
<daniels>
so if you were given tile size + stride, you could retcon the image size back from that?
<daniels>
huh
<lina>
So as far as the hardware is concerned, there is one single modifier for "images in twiddled format", and they have a width and height, and everything else is magically derived from that (as far as image layout goes, pixel format/swizzle/etc notwithstanding), as far as I can tell
<lina>
And subimages don't work
<daniels>
so how do you calculate the total memory size required for a tiled image of dimensions w x h?
<lina>
There's a whole complex (and suboptimal for hardware implementation optimization reasons) algorithm for calculating the mip level offsets based on just image size and sample size as inputs
<daniels>
awesome
<lina>
For non-mipmapped images you can simplify it as just computing a tile size and aligning to that, I think
<daniels>
right, so you do know the tile size that you'll end up with?
<daniels>
(in any case, banning subimages is a totally OK thing to do)
<lina>
For a single mip level, yes, we can calculate that
<lina>
Also the tiles are stored in Morton order, not raster order
<lina>
The pixels within I mean
<lina>
The max tile size depends on the blocksize (one tile is always one 16K page)
<daniels>
yeah, that's fine - given that then, I would expect the stride to be defined as just (align(w, tile_w) * bpp)? you could then _either_ reverse that on import to get the total padded width, or validate that the stride matches the width you were given on import and reject if not
<lina>
Ah, so just treat stride as what it would be if the buffer were linear and padded?
<daniels>
essentially, yeah - still the logical distance in bytes between row n and row (n + 1)
<lina>
for some definition of "between rows" since that doesn't really work for Morton/Z order ^^
<daniels>
yeah, you sort of have to squint at it and pretend that tile_h==1
<daniels>
looking at it from the other direction, it would be alloc_size / align(h, tile_h)
<daniels>
(and please do encode tile size in the modifier if it's not going to be catastrophically bad)
<lina>
Do we really need to do that? It's kind of implicit (and we can't do anything with it if it doesn't match the expected one)...
<daniels>
I don't know the hardware well enough to say, but the general rule is to be as explicit as possible, because you can have mismatching versions of your GL/Vulkan driver between your client and compositor, so if you ever do (now or in the future) have any heuristics or whatever in your driver, then those heuristics effectively become ABI forever
<lina>
This is hardware, the actual hardware texture specifier takes w/h/levels/etc and a base pointer (and stride only for linear). Everything else is magic.
<alyssa>
daniels: Did I miss WSI talk? Uh, whoops.
<daniels>
lina: that truly is magic! ok, in that case it sounds like the best thing to do is to indeed just make the modifier be AGX_M1_TWIDDLED or so
<daniels>
alyssa: I know how much you love it
<alyssa>
:100:
* alyssa
reads scrollback
<alyssa>
'distance in bytes between vertically-adjacent tiles, divided by number of rows within the tile'
<alyssa>
lina: Mali hardware uses ^^ that definition, under the name "row stride"
<alyssa>
So if we use that, my vote is "row stride" because--
<daniels>
lina: btw, the reason I suggest AGX_M1_TWIDDLED is because it makes it a bit more obvious when you add AGX_M3_SUPERTILED_AND_PARAMETERISED or whatever later on down the road
<lina>
I think Apple themselves call it "twiddled" and it has existed for a few generations by now, but alyssa would have stronger opinions there
<vsyrjala>
can the display hardware eat that? and how does that figure out the stride?
<alyssa>
That is indeed my impression
<alyssa>
vsyrjala: It cannot
<alyssa>
TTBOMK
<lina>
There's also the scaler though, do we know whether the scaler can eat that?
<alyssa>
Also unlikely?
<alyssa>
In an optimized driver, twiddling is only used for formats that cannot support compression (for example due to being compressed already, like ASTC)
Leopold_ has joined #dri-devel
<alyssa>
or for usages where compression isn't possiblle (shader image writes, perhaps?)
<alyssa>
When possible, the driver likes to use compression.
<alyssa>
There are other tiling patterns used for compression (with other names)
* lina
runs `strings AppleM2ScalerCSC`
<alyssa>
I have not r/e'd any of the interesting details of compression, nor is it plumbed into Mesa.
<alyssa>
At any rate that will require a large pile of new modifiers.
<lina>
"%s Pitch must be power of two aligned for twiddle surfaces"... so apparently now we have some idea of a pitch, and support for twiddled surfaces in the scaler?
slattann has quit [Quit: Leaving.]
<lina>
Way to throw a wrench into things!
<alyssa>
Does anything use the scaler?
<daniels>
lina: right, so if you're passing through 'row stride' as suggested above, then the display driver can validate that align(w, tile_w) * bpp == supplied_stride
<alyssa>
Like, anything?
<lina>
On macOS I think it does?
<lina>
We don't have a driver for it yet though
<alyssa>
14:43 <daniels> lina: hm, what do you mean by the driver not being able to use it? are you not able to map a (a,b)->(c,d) view of an image, where (a > 0 || b > 0 || c < w || d < h)?
<alyssa>
No, I don't believe we can.
<alyssa>
(Except for linear images.)
<lina>
Strings suggest it can do fancypants HDR conversions and things like that, so Apple probably use it at least for video, behind the video decoder...
<daniels>
lina: makes sense - having a separate post-processing block is quite common for media, and V4L2 can do the mem2mem transformation thing quite well
<alyssa>
For mipmapping, the texture descriptor has a "first level" field specifically so you can map other levels
<daniels>
(now it's time for 4 hours of WSI workshop woo)
<alyssa>
And the width/height fields are of the base image
<alyssa>
With no pointer math involved
<alyssa>
(it has to be that way, because otherwise the hw will use the wrong tile sizes.)
djbw has joined #dri-devel
<alyssa>
14:45 <lina> I'm not even sure if the hardware supports a concept of stride for images with this layout? Alyssa would know...
<alyssa>
Correct. The hardware supports a "strided linear" mode for WSI, but otherwise stride is all implicit.
<alyssa>
14:56 <daniels> yeah, that's fine - given that then, I would expect the stride to be defined as just (align(w, tile_w) * bpp)? you could then _either_ reverse that on import to get the total padded width, or validate that the stride matches the width you were given on import and reject if not
<alyssa>
I don't like this because layout code should tell no lies (I am an isl fangirl)
<lina>
I'm tempted to say just set the stride to something but not validate it - then if we ever have to change that because the scaler wants a stride with a different meaning and it makes sense to export it that way, it won't cause problems with mismatches.
<alyssa>
And `align(w, tile_w) * bpp` doesn't have any physical or logical significance
<lina>
But I don't know if that makes sense...
<alyssa>
At least `align(w, tile_w) * tile_h * bpp`, i.e. the row stride, has physical significance.
<alyssa>
That's a quantity we can validate. But if it doesn't match on both ends, there's nothing we can do but fail
<alyssa>
(and one end is guaranteed to be broken code)
<alyssa>
lina: Also, CSC's idea of twiddling may be different from AGX's.
<lina>
It might be, yeah
<daniels>
alyssa: there are some components which will validate size >= stride * height ...
<lina>
Also even if it's more flexible than AGX, leaving that open for interpretation would cause a problem on the other direction
<lina>
daniels: Ouch...
<lina>
Okay, then it has to be a lie
<alyssa>
daniels: In that case, my vote is to use the bullshit (w * bpp) definition on the understanding it is completely meaningless ABI.
<daniels>
why not align to tile_w?
<alyssa>
We can align I guess
<alyssa>
It's equally nonsensical either way? :-p
<daniels>
(I'll grant you this is largely meaningless yes, but even so, being less surprising compared to other components is definitely a good thing)
<alyssa>
++
<alyssa>
The implementation details aside, the AGX twiddling is well-motivated
<lina>
(For what it's worth, my current solution is stride=1)
<lina>
(Lovely, I know, but it works!)
hansg has quit [Quit: Leaving]
<alyssa>
Apple uses 16K pages, so we use the tile size that ensures 1 tile is exactly 16 KiB because caches go brr
<alyssa>
For rgba8, that
<alyssa>
's 64x64
<alyssa>
for r8, that's 128x128
<alyssa>
However, if the entire image is smaller than that tile size, that uses too much padding
<alyssa>
So it instead switches to rounding the bigger dimension up to the next power-of-two tile sizes and using that, so we get square POT tiles and as little padding as possible
<alyssa>
The whole point is cheaper mipmapping, this means the tile size differs for different levels in a mipmap
<alyssa>
At level 0, use 64x64 tiles, but at level 10, use 2x2 tiles.
<lina>
And then the mip level offset calculation is a funny thing but which, in hardware, only requires a single small-bitwidth mul at the start and then just shifts and adds
<alyssa>
Right. That's why I said "implementation details aside"
<alyssa>
The concept is sensible.
<lina>
(At the cost of some spurious padding)
<alyssa>
The implementation is less so
<lina>
It took 3 people to reverse engineer that one...
<alyssa>
Which is some of my proudest work I would add...
<alyssa>
(That's only like 10% tongue-in-cheek)
<zamundaaa[m]>
MrCooper: about the tearing stuff... if I remember correctly, GNOME unredirects fullscreen windows, right?
<daniels>
alyssa: docs? you must be new around here
<zamundaaa[m]>
How does that work with applications like Firefox in terms of screen tearing on Xorg?
<alyssa>
daniels: I have this fantasy where I write docs and open well-written issues on the issue tracker and then new people will hack on the code and i get to retire some day
<alyssa>
I know, it's very unrealistic
<daniels>
zamundaaa[m]: Firefox is going to be decorated so won't be eligible for unredirect
<zamundaaa[m]>
decorated in fullscreen? LIike, when a video is playing?
<alyssa>
Anyway, I must be going now.
<alyssa>
Hopefully all parties enjoyed that, err, image layout experience.
<vsyrjala>
wtf. not seeing most debugs anymore w/ drm.debug=0xe? did the dyndbg stuff just totally break it or something?
<alyssa>
lina: I think our consensus is to use `align(w, tile_w) * bpp` as the EGL stride, validate it on import as a sanity check, and then ignore it. Just pure UAPI at that point.
<daniels>
zamundaaa[m]: in that case it should be, yeah
<daniels>
alyssa: ++
<lina>
alyssa: Sounds good to me!
<alyssa>
lina: Thanks for volunteering to write that patch
<daniels>
lina: yeah, thanks for pushing this forward, and sorry about winsys
<lina>
I mean, I already have a patch with stride=1 and I doubt you'll merge that one, so... not like I have a choice ^^;
<alyssa>
Giggl
<alyssa>
Oh shit does that mean I'm the maintainer?
<zamundaaa[m]>
daniels: I'm really wondering how that doesn't result in constant awful tearing with fullscreen applications. Because if there's some way to avoid that, then maybe the same can be applied to what I'm doing on Wayland
<alyssa>
Shit
<lina>
alyssa: ^o^
<karolherbst>
alyssa: you are the maintainer now
<alyssa>
karolherbst: Shit!
<karolherbst>
don't worry
<karolherbst>
same hapapned to me
<karolherbst>
*happaned
<anholt>
alyssa: agree that "`align(w, tile_w) * bpp" is the right thing for various egl, gbm, x11, etc. strides.
<anholt>
if you don't do that, you'll run into trouble where people do sanity checks for stride*h <= size.
<alyssa>
~~Someone needs sanity checks for the sanity checks~~
<karolherbst>
CI the CI
alyssa has left #dri-devel [#dri-devel]
<lina>
Speaking of CI... One day I'm going to have to set up CI runners for this stuff on real hardware...
<karolherbst>
don't worry, I was thinking about that for years for nouveau as well
<karolherbst>
but I suspect somebody will show up and do it for you :P
<karolherbst>
daniels seems to be volunteering here :P
<daniels>
lina: basically the crucial thing is completely bulletproof power-control automation and an extremely reliable UART - I know you have at least the latter through m1n1 (?) but not sure about the former
<daniels>
karolherbst: I'm not not volunteering
<karolherbst>
:'(
<daniels>
(well, plural 'I' ...)
<danvet>
daniels, lina for the "what stride" definition drm is somewhat opinionated and you need to use the one in drm_format_info_min_pitch() or it wont work
<karolherbst>
:'(
<anholt>
lina: if you can come up with some set of hardware that can be powered off of 30w of (12v, 5v, usbc) and run your ci stuff, I'm a sucker.
<danvet>
I had that discussion with arm afbc folks because they specced a stride half of what drm does and where unhappy that it broke everywhere
<danvet>
(got a bit behind on scrollback)
<lina>
daniels: We have both! We can do hard resets via USB-PD and get a real physical UART, and just have it boot into m1n1.
MrCooper_ is now known as MrCooper
<daniels>
lina: \o/
<lina>
You just need either two M1s or one M1 and some funny arduino thing to do the USB-PD comms
<daniels>
yeah
<lina>
My idea was to just boot via NFS or something, and not even bother with flashing images
<daniels>
anholt: do you have PD control in yours?
<danvet>
but I think the stride confusion only happens when you have compression, I think with tiled we didn't have anyone mixing things up yet
<daniels>
lina: oh yeah, flashing is a really good way to destroy your local flash really quickly
<anholt>
daniels: POE into a USBC poe extractor.
<anholt>
that's the jetson nano solution
<daniels>
anholt: oooh, link?
jkrzyszt has quit [Ping timeout: 480 seconds]
<lina>
(I don't think that does PD, just power control?)
<karolherbst>
yep. I can agree that PoE is a really cool solution once you have a switch/router you can throw HTTP requests at
<lina>
(We need USB-PD vendor defined messages to trigger reboots on otherwise not USB powered machines)
<MrCooper>
zamundaaa[m]: Firefox sets the prop which asks not to be unredirected
<daniels>
lina: all the Mesa CI (LAVA + bare-metal + boot2container) have a bootloader which can TFTP a kernel + initramfs and boot into that, with NFS rootfs
<lina>
Ah, ~same solution then ^^
<lina>
(We'd just load kernels over m1n1 instead)
<daniels>
++
<daniels>
there are/were some devices which fastboot rather than TFTP, same thing
<lina>
There's a thing with resetting the fail-to-boot counters (currently Linux does that, but it can be trivially done before loading a kernel by the m1n1 host, so you guarantee to never trip the boot-to-recovery mode as long as the m1n1 part is working properly)
<lina>
Actually I think the python m1n1 stuff also does it unconditionally anyway? So it probably already just works
<anholt>
lina: so, it doesn't just power on on transition from off -> on from PD? you have to send a command?
jkrzyszt has joined #dri-devel
<lina>
anholt: It's not powered via PD (they're either desktops or laptops with batteries)
<lina>
But what they do have is a vendor-specific command (VDM) that triggers a hard reset
<lina>
Every time I do `areset` in my streams, that's what I'm doing (usually when the USB connection flakes or the hypervisor wedges or I do something to break the m1n1 protocol)
<zamundaaa[m]>
MrCooper: hmm there is also the prop that asks KWin to disable compositing. If we can make use of that additional information, that would make things a bit easier
<lina>
You can instead cycle the physical mains power of the desktops, and set them to auto power on when AC is applied, and use a traditional PDU
<lina>
But it's not reliable, because apparently it only works if you actually *lost* AC power
<lina>
So if you do `shutdown -h now` in the OS, now you can't turn it back on
<lina>
So the USB solution is more reliable since that really does do a hard reset
<MrCooper>
zamundaaa[m]: a Wayland compositor could do tearing updates without unredirecting though, and "disable compositing" doesn't really make sense with Wayland :)
<zamundaaa[m]>
I'm more talking about when to allow tearing
<zamundaaa[m]>
Only games set the "disable compositing" prop
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
With the current approach, the compositor can't really make that decision because Mesa wouldn't pass the "swap interval 0" information on. We could maybe make Mesa check for the prop though
<MrCooper>
I'd rather not rely on indirect hints like that; also, even games shouldn't tear unless explicitly allowed by the user
<zamundaaa[m]>
Requiring the user to explicitly enable it somewhere is very far from what I want
<zamundaaa[m]>
(that is, per game / application)
<MrCooper>
it's very important to me not to end up with something like Xorg, where users keep hitting tearing when they don't want it
<zamundaaa[m]>
That will never be the case, as they can always conveniently disable tearing globally
<zamundaaa[m]>
With games, if vsync is off, tearing is expected and desired
<MrCooper>
they'll enable that because they read somewhere on the web it improves gaming
<MrCooper>
then they'll hit tearing in places where they don't want it
<zamundaaa[m]>
which would be where?
<zamundaaa[m]>
The "disable compositing" prop is really exclusively used by games and nothing else. The only issue it has is that not completely all games use it
<MrCooper>
"With games, if vsync is off, tearing is expected and desired" I disagree with
<zamundaaa[m]>
If you wouldn't want tearing in games, you shouldn't enable the global tearing option
<MrCooper>
the default behaviour should be mailbox
<zamundaaa[m]>
It's fine if you make that the default in your compositor, but that policy must not be hardcoded in Mesa
<MrCooper>
tearing may be desirable in certain competitive games, those are a minority
<lina>
anholt: I just checked and the USB-PD link survives (or rather comes back up) even when the machine does a normal shutdown, so you can send a reset command and turn it back on.
<zamundaaa[m]>
Anyone that wants tearing in any game is ok with having it in all games
<MrCooper>
I'd be kind of surprised if mutter will allow tearing at all
<lina>
So all you need is that single USB cable to a machine able to send VDMs to remotely control and reboot one of these machines, reliably
<zamundaaa[m]>
If a compositor wants, there's nothing preventing it from providing a per-game "allow" or "disallow" rule. I intend to make a window rule in KWin that allows toggling that for example
<zamundaaa[m]>
(we have an equivalent for X11 already)
<LaserEyess>
MrCooper: I can't comment on mutter but people stay on Xorg because they want tearing and it is impossible to tear on wayland. If you're worried about users making spurios bug reports because they somehow accidentally enabled tearing but don't want it, then you should also be concerned about the already existing bug reports of people who want tearing but can't turn it off
<vsyrjala>
yeah. drm dyndbg stuff just broken. sigh. this merge window is turning out terrible
<LaserEyess>
and in the case of accidentally turning *on* tearing, it's not like they can switch back to xorg to fix that
<MrCooper>
LaserEyess: I doubt most of those users really want tearing, as opposed to good latency, which is possible with mailbox (and improvements in Wayland compositors); those who truly want tearing are free to use Xorg
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<LaserEyess>
no, they want tearing
<MrCooper>
because somebody told them they need that for good latency
kts has joined #dri-devel
<zamundaaa[m]>
MrCooper: Possible and actually a thing in practice are two very different things. In practice you get 20ms additional latency with mailbox
<LaserEyess>
they know they want this, because it's what they get on windows, and whatr they get on xorg, and what is needed for *0* latency for competitive gaming
<daniels>
anholt: looks like that only sticks 5V + 2.4/4A over vbus, not actual PD
<daniels>
MrCooper: some people do genuinely legit want actual tearing
<daniels>
I don't mind them being able to opt in to that
<anholt>
daniels: yeah, I guess? didn't look into the details, was enough for the nano
<LaserEyess>
^
<MrCooper>
zamundaaa[m]: we're gonna need to fix that in the Wayland compositors, I'm working on it for mutter
<zamundaaa[m]>
MrCooper: it has nothing to do with Wayland compositors
<zamundaaa[m]>
You get the same on Xorg without compositing
<MrCooper>
I know some really do want tearing for competitive gaming, but I'm convinced it's a small minority among gamers
<MrCooper>
zamundaaa[m]: yep, mailbox is totally busted in Xorg
<lina>
I don't think it's even possible to get traditional tearing on Apple M1 platforms... I'm not sure if the display controller supports non-synced page flips, and you can't (reliably) render directly to the scanout buffer in a reasonable way.
<lina>
Short of rendering to an offscreen buffer and manually blitting...
swalker__ has quit [Remote host closed the connection]
<daniels>
lina: so guess what Xorg does ...
<lina>
CPU blits?!
<LaserEyess>
MrCooper: chicken/egg, most competitive gamers aren't asking for tearing on wayland because they are on windows, the ones who want to use wayland *cannot* because of this
<LaserEyess>
I mean, I'm sorry but this is just a fact, people want tearing
<LaserEyess>
idk what else to tell you
<MrCooper>
zamundaaa[m]: there's no fundamental reason why mailbox would have to add more than half a refresh cycle worth of latency on average
<zamundaaa[m]>
MrCooper: I don't disagree that the 20ms I measure on my PC is the best that's possible, but you physically cannot make it as good as tearing
<zamundaaa[m]>
Even with FreeSync you're looking at about 5ms additional latency on my 120Hz screen (measured in the middle of the screen). That is with like 300fps in the game, but that's not unrealistic for competitive shooters
<danvet>
vsyrjala, :-/
<danvet>
it should not have at all, but also I kinda didn't test it :-(
<vsyrjala>
i think some magic trigger is missing to patch in the things when the module loads
<vsyrjala>
but haven't looked at that stuff at all really. so just a hunch
<anholt>
insofar as managing hardware farms can be
<daniels>
anholt: the definition of 'damning with faint praise'
<danvet>
vsyrjala, hm yeah the POC patch also landed, I thought that one wouldn't
<danvet>
or maybe I got confused
<danvet>
oh gregkh just kinda merged it all
<danvet>
yeah that was a lot more than I thought
<danvet>
vsyrjala, f158936b60a7874f29cf8de8d83191ad69119c11 nuke this (and anything you need to nuke on top)
MajorBiscuit has joined #dri-devel
<swick>
zamundaaa[m]: if you get any kind of increased latency with vrr compared to tearing frr, things are going very wrong somewhere
<zamundaaa[m]>
I'm pretty sure that's expected
ybogdano has joined #dri-devel
<swick>
it's not
<zamundaaa[m]>
I'm measuring in the middle of the screen. With VRR, when a frame is posted, you have about half the frame to wait until you actually see what's in the middle
<zamundaaa[m]>
With tearing, the screen updates a bit faster and that restriction is not there
<zamundaaa[m]>
In my case there were about 3 part-frames. So it's completely expected that latency is lower
<swick>
oh man, at that point you have to argue about what constitutes an update
<swick>
would you still say it has lower latency if only the last line of the new image was drawn in that scanout cycle?
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
swick: it's pretty simple. What matters is when the user sees the part of the screen that they care about
<zamundaaa[m]>
For first person shooters, that's almost always in the middle of the screen
<zamundaaa[m]>
swick: so no, that doesn't count
<swick>
sorry but that's just an arbitrary metric
<zamundaaa[m]>
What metric would you use?
<swick>
latency for a full update
<zamundaaa[m]>
What matters is at which point the user sees what matters to them. They don't need a full update for that
<swick>
they also might not need the center of the screen
<zamundaaa[m]>
That's true. It might be towards the bottom of the screen, where the latency difference is even greater
<swick>
or the very top where the difference is also greater, but in the other direction
<zamundaaa[m]>
Why would it be?
<zamundaaa[m]>
If you measure the very first row of pixels you could get a theoretical better latency value with FreeSync, but tearing catches up in just a few scanout lines (depends on the fps and refresh rate of the screen ofc)
tzimmermann has quit [Quit: Leaving]
<swick>
no, tearing frr might still happen at any point in time
<swick>
and if the rendering is later than the point where the first lines were scanned out you have to wait for the next refresh cycle
<swick>
much worse latency suddenly
<zamundaaa[m]>
You don't have to wait a refresh cycle with tearing
Jeremy_Rand_Talos has joined #dri-devel
<zamundaaa[m]>
That's the entire point of it
<swick>
ofc you do. if the information you want is in the top lines and the top lines were scanned out already you have to wait for the next refresh cycle.
<swick>
... for the information to become visible
<zamundaaa[m]>
For the special case of the thing of interest to be in the first scanout lines, yeah
<zamundaaa[m]>
To put it a bit into perspective though, the first few scanout lines effectively never matter. Except if you're playing Tetris of course :D
<swick>
you cherry picked one metric in which the tearing frr case works well on average but the latency has much higher variance. with vrr the latency is consistent and good.
<swick>
where the latency is better depends on what information you need but the higher variance is just objectively worse with frr tearing
<zamundaaa[m]>
In almost all non-first-person-shooter games, the area of interest will be on some point of the screen, at random. So on average you get a lot worse latency with vrr
<zamundaaa[m]>
swick: looking at the main use case isn't really cherry picking
<swick>
you keep saying this but it's not true. if the information you want is juuust above the center the latency increased by 1 whole refresh cycle
<zamundaaa[m]>
the same applies to vrr though
<zamundaaa[m]>
so I don't see the point?
<swick>
no, you get that information consistenly after whatever time it takes to reach the scanline your information is in
<zamundaaa[m]>
The same is true with tearing
<swick>
no it
<swick>
's not
<zamundaaa[m]>
It's not a random thing. Creating an easy example, with 360fps on a 120Hz screen you always get 3 updates
<zamundaaa[m]>
The position of these updates will vary a bit, but if something is just above the center you're guaranteed to get better latency than vrr in all cases
<swick>
okay, if you have multiple updates in one refresh cycle that's true
<zamundaaa[m]>
That's an assumption you can make
<swick>
it sure is. that's also an assumption you don't have to make.
<swick>
again, it depends on so many things at this level
<zamundaaa[m]>
If we want to automatically optimize for the best latency, considering the "20% more than native refresh rate" case is interesting though
<swick>
all I'm saying is that you picked the optimal condiations for frr tearing
<zamundaaa[m]>
Like, the compositor could maybe measure the frame times, extrapolate if tearing or vrr would be better, and dynamically switch. But as a first step, tearing needs to be possible
<zamundaaa[m]>
swick: The optimal conditions would be on the bottom of the screen
<swick>
you could just as well pick the optimal conditions for vrr and conclude that vrr is just "objectively" better than frr tearing
<zamundaaa[m]>
again, the middle of the screen is not something I chose to get a specific result
<zamundaaa[m]>
It's what's important for most people that care about latency, and it fits most other applications on average as well
<swick>
the assumption that you have multiple updates per refresh cycle changes everything in frr tearing's favor
<zamundaaa[m]>
It's an assumption that will hold true for anyone who cares about latency
<swick>
sorry but no
<zamundaaa[m]>
People turn down their settings even in light games like CS:GO, amongst other things to get this advantage
<daniels>
swick: people do literally want this
<swick>
if you care about latency you get a high refresh rate display and getting a multiple of e.g. 240hz updates is unrealistic
<zamundaaa[m]>
swick: those that are rich enough to get such monitors do have PCs that do 600+fps
<swick>
higher refresh rate displays also have lower latency in the display itself to achieve those high refresh rates
<daniels>
there are people who really want to play games literally as fast as absolutely possible, and do not have 240Hz displays
<daniels>
it's not just two random people on the internet, but an actual class of users which exist in reality
<daniels>
if you don't like it, that's fine and you don't have to implement it in your compositor, but you can't handwave it away as not being a usecase
<swick>
sorry but people on the internet want a lot of things which are objectively bullshit
<zamundaaa[m]>
swick: but it's objectively not bullshit in this case
<daniels>
swick: 'objectively'
<swick>
i'm not saying this case is
<swick>
but i'll bet a lot of money that it's placebo
<zamundaaa[m]>
swick: fwiw, for most people that don't care about this stuff, defaulting to use vrr when available makes sense. But for those that do care, it's just not enough
<karolherbst>
it's not
<karolherbst>
anyway, could we bikeshed less?
<karolherbst>
120Hz is better than 60Hz for _real_
<karolherbst>
that's not placebo
<karolherbst>
the difference is sooo obvious
<karolherbst>
try it out foryourself before making such assumptions
<karolherbst>
there might be a range where the difference doesn't outweight the cost, but I can believe that even 240 vs 120 makes a huge difference
jkrzyszt has quit [Remote host closed the connection]
<daniels>
we don't need to bikeshed - if swick thinks it's pointless placebo, then swick is free to not bother implementing it
<daniels>
people who are interested in it can go forward with it
<zamundaaa[m]>
swick: when I have time I'll measure those edge cases like "on top of screen", "on bottom of screen", "tearing + only 150Hz". But as far as I can see, there's not much new to be learned
<swick>
seriously, put some fake scanlines on a vrr output and test that against tearing frr
<swick>
and I
<zamundaaa[m]>
swick: I measured it with a microcomputer and some sensors
<zamundaaa[m]>
Not with eyes
<swick>
yes, a very specific case
<daniels>
swick: shrug, that's your measurement, not mine
<zamundaaa[m]>
*microprocessor
<swick>
just like I could measure vrr performing better than frr tearing if I choose the test like that
<swick>
and no karolherbst I didn't say anything like lower refresh rate is better than higher refresh rate
<karolherbst>
MrCooper: yeah.. I only have 60 on my compute :( 120 on my TV though
<swick>
and I'm also not against people implementing tearing if they want to do that
<MrCooper>
daniels: I acknowledge that it's a valid use case, but since the class of users interested in it is a minority even among gamers, it should not be the default behaviour for all applications even if enabled in general
<swick>
because there are cases where you can get significantly better latency with tearing
<swick>
if you're stuck on a 60hz display and it's likely that you can get multiple updates per scanout cycle and tearing really does help there
<zamundaaa[m]>
MrCooper: again, I'm fine with that being the policy in the compositor of your choosing. But this policy must not be done in Mesa
Leopold_ has quit [Ping timeout: 480 seconds]
<swick>
but if you want low latency get a somewhat good monitor and then tearing will be purely placebo
<zamundaaa[m]>
swick: even if it was placebo, "get a somewhat good monitor" is not an option for many many people
ybogdano has quit [Read error: Connection reset by peer]
<daniels>
Mangix: I agree it absolutely has to be opt-in
<daniels>
MrCooper: ^
<swick>
zamundaaa[m]: but getting a GPU to produce multiple updates per refresh cycle is?
<zamundaaa[m]>
swick: yes. There's a reason games have graphics settings, and with e sports titles they go really low
<zamundaaa[m]>
daniels: if the user goes into the settings and sets it to allow tearing, why should they need to use env vars or similar per game to activate it there again?
<daniels>
zamundaaa[m]: I agree with you, yes
sdutt_ has joined #dri-devel
kts has quit [Quit: Leaving]
<daniels>
I'm arguing that the desired semantics are: we don't tear by default, but if the client opts in to tearing (because it's forced to by OS policy, or the game just does it always, or the user goes and clicks something - whatever), then they can have the thing they asked for
<karolherbst>
sounds like a sane policy to me
sdutt has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Yeah. The problem is that with glx and egl, there's no difference between mailbox and immediate mode
<zamundaaa[m]>
So the thought was that we have a X11 prop for KWin, which almost all games use to disable the compositor on Xorg. If we combine that + swap interval 0, that would imo be enough to indicate a desire to get tearing
<zamundaaa[m]>
And all applications that don't set it, get mailbox instead like until now
<karolherbst>
some games have terrible vsync implementations though :/
<karolherbst>
so in some cases disabling vsync is what you want even without wanting tearing
<zamundaaa[m]>
The alternative is to just leave glx and egl as-is, which is, they all get mailbox with swap interval 0. Until a new egl extension is made (which would be needed for Wayland anyways), requesting tearing would be exclusive to Vulkan
<karolherbst>
yeah... but I think what I noticed was more like windows game being weird sometimes where enabling Vsync adds a significant input latency to a degree it's not bearable
<karolherbst>
but maybe we can fix that in wine
<zamundaaa[m]>
Another alternative is to do that + provide an env var that allows you to still get tearing with glx and egl
<LaserEyess>
karolherbst: I think something like gamescope is designed to take care of most of that, no?
<zamundaaa[m]>
karolherbst: personally for KWin I intend to add a window rule that allows or disallows tearing. So you could disable vsync in the game and then disable tearing for that one game through the compositor option
<zamundaaa[m]>
Most users that don't like tearing would just leave it disabled globally though
<karolherbst>
yeah sure.. that's all nice and that, but users want the perfect solution straight away and only bother with having one in game flip :P
<karolherbst>
but yeah...
<karolherbst>
guess certain games/apps will require more OS specific workarounds
<karolherbst>
LaserEyess: yes, so the compositor makes it not tear and everything is fine. But once we decide "in game vsync off" actually means it, we are screwed
<karolherbst>
but maybe we could add game specific workarounds as this is usually not the case
<LaserEyess>
well, that's a different problem entirely than vsync being implemented poorly
devilhorns has quit []
<karolherbst>
yeah...
<LaserEyess>
ultimately, even on windows most games require ridiculous workarounds to work properly
<LaserEyess>
not much you can do about it unless you want mesa to carry around 100s of MB of games specific hacks and overrides
<karolherbst>
it gets worse when games carry driver specific workarounds we will have to workaround
<zamundaaa[m]>
To get progress at all I guess I'll just restrict tearing to Vulkan for now, and lock tearing with glx and egl behind an env var. Additional workarounds and stuff can be added later...
ybogdano has joined #dri-devel
<zamundaaa[m]>
I do expect user complaints with that though. CS:GO still uses OpenGL by default
<karolherbst>
could add a cs:go specific workaround :P
<zamundaaa[m]>
It's not the worst idea
<zamundaaa[m]>
Why didn't anyone working on OpenGL ever think about swap interval 0 being too vague. Would've made things a lot easier...
<karolherbst>
¯\_(ツ)_/¯
<jenatali>
WGL has a separate tearing extension, FWIW
<jenatali>
(I know very little about EGL/GLX in this space though)
<jenatali>
And D3D up until ~2015 didn't distinguish swap interval 0 between mailbox and tearing, but nowadays it does
frieder has quit [Remote host closed the connection]
Leopold has joined #dri-devel
<Frogging101>
zamundaaa[m]: A window rule for this sounds great
<zamundaaa[m]>
jenatali: there's an extension for GLX, but it only does negative swap intervals, so "tear if late". For egl there is a proposal that I think would solve this but there's been no action on it for two years
<jenatali>
Ah yeah that's what the WGL one does too, but 0 is specified to be unsynchronized/tearing
<daniels>
yeah, EGL_EXT_swap_control_tear is VK_PRESENT_MODE_FIFO_RELAXED_KHR
<daniels>
*GLX
<zamundaaa[m]>
jenatali: it's specified like that for egl and glx too - or at least there's no guarantee of not-tearing. We can't translate that to "wants tearing" though because in practice, applications expect it to be turned into mailbox behavior by a compositor on Linux
<zamundaaa[m]>
Instead of using negative swap intervals for "tear late", it just adds another property that causes frames to tear if late. With a swap interval 0, it would be always late and thus always tears
<vsyrjala>
hmm. what are apps doing that breaks with tearing swaps?
<zamundaaa[m]>
They play videos for example
<zamundaaa[m]>
It's not so much that things actually break, but we obviously don't want tearing for stuff like that
<daniels>
or anything which sets SwapInterval to 0 and then does its own sync back to the winsys repaint cycle in order to avoid blocking in eglSwapBuffers
<vsyrjala>
ah. so one of those "hack it until it seems to work and then ship it" type of things
<zamundaaa[m]>
Sort of. I can't blame applications too much, with OpenGl not providing a proper alternative
<daniels>
^
<daniels>
EGL just doesn't give you a better way
<daniels>
it's designed to make while (true) { glDrawElements(); eglSwapBuffers(); } latch to the underlying refresh cycle, which makes things worse for everyone who isn't that
<swick>
I still don't really get how this conversation ended with some thinking I argued that high refresh rates are bad and that tearing is never useful when all I did is point out that if vrr is supported it can be lower latency than tearing (and zamundaaa[m] pointing out that in some situations tearing can still be lower latency)
<swick>
was what I said so unclear?
piggz has quit [Quit: Konversation terminated!]
piggz has joined #dri-devel
carbonfiber has joined #dri-devel
piggz has quit [Ping timeout: 480 seconds]
<carbonfiber>
What is preventing DRI3 from working when using xorg inside of virtualbox? I am using the modesetting driver which I thought was DRI3 only, but various software reports the DRI3 extension as not working.
lygstate has quit [Remote host closed the connection]
srslypascal is now known as Guest3607
srslypascal has joined #dri-devel
Guest3607 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<dj-death>
anybody knows why amdgpu would refuse to import a dmabuf coming from i915
<dj-death>
drmPrimeFDToHandle() returns -1 with errno=EOPNOTSUPP
Surkow|laptop has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
Surkow|laptop has joined #dri-devel
l554 has joined #dri-devel
eukara has quit [Remote host closed the connection]
Ristovski has joined #dri-devel
gouchi has quit [Quit: Quitte]
[Ristovski] has joined #dri-devel
<agd5f>
dj-death, buffer alignment?
<dj-death>
agd5f: possible
<dj-death>
not getting any trace with drm debug = 15
Ristovski has quit [Ping timeout: 480 seconds]
<dj-death>
agd5f: although I doubt the alignment be a problem just to create a BO
<agd5f>
dj-death, oh, -1 is -EPERM
<dj-death>
agd5f: -1 is the return value, but I think the value of errno is usually relevant
<dj-death>
as usual the kernel are completely useless :
<vsyrjala>
enable the function tracer and try to follow it along?
<airlied>
but usually make sure it's not tiled and then it's probably some linear alignment on stride
<airlied>
but that seems like a wierd error
<dj-death>
it's linear afaict
<dj-death>
but even then, the import is like a lower level operation
<dj-death>
tiling shouldn't matter
<airlied>
so for linear make sure you have at least 256 stride I think
<dj-death>
where do special that when import the dmabuf?
<airlied>
I don't think you can do it on import, it's too late
ybogdano has quit [Ping timeout: 480 seconds]
<airlied>
but EOPNOTSUPP seems like the wrong error msg for that fail case
<airlied>
dj-death: if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) seems the most likely reasons on the i915 side
<dj-death>
airlied: thanks a lot
<dj-death>
airlied: sounds about right, the integrated GPU on this machine can display on the AMD card find
<dj-death>
but the DG2 one is unable to share anything in wayland
<dj-death>
and with X11 the rendering is completely broken
<dj-death>
80% or 50% of the app render image is just blank
<dj-death>
so we probably don't place the buffer in the right mem
ngcortes has joined #dri-devel
l554 has left #dri-devel [#dri-devel]
<bl4ckb0ne>
is there an intel gpu related chan?
<bnieuwenhuizen>
#intel-gfx and #intel-3d
<bl4ckb0ne>
thanks
Duke`` has quit [Ping timeout: 480 seconds]
rgallaispou1 has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
mvlad has quit [Remote host closed the connection]
rgallaispou has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Heil_Hitler has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Company has quit [Quit: Leaving]
Heil_Hitler has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2022-10-20 22:21:07)]
ahajda has quit [Ping timeout: 480 seconds]
Heil_Hitler has joined #dri-devel
<karolherbst>
dcbaker: mhh.. meson doesn't seem to create a rust-project.json file anymore :/
<karolherbst>
ohh wait.. that was me being silly
<karolherbst>
heh.. 0.63.3 doesn't give me that :/ odd
fxkamd has quit []
Heil_Hitler has quit [autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2022-10-20 23:05:38)]
<dcbaker>
It was new in 0.64 it looks like
<karolherbst>
yeah.... I was under the impression it got merged way earlier, but...
<karolherbst>
oh well
pcercuei has quit [Quit: dodo]
<pzanoni>
So, I'm learning the timeline syncobj API. There's nothing that helps with overflow, right? I mean, once I signal the biggest possible value, the only way to keep using it is to reset it. Is that correct?