sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tzimmermann has joined #dri-devel
zackr has quit [Remote host closed the connection]
zackr has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
danylo has joined #dri-devel
tursulin has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
hansg has joined #dri-devel
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
crabbedhaloablut has joined #dri-devel
loki_val has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
flynnjiang has quit [Quit: flynnjiang]
camus1 has quit []
camus has joined #dri-devel
garrison has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
cheako has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
<karolherbst>
tomeu: right... and spir-vs with that are already supported, I'm mostly wondering if I can test the arm version of that extension
aravind has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
garrison has quit [Read error: Connection reset by peer]
yyds has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
garrison has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
MTCoster has quit [Read error: Network is unreachable]
MTCoster has joined #dri-devel
<sima>
emersion, the async you commented on means tearing, usually the async on cursor means "allow more updates to hit the same frame"
vliaskov has joined #dri-devel
MTCoster has quit [Read error: Network is unreachable]
zx2c4_ has quit [Write error: connection closed]
ogabbay has quit [Read error: Network is unreachable]
angular_mike_______ has quit [Read error: Network is unreachable]
pundir has quit [Read error: Network is unreachable]
TimurTabi has quit [Write error: connection closed]
angular_mike_______ has joined #dri-devel
jimjams has quit [Read error: Network is unreachable]
i509vcb has quit [Read error: Network is unreachable]
bwidawsk has quit [Read error: Network is unreachable]
alatiera has quit [Read error: Network is unreachable]
zmike has quit [Write error: connection closed]
ogabbay has joined #dri-devel
pundir has joined #dri-devel
TimurTabi has joined #dri-devel
jimjams has joined #dri-devel
i509vcb has joined #dri-devel
MTCoster has joined #dri-devel
zx2c4_ has joined #dri-devel
alatiera has joined #dri-devel
bwidawsk has joined #dri-devel
zmike has joined #dri-devel
<pq>
sima, does cursor-async then not allow cursor tearing?
<sima>
the one we currently have doesn't really
<sima>
well, it maybe does
<sima>
cursor-async is still a giantic mess :-/
itoral has quit [Remote host closed the connection]
glennk has joined #dri-devel
mclasen has joined #dri-devel
kts has joined #dri-devel
<zamundaaa[m]>
Tbh whether or not the cursor actually tears is quite irrelevant to me at least
<zamundaaa[m]>
"Async" cursor updates + tearing on other planes would be enough
macslayer has quit [Remote host closed the connection]
<zamundaaa[m]>
Hmm actually, as that's already allowed with the legacy cursor ioctls, is there any reason not to allow that with all drivers that support async?
<Venemo>
gfxstrand, zmike, alyssa, mareko Do you guys think there is any interest left in supporting NV mesh shaders in either VK or GL? if not, is it okay if I open a MR to delete its remnants?
robmur01 has joined #dri-devel
Dark-Show has quit [Ping timeout: 480 seconds]
<zmike>
it might be neat to support on zink+nvk at some point? I could imagine someone taking it as a hobby thing
<Venemo>
I know there are some users who want it
<Venemo>
if there is some willingness to eventually support it, I say let's keep the common parts of it for now
<zmike>
I'm not 100% against it since there's apparently that minecraft mod
zf has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<CounterPillow>
Doesn't Alan Wake 2 use mesh shaders extensively?
Leopold_ has joined #dri-devel
<pixelcluster>
mesh shaders themselves are still going to be supported
Leopold_ has quit [Remote host closed the connection]
sewn_ has quit [Remote host closed the connection]
<sima>
zamundaaa[m], we could wire those up for drivers that support async on cursors
sewn has joined #dri-devel
<sima>
once the infra for async=tearing for cursors gets there
<sima>
atm it's kinda the other async
<sima>
or if that doesn't work, a terrible hack that I should never have landed because it breaks the atomic state structure lifetime rules really badly
Leopold_ has joined #dri-devel
ascent12 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
<sima> "atm it's kinda the other async" <- That doesn't matter though. Noone cares if the cursor actually does tearing
<zamundaaa[m]>
I'm saying it's fine to have tearing primary plane + "mailbox" cursor, in the same commit
kts has quit [Ping timeout: 480 seconds]
<sima>
zamundaaa[m], yeah I got that, just wanted to add a bit of detail
<sima>
zamundaaa[m], the other thing is that at least in the drm core parts, cursor is just a plane with a flag so it's used for legacy cursor ioctls
<sima>
which means on many hw it's actually a full sized plane and can be used as such
<sima>
and there this combo is probably not what you want at all
yuq825 has left #dri-devel [#dri-devel]
<sima>
for small cursor planes it doesn't matter whether you tear or not, but if your cursor plane is the main game scene it kinda does
<pq>
cursor tearing can manifest as half a cursor at the top of the screen, and another half at bottom of the screen, right? Since it's not just tearing plane content update, but also plane moving?
<pq>
or even multiple cursor images on the same refresh cycle
Leopold_ has quit [Remote host closed the connection]
<sima>
pq, I guess you could even have like two cursors at the same time
<sima>
or multiple teared ones
<sima>
like if you move in sync with scanout, you could probably have a _lot_ of teared partial cursors
heat_ has quit []
heat has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<Company>
I'm confused
<Company>
Epiphany uses dmabufs to communicate between web process and ui process, and it uses dmabufs for that
<Company>
and it uses gbm to allocate these
<Company>
apparently on "Intel Corporation Raptor Lake-P [Iris Xe Graphics]" this selects a 3-plane dmabuf format
<Company>
but the Vulkan code can't import it
<Company>
and my TigerLake claims it can't import disjoint dmabufs
<emersion>
you need to check whether the FDs are the same memory object
Leopold_ has quit [Remote host closed the connection]
<emersion>
then use a non-disjoint Vulkan import
<emersion>
see wlroots code for example
<Company>
so I get different fds and then have to figure out if they are the same thing?
<emersion>
the FDs will always be different
<emersion>
as in, the file descriptor numbers
<Company>
yeah, that's what I mean
<Company>
I've gotten dmabufs with the same fd numbers
<emersion>
if you send the same FD twice over a Unix socket, the other side will get two different file descriptors
<emersion>
same as dup()
<Company>
ah yeah - might have been libv4l or something then
<emersion>
different FD number doesn't mean different underlying memory object
<Company>
sure
<emersion>
and Vulkan's disjoint only cares about the latter
<Company>
I can fix that, I just need to figure out what to care about
<sima>
emersion, didn't we have a discussion about kcmp syscalls about this topic?
<sima>
there's plenty of -5
<sima>
if you include cache coherency there's still plenty of -10
<pq>
I remember kcmp has been mentioned in the past few years.
<emersion>
i just use GEM handles to tell
<emersion>
iirc
<sima>
emersion, yeah but that needs a driver that doesn't refuse the import
<sima>
but I guess at that point you don't care anymore anyway
<Company>
daniels: "at least" is doing a lot of work in that sentence
Leopold_ has joined #dri-devel
<daniels>
Company: I'm feeling generous today
<Company>
daniels: there are a bunch of places that hit -7
<sima>
I mean the goal of dma-buf was to at least sometimes, make the formerly impossible possible
<Company>
like this one
<sima>
we got that :-D
<daniels>
sima: I thought the goal of dmabuf was to be a totally universal allocator that would solve all known problems
<sima>
nah we punted that to userspace :-P
<Company>
and now we're closer to world peace than to that
<pq>
that's a really nice gradient on the background of that webarchive page
<Company>
anyway, I'm going to get this working, dmabufs haven't defeated me yet and they won't in the future
<sima>
daniels, like the reason behind the "every driver yolos its own dma-buf exporter" was because the universal allocator was impossible
<daniels>
sima: i know, i know :)
<sima>
I'm kinda still surprised how often we actually managed to make it work
<daniels>
but yeah, I probably shouldn't make statements like that without explicit sarcasm indicators, given how much people seem to assume that 'dmabuf will translate my poorly-expressed hopes and dreams into proper solutions' is actually the intention and/or reality
kts has joined #dri-devel
<sima>
and how little we had to break given some of the really horrendous first implementations
<daniels>
well yeah, we did make it mandatory right
simondnnsn has quit [Read error: Connection reset by peer]
<daniels>
I mean, it's not some weird luxury option that you can enable if you're really fancy; it's something you need if you want to display anything at all
simondnnsn has joined #dri-devel
<sima>
dumb buffer + memcpy would still work
* sima
should also enable the sarcasm indicator on all of this
<Company>
if people would spend a bit more time talking to each other, this would already improve things massively
<Company>
just because of the knowledge transfer
<Company>
because this channel is pretty much the only place where I can figure these things out - and only if I'm lucky and the right person sees this
kzd has joined #dri-devel
<MrCooper>
emersion Company: I'd say GEM handles is the only way to be sure — even if the file descriptors reference separate dma-buf file descriptions, they could still reference the same underlying BO
<emersion>
yeah, it should be more reliable
<Company>
oof
<Company>
I'll wait for PFN_vkCheckDisjoint
Leopold_ has quit [Remote host closed the connection]
yyds has joined #dri-devel
shashanks has joined #dri-devel
aravind has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
hwentlan__ is now known as hwentlan
<hwentlan>
Does anyone know who is responsible to ensure tiled display connectors are programmed in a consistent fashion, e.g.: that color management is programmed the same for all tiles? Should the DRM/KMS driver ensure that or userspace (DDX or compositor)?
<pq>
hwentlan, I would assume it's just a userspace convention since end users probably don't like it otherwise, and no other reason nor guarantee. Not that I've heard.
<zamundaaa[m]>
hwentlan: do you know what a display would do if you set one part with PQ as the TF but not the other?
<zamundaaa[m]>
If that works at least somewhat decently, definitely leave it to userspace to do it correctly
<pq>
hwentlan, what do you mean with color management, though? infoframe data?
<hwentlan>
we got an issue on some panel where color differs on the two tiles of a tiled display
<hwentlan>
the color differs because the crtc color management property (LUT or CTM, not sure) is only set on the master tile
<hwentlan>
the question is: is userspace messing up or should DRM/KMS propagate the master tile property to the other tiles
<pq>
oh that - definitely userspace, I'd say.
<hwentlan>
yeah, that would be my call as well
<hwentlan>
if userspace understands tiles it should ensure consistency
<pq>
I would not expect the kernel to even understand that the two connectors are the "same display" to begin with.
<emersion>
yeah, it's questionable why "tile" is a thing to begin with…
simondnnsn has quit [Read error: Connection reset by peer]
<emersion>
as a KSM prop i mean
<emersion>
KMS*
simondnnsn has joined #dri-devel
<pq>
...I didn't know it's even a prop
<hwentlan>
on other OSes the driver will read the tiled display info and present the two tiles of a tiled display as one single output to the OS
<zamundaaa[m]>
emersion: probably because of the lack of good EDID parsing library when it was introduced
<hwentlan>
so I could see a solution where the driver abstracts that away entirely
<hwentlan>
but the solution that was built in KMS seems to put the ownership entirely onto userspace
<pq>
IMO either the kernel abstracts nothing here, or it abstracts everything by exposing all physical tiles on the same KMS connector, so userspace does not need to care. And then under the hood use as many CRTCs as it needs, and then it can even do gen-lock.
<emersion>
intel will try to gen-lock iirc
<emersion>
but there's no need to expose a TILE prop for that
<hwentlan>
amd hw will lock the timings as well. it will do so for any (DP) output where the timings are identical
<emersion>
ideally, gen-lock would be a KMS prop…
<pq>
is it possible that tile information can come from elsewhere than EDID?
<pq>
like DT?
<emersion>
good question
<zamundaaa[m]>
What's DT?
<pq>
device tree
<shashanks>
@vsyrjala: how does I915 handle this for pipe ganging ? does the compositor/DDX driver apply the transformations, or does the driver do it for each of the CRTCs ganged ?
<pq>
some hardware description format mostly used on non-PC systems to tell Linux about devices and configurations that cannot be probed and/or vary from board to board.
<hwentlan>
the property is set from drm_edid_connector_update(). looks to be only from edid (in upstream)
<pq>
"TILE" doc says it is mainly for non-gen-locked.
<hwentlan>
hmm, I wonder if I'll have to fight DRM core, though, if I wanted to abstract the tiling away in driver
<hwentlan>
since DRM core manages tiled display info
<hwentlan>
the driver doesn't even seem to expose the tiling... that seems to come straight from edid parsing code
<hwentlan>
if that's the solution we're going for I'm not sure why TILE was ever introduced
mareko_ has joined #dri-devel
<emersion>
would be nice for KMS to have versions so that we can hide mistakes from the past
<hwentlan>
yes, please
<hwentlan>
but it also looks like there is general support for the TILE property in compositors
<hwentlan>
because it tends to just work (or so I hear, I don't have a tiled display to try myself)
mareko has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
<hwentlan>
so then the question remains... if the TILE property advertises tiled displays and userspace honors that and treats two connectors as a single monitor, should userspace ensure consistency between tiles?
<pq>
whatever end users want
<pq>
so yes, that would be a userspace bug
<hwentlan>
do compositors actually look at TILE or just at the EDID?
<emersion>
probably TILE
dri-logger has joined #dri-devel
<hwentlan>
fwiw, a quick grep only shows me what looks to be the "TILE" property in mutter code, not in sway, weston, kwin
<zamundaaa[m]>
yeah, supporting tiled displays is a very old task of mine for KWin
<pq>
weston doesn't do tiled monitors
<zamundaaa[m]>
It clashes with a bunch of KWin's abstractions and hasn't received enough attention yet
<pq>
heh, yeah, it's yet another level of abstractions, I remember seeing Mutter stuff years ago
fab has quit [Quit: fab]
<shashanks>
I guess it would be a good idea to implement a property like this only when the driver and the DDX/Compositor are in sync. It doesn't make sense to bet of half-baked implementations or do something for time being.
<shashanks>
This is not limited to just the CM props, but it needs to be implemented for each transformation
<shashanks>
Like rotation, scaling and everything else which can transform one CRTC/connector
<pq>
shashanks, what do you mean?
macslayer has joined #dri-devel
<shashanks>
I mean,if a user applies 90 rotation on one connector/CRTC, this should be duplicated on the tiled display as well, isn't it ?
<emersion>
that's up to userspace really
<pq>
yes, but it's userspace's responsibility, if the driver needs userspace two drive two connectors.
<shashanks>
that's the point, I don't think userspace can do every transformation, is there a userspace which does it already ?
<zamundaaa[m]>
Of course userspace can do every transformation
<pq>
userspace *chooses* the transformations
<shashanks>
then probably userspace will have to do a atomic_check on tiled display to see if that's even possible
<shashanks>
what if the HW has one scalar and we need two for the tiled display scaling
<zamundaaa[m]>
You need two whole crtcs to drive a tiled display
zf has joined #dri-devel
<zamundaaa[m]>
And yeah, userspace does need to do an atomic check to see if it can do hardware rotation, scaling and whatnot. There's no difference to a normal display (or rather, two normal displays)
<hwentlan>
userspace could always use GPU for the transform, if needed
<hwentlan>
e.g., in the hypothetical scenario of having two crtcs but one scaler the fallback path should be for userspace to do GPU scaling instead
<shashanks>
I am curios to see if there is a compositor who is handling it already ? Any suggestions ?
<hwentlan>
or, alternatively, to reject a config that requires scaling
<zamundaaa[m]>
shashanks: KWin scales and rotates with the GPU by default, and uses KMS for direct scanout if possible
<hwentlan>
shashank: I wonder if the "tiled discoloration bugs" should be filed as bugs with mutter in this case
<shashanks>
zamundaaa[m]: I mean for tiled displays
<pq>
hwentlan, yes.
<shashanks>
hwentlan: I am afraid that we will end up doing this for every tiled display test case in the end
<pq>
shashanks, it doesn't matter, it's the right thing to do. Do not try to "fix it" in a driver.
<hwentlan>
I think with the way the TILE property was designed ten years ago it would have to work this way
<hwentlan>
alternatively we could consider abstracting all the TILE stuff away in the driver, but I'm not sure how to do that without fighting with DRM core
<hwentlan>
would need some way to tell DRM core to ignore tiling stuff and let the driver handle it
<pq>
I agree: either expose TILE and let userspace handle everything, or handle everything in the driver. No middle-ground.
<zamundaaa[m]>
hwentlan: you'd have to take away CRTCs from userspace
<zamundaaa[m]>
That's not gonna happen, userspace just has to do things correctly
<pq>
zamundaaa[m], CRTC stealing etc. is already a thing, at least on intel
<zamundaaa[m]>
:(
Leopold has joined #dri-devel
<hwentlan>
we steal pipes all the time as well
<pq>
you just fail to enable a CRTC that you thought was still unused
<hwentlan>
we do pipe split when it makes sense (for power, or because we need another pipe for a high pixel clock)
<pq>
...once all CRTCs are actually used
<hwentlan>
and then reject atomic commits if we can't support the config
<hwentlan>
so all crtcs still look available, but you'll fail at atomic config
<hwentlan>
Manasi had a presentation about i915 pipe splitting for high-pixel-clock timings at XDC a few years back
<shashanks>
IIRC I915 applies the transformations on ganged-pipes in the driver, i think that's the stealing CRTC thing
<hwentlan>
amdgpu also applies transformations on "ganged pipes" in the driver, but only for ganged pipes the driver controls
<zamundaaa[m]>
we really need more feedback from atomic tests if that's the case. KWin will kind of handle such a situation, but not that well. EINVAL is not very expressive after all
<hwentlan>
the tiled display "ganging" isn't controlled by the driver
<shashanks>
hwentlan: what do you mean by that ?
<hwentlan>
we do need more info from atomic tests... but how to do that sensibly is a hard part
<hwentlan>
the AMD display driver will sometimes decide to use two pipes to drive one output
<hwentlan>
that output will be a single connector
<pq>
zamundaaa[m], what could you do if you knew, though?
<hwentlan>
but in the background we'll use two (or more) pipes to drive it
<hwentlan>
in this case the driver will ensure those pipes are programmed consistently
<hwentlan>
for tiled display we have two outputs
<hwentlan>
for the driver it looks like two independent outputs as it has no concept of tiled displays
<shashanks>
hwentlan: I understand that part of ganging, but why do you say tiled displays are not controlled by driver, what is different here ?
<hwentlan>
userspace controls the tiled displays and treats them as a single one
Leopold has quit [Remote host closed the connection]
<zamundaaa[m]>
pq: I'd be able to just remove a crtc without testing the world beforehand
<pq>
zamundaaa[m], how about when lighting up a new output, start with the simplest possible configuration?
<zamundaaa[m]>
In the worst case, KWin can take up to a few seconds searching for connector<->crtc connections. And that's with assuming it can use all the crtcs
<pq>
...seconds?
yyds has quit [Remote host closed the connection]
<shashanks>
hwentlan: Ok, I guess I had a mixed-up understanding on tiled display vs ganged-displays and I was mostly using that interchangeably.
<zamundaaa[m]>
Yes, seconds. I haven't encountered that in the wild yet, but for some of these tests, we have to allocate buffers
<hwentlan>
shashanks: the difference is that in the driver-controlled case the driver sees one connector and the driver reports one display to userspace. in the userspace-controlled case (the tiled display case) the driver reports two separate displays and userspace enables two separate connectors. the driver isn't aware currently that the two connectors are supposed to be the same
<zamundaaa[m]>
With more feedback we'd also know whether or not we're crtc-count restricted or bandwidth restricted
<zamundaaa[m]>
In the latter case, reducing the mode resolution or refresh rate could help, in the former, buffer allocations + atomic tests for these different modes would just be useless
<hwentlan>
Leo (not sure what his nick is) has been battling with long atomic checks in libliftoff as well. seems similar to the issues you're having in kwin
Leopold_ has joined #dri-devel
<shashanks>
hwentlan: yep, in this case it makes sense that the userspace handles mimicking of the transformations for tiled-displays (as driver is unaware if it), whereas driver does it for ganged-displays
<hwentlan>
lileo, ^^
<hwentlan>
shashanks, agreed
<hwentlan>
and we could consider pushing tiled display handling into the driver so it's treated like other ganged-display scenarios. but that would be a fair bit of work
<zamundaaa[m]>
Yeah. With modesets, users don't mind if it takes a little bit longer, but the number of tests you could do are also astronomical
<hwentlan>
exactly
<hwentlan>
the question I have is how to reduce the combinatorial explosion
<hwentlan>
maybe what you suggest, report the reason for atomic rejection
<zamundaaa[m]>
I think it was sima that had a proposal for "out properties" for atomic tests
<hwentlan>
but it can be hard to enumerate all reasons in a sensible manner
<hwentlan>
was there ever a write-up for it? i'd be curious to have a look if you have a link or anything
<zamundaaa[m]>
Just bandwidth vs crtc / used resources vs any other error would help a ton already though
<zamundaaa[m]>
hwentlan: Let me check, it was a while back
<hwentlan>
agreed
<hwentlan>
another set of rejects might be a conflict between two (or more) properties, but it's hard to communicate that, or to identify that in the driver
<hwentlan>
but we know whether something fails because of link bandwidth, or soc bandwidth, or missing resource (e.g., a crtc is already taken behind the scenes)
yyds has joined #dri-devel
fab has joined #dri-devel
dri-logg1r has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
dri-logger has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
mareko_ has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<zamundaaa[m]>
hwentlan: it's in the scrollback, search for "what do you think of output properties in atomic ioctl?" on January 11th
<zamundaaa[m]>
sima: do you have a more concrete proposal written up anywhere yet?
mareko has joined #dri-devel
<zamundaaa[m]>
It is hard when you have a whole compositor + effects ecosystem that assumes one logical output == one render output
<zamundaaa[m]>
We've slowly been moving away from that, for other reasons too, but it's not that simple. Or at least not fast to do
hansg has quit [Quit: Leaving]
<zamundaaa[m]>
That describes about 80% of the problems we're dealing with in the graphics stack :D
<hwentlan>
I'm not sure what you mean with one logical output == one render output?
yyds has quit [Remote host closed the connection]
<zamundaaa[m]>
with "logical output" I mean user facing. So what a window will maximize or fullscreen to generally
<zamundaaa[m]>
With tiled displays, we may need to render to two viewports with two separate buffers
<hwentlan>
you could still render to a single buffer and then set the viewport on the drm_plane for each output as needed
<hwentlan>
but I wonder if there'd be value nowadays to abstract all the tiled display stuff away in the driver
<hwentlan>
if we did that then it would just work on any compositor
<zamundaaa[m]>
We have no guarantees that this scaling will work on all hardware
<zamundaaa[m]>
And I have no intentions of dealing with the fallout of that ever not working
<hwentlan>
right
<lileo>
it sounds to me that it's up to the hw/driver to figure out how to make a tiled display work no? It doesn't quite click with me why compositors should have to figure out how to make tiling work for a specific vendor
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
dri-logg1r has quit [Ping timeout: 480 seconds]
mareko has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<lileo>
I just read over the scrollback, sorry if I missed something :D Does the compositor's combinatorial explosion still happen if drivers deal with setting up the resources for a tiled display?
<daniels>
yeah, we have that combinatorial problem for non-tiled displays because CRTCs != CRTCs; sometimes one CRTC can do a particualr mode which another cannot because they don't have the same clock sources
<daniels>
you also have it for trying to use planes
<daniels>
so atomic_check() cannot take a measurable amount of time without breaking userspace
ity has quit [Quit: WeeChat 4.1.2]
<daniels>
and yeah, drivers can't fully encapsulate TILE without shattering the plane/CRTC/connector model offered to userspace; iirc when it first came around that some of the tiled displays had larger dimensions than the GPUs they were attached to could render to, so userspace wouldn't actually be able to use it if you were accepting a single plane for all
jsa has quit [Read error: Connection reset by peer]
<hwentlan>
I think DRM/KMS was originally designed to expose HW resources as directly as possible to userspace. Hence, let userspace deal with tiled display. It was thought more beneficial for userspace to have direct controls over crtcs and connectors, at the expense of dealing with things like tiled display. In the last few years that has changed a bit, partly due to complex resource handling in drivers to deal with large timing modes.
<hwentlan>
The other thing that has changed is that each Wayland compositor has to handle DRM/KMS programming itself. So now tiled display would have to be implemented in each compositor, instead of being able to abstract it in a DDX.
<daniels>
so exposing it to userspace and making userspace configure it accordingly was the pragmatic compromise, and yeah, Weston/wlroots/KWin should support that
<daniels>
hwentlan: virtualising CRTCs/connectors/planes does solve a bunch of problems, but then KMS has to be the one translating userspace's wishes into concrete hardware configuration, which was seen to be unnecessary complexity in the kernel
<daniels>
of course, this was in the days before certain vendors had billions of LoC in their drivers :P
<hwentlan>
ha, I guess I deserve some of that blame
<lileo>
ah so similar problems with setting up CRTCs as with setting up planes. I'm well aware amdgpu's atomic_check does *not* help in this regard :)
<hwentlan>
it makes a lot of sense that a lot of the drivers for simpler HW shouldn't / wouldn't want to deal with those complexities, though
<shashanks>
I guess if a driver is already dealing with it in case of a ganged-pipe case, it would make sense to deal with it in the tiled case as well.
<daniels>
it also more or less only works for BCM
<daniels>
for hardware which isn't as flexible as that, when a compositor says 'here are my 8 surfaces I'd like to display and all their parameters', what do you do when you have 4 planes?
greenjustin has joined #dri-devel
<daniels>
saying 'no' and letting userspace brute-force less and less of it is exactly where we are today
<hwentlan>
what's BCM?
<daniels>
saying 'no, but I can take these 4 if you take the other 4' is exactly the libliftoff/HWComposer API, and that is ... somewhat complex
<daniels>
hwentlan: Broadcom, as in VC4/VC5 in the RPi
<daniels>
it doesn't have planes in CRTCs as traditional display controllers do, but instead has a blazingly fast programmable 2D composition engine
<hwentlan>
the "somewhat complex" is something lileo has been wracking his brain about lately :D
<lileo>
:')
<daniels>
so it can do arbitrarily complex composition in a display list; the only limitation is how many pixels it can process within the frame time
<hwentlan>
right
<hwentlan>
that engine sounds pretty nifty
<daniels>
it's super neat, yeah
<daniels>
(if your next question is 'how does this get expressed to userspace?', the answer is 'we sat down with anholt and decided 10 planes was a good number to expose to userspace')
<daniels>
and it just pretends that it has the classic fixed-plane model
<daniels>
anyway, maybe I'm just getting conservative in my old age, but given the choice between making amdgpu atomic_check not be slow, and pushing the entire HWC API into uAPI, I know which I'd choose
<lileo>
The former (atomic_check slow) would solve a lot of problems it seems
<hwentlan>
the first one is definitely a much easier design
<lileo>
It helps with the liftoff efforts too
<hwentlan>
I feel the latter would also be much more than pushing the entire HWC API into uAPI... I bet DRM/KMS does a lot more than HWC at this point
Duke`` has quit [Ping timeout: 480 seconds]
<daniels>
the atomic_check() doc doesn't say 'this needs to be really really really fast', but it does not
<daniels>
I'd happily Ab that doc patch ;)
<hwentlan>
really, really fast is currently a problem for the AMD bits... but we're looking at how we can improve it :)
<daniels>
:)
<hwentlan>
fwiw, until now it's not been a problem that's bubbled up to us much, other than for the SteamDeck. I feel most compositors get away with what we do, though maybe compositor devs are just very patient folk.
Duke`` has joined #dri-devel
<zamundaaa[m]>
From the last conversation about that topic I didn't get the impression that was a this-decade thing
<zamundaaa[m]>
Would be nice to at least start moving towards it though
aravind has quit [Ping timeout: 480 seconds]
<hwentlan>
The problem has become more acute for us since we started looking at multi-plane enablement in your average linux desktop compositor. lileo's been looking at the libliftoff / wlroots / sway stack. Once you need to check for overlay plane support your combinations go way up. That's a real problem if our check is taking a couple hundred us.
gouchi has joined #dri-devel
gouchi has quit []
kts has quit [Quit: Leaving]
mareko has joined #dri-devel
dri-logger has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
DodoGTA has quit [Read error: No route to host]
DodoGTA has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
kxkamil has quit []
kxkamil has joined #dri-devel
krushia has joined #dri-devel
omniwrench[m] has left #dri-devel [#dri-devel]
callen92 has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
tzimmermann has quit [Quit: Leaving]
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
<Company>
from the "fun with Vulkan renderers" department, today: 23.3's Intel Vulkan renderer doesn't support the modifier that its GL renderer picks by default for AR24
<Company>
0x0100000000000008
<Company>
24.0 does
dwlsalmeida has joined #dri-devel
log123 has joined #dri-devel
paulk-bis has quit []
paulk has joined #dri-devel
<log123>
Hello, not sure if this is the right place to ask but i'm trying to get NVK working on my setup, its got dual graphics and the IGP is detected by RADV fine but the dGPU RTX 2060 Max-Q [10de:1f12] seems to not get picked up for some reason, the OpenGL driver works as verified by switching with DRI_PRIME, I'm on kernel 6.7 running Mesa Git, but the kernel/mesa versions don't see to matter, i've tried 6.8 RC-2 and Mesa Stable also
<log123>
by dual graphics i should probably specify its an optimus non MUXed setup
Leopold_ has joined #dri-devel
callen92 has quit []
log123 has quit [Remote host closed the connection]
fab has quit [Read error: No route to host]
<daniels>
Company: that’s why you have to check what all consumers support and pass that acceptable list to the producer when you allocate
fab has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<Company>
sure, technically webkit needs to send webkit its Mesa config so that it can check with Mesa to get a matching config to Mesa, so that the webkit can then send the matching Mesa config back to webkit so it can ensure Mesa can display the buffer
lynxeye has quit [Quit: Leaving.]
<Company>
or we just fallback and let the users complain to Mesa or Mesa that their Mesa config doesn't match Mesa's config and then the Mesa devs can make sure that Mesa can to the same thing as Mesa
<Company>
the Vulkan switch will be fun at least
<Company>
I do think that drivers should support the same dmabuf formats for Vulkan and EGL - and specifically pick a default format that both support, just to make issues like this not appear
<Company>
but I also think that it's so far not been an issue because there's not enough usage of Vulkan that it's worth not shipping a new modifier in EGL just because the Vulkan driver isn't ready
<emersion>
Company, there will always be situations where EGL doesn't match Vulkan in terms of format support
<emersion>
it's two separate codebases really
<emersion>
the classic one is radeon adding a format or modifier before RADV gets the chance
frieder has quit [Remote host closed the connection]
<emersion>
also maybe a format is really difficult to support in GL, but easier in Vulkan
<emersion>
or the other way around
<emersion>
depending on its usage
<Company>
sure, but it's also a bad idea to just assume everybody will surely do proper negotiation and just choose a default format at them that you know is unsupported by either of the two
<emersion>
it's a good way to ensure everybody is doing the right thing
<emersion>
the bug isn't in mesa for sure
<zamundaaa[m]>
It's a much worse idea to not do format modifier negotiation at all. The OpenGL component might be using an entirely different driver (like the proprietary AMD OpenGL one), or even a different GPU
<emersion>
or maybe it's coming from flatpak runtime or w/e
<Company>
considering that even Mesa can't do proper negotiation yet, I'll just wait for that to happen
<emersion>
what do you mean by mesa can't do proper negociation?
<emersion>
s/c/t/
<zamundaaa[m]>
Company: format negotiation is up to the clients allocating buffers, not Mesa
<Company>
Mesa does formats + modifiers somewhat decently (though GL lacks information about features of the formats, ie can you call glReadPixels() on them and Vulkan lacks the ability to enumerate by format and you have to guess the VkFormat for it)
<emersion>
mesa WSI does proper negotiation
<Company>
but there's also no way to communicate stride limitations for linear buffers and whatnot
<emersion>
that's not a mesa issue
<Company>
sure
<emersion>
it's an API issue for GL/Vulkan
<emersion>
and this doesn't prevent mesa from doing proper format+modifier negotiation
<Company>
but that's the argument you hear everywhere
<emersion>
format+modifier are orthogonal to stride alignment
<Company>
they cause the same problem - a buffer that can't be imported
<emersion>
sure
<Company>
things are just a whole lot easier for the existing situation if Vulkan and GL at least support the format/modifier combo they use by default
<emersion>
i don't see how that relates to your comment about stride
<emersion>
if there is proper format+modifier negotiation, then this isn't an issue at all
sima has quit [Ping timeout: 480 seconds]
<Company>
sure\
<Company>
if everybody wrote perfect code, it wouldn't be an issue
<emersion>
there will always be bugs
<emersion>
bugs can be fixed, hopefully
<Company>
this is less "bugs" and more "missing features"
flom84 has joined #dri-devel
flom84 has quit [Remote host closed the connection]
<emersion>
you make it sound like format negotiation is optional
<emersion>
it's not :P
<Company>
it seems to be in a lot of places
konstantin_ is now known as konstantin
<Company>
lots of people implement it once they need it, but assume things just work before that
mbrost has joined #dri-devel
<emersion>
there are many ways to write bugs when you haven't read the docs (or when they don't exist yet)
<Company>
or when you want to get done and not have perfect code
<Company>
and just something that works
<emersion>
still, bugs and not missing features
<Company>
whatever you want to call it
simon-perretta-img has quit [Ping timeout: 480 seconds]
yang is now known as Guest994
simon-perretta-img has joined #dri-devel
Guest994 is now known as yang
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<airlied>
hwentlan, daniels : yeah the tiled display stuff was pre atomic, the first implementation was all in kernel, but it broke a lot of assumptions
<airlied>
also userspace wants EDID
<airlied>
how do you expose tiled EDIDs if you have one connector?
<emersion>
toss a coin :)
fab has quit [Quit: fab]
<emersion>
but yeah, seems lik user-space can do a better job
dok has joined #dri-devel
fab has joined #dri-devel
ngcortes has joined #dri-devel
<airlied>
though i cant remember if tbe main tile exposes a super mode in edis
<airlied>
edid, it probably did
<mairacanal>
i'm using a separated shmfs mountpoint to create my shmem-backed objects, but i'm not quite sure what would be the correct approach: (1) create a custom drm_gem_shmem_create() for the driver and basically copy and paste drm_gem_shmem_create() but using shmem_file_setup_with_mnt() or (2) add a mountpoint parameter to drm_gem_object_init() and create
<mairacanal>
a drm_gem_shmem_create_with_mnt(). i don't know if any other shmem driver has the interest to use huge pages...
<dok>
hi there, I am having issue with some shaders when using musl-libc and with radeonsi_dri, I am experiencing segmentation fault caused by not enough stack allocated for threads
<airlied>
mairacanal: probably go with the latter and see how messy it looks
Duke`` has quit []
Duke`` has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
ity has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
fab is now known as Guest998
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
simon-perretta-img has joined #dri-devel
mattrope has quit [Remote host closed the connection]
Guest998 has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
fab_ has joined #dri-devel
fab_ is now known as Guest1000
Guest1000 has quit []
konstantin_ has joined #dri-devel
konstantin is now known as Guest1001
konstantin_ is now known as konstantin
simon-perretta-img has joined #dri-devel
Guest1001 has quit [Ping timeout: 480 seconds]
jtatz[m] has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
rasterman has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
mclasen has joined #dri-devel
tanty has quit [Quit: Ciao!]
krushia has quit [Quit: Konversation terminated!]
Surkow|laptop has quit []
Surkow|laptop has joined #dri-devel
fab has quit [Quit: fab]
tanty has joined #dri-devel
tanty has quit []
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Leopold_ has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
tanty has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
fab has joined #dri-devel
simondnnsn has joined #dri-devel
Leopold_ has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
Leopold_ has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
Leopold_ has joined #dri-devel
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
mclasen has quit []
Leopold_ has quit [Remote host closed the connection]
<Venemo>
CounterPillow: the discussion was about the old nv mesh shaders extension, which currently nobody supports. the ext mesh shaders will definitely stay
<Venemo>
sorry for the late reply
Leopold_ has joined #dri-devel
mbrost has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
ity has quit [Remote host closed the connection]
ity has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<daniels>
emersion: I feel like if two of the four compositor developers are saying that compositors can do a better job, and one of the other two has done it for years already, then that's consensus :P
<daniels>
Company: I take the snark about Mesa or Mesa and Mesa's config to Mesa's config so Mesa can Mesa Mesa, but if you've ever run something in a container, or tried to bisect anything, then Mesa's semantics are not Mesa's semantics, unless you write those semantics exactly once and entomb them as ABI forever
<daniels>
Company: equally, embedded web views mean that WebKit is not necessarily WebKit
<daniels>
Company: if you're ever doing anything more complex, like interacting with codec APIs or window systems, you need to do modifier negotiation anyway
<daniels>
Company: and you can't say you were unaware because the canonical modifier doc literally spells out at great length that you must enumerate the acceptable downstream subset and pass those to the allocator; if we were just relying on wishful thinking and vibes then we wouldn't have bothered surfacing lists of explicit modifiers, but we'd have stuck with implicit 'errr yeah dunno really but let's hope the other side picks the same'
Haaninjo has quit [Quit: Ex-Chat]
mbrost_ has joined #dri-devel
apinheiro has quit [Quit: Leaving]
mbrost has quit [Ping timeout: 480 seconds]
danylo has quit [Ping timeout: 480 seconds]
<Company>
daniels: my issue here was mostly integration between apps using GTK and other GL/dmabuf-using libraries - and the concrete case here was Webkit which sends dmabufs from its web process to the ui process and the web process uses EGL while someone decided to try GTK's Vulkan renderer
<Company>
and of course, in an ideal world we'd all negotiate things perfectly, but I fear some of those applications won't even if I provide them with all the necessary code to do it
<Company>
I will certainly make sure that GtkGLArea picks a dmabuf format/modifier that the Vulkan renderer accepts, when the Vulkan renderer is in use
<Company>
but there's also things like GStreamer with its GL pipelines that can be ade to spit out dmabufs
<Company>
and GTK might want to consume that, too
<Company>
of course, this is ultimately going to go in the other direction too - where Vulkan libraries produce dmabufs for GTK's GL renderer to consume
<Company>
and I'm sure the same thing is gonna happen in Qt and wherever else people smash libraries together
<daniels>
I'd love to tell you there's an easy way out, but there's not
<daniels>
if you're exchanging dmabufs, then you need to be exchanging acceptable format/modifier/etc sets before you do so
<daniels>
if that wasn't the case, we wouldn't have bothered typing up all the EGL/Vulkan/Wayland/KMS/... extensions
<daniels>
but it is, so we did, and if you want the benefits of just firing around nice zerocopy handles then you need to be doing the same
<Company>
I get that
<daniels>
if people get that wrong, then that sucks for anyone using those things, but there isn't a magic lever we can pull to make it work
<Company>
but I also get that people write code that works well enough and then they ship it
<Company>
and then it doesn't work for somebody else
<Sachiel>
people also write code that doesn't work at all, and still ship it
<Sachiel>
can't fix what can't be fixed
<daniels>
tldr: software
<zamundaaa[m]>
It could be useful to have a debug env for Mesa to pick a single random modifier and not support anything else
<zamundaaa[m]>
So that you can at least somewhat consistently test this kind of scenario
<Company>
and then they're gonna blame someone for that, and I can tell you it's not always the one who doesn't conform to the spec
<Company>
zamundaaa[m]: WebKit already has an env var to force a format/modifier combo so that seems like a common thing
<Company>
zamundaaa[m]: but are you talking about Mesa or Mesa here? ;)
krumelmonster has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
About Mesa, obviously. Meaning, support the env var with all drivers
<Company>
like, the issue here is the EGL vs the Vulkan driver in the same process
<daniels>
Company: they can blame who they want, but the fix is the same: do the difficult thing people tried to avoid doing
<Company>
so you'd need to have 2 env vars
<zamundaaa[m]>
I really meant "random" as in "randomly chosen at init time"
<daniels>
(also, 'select the same thing for EGL and Vulkan' is not really a thing, given that Vulkan has fine-grained usage flags forming immutable allocations, and EGL/GL/GLES have ~no usage flags forming very mutable allocations)
<Company>
zamundaaa[m]: I think you want "make sure Vulkan and EGL both can do it" as well as "make sure Vulkan and EGL are different"
<Company>
the first one to make your code actually work in the ideal case
<Company>
and the second so once that works, you can ensure that negotiation also works
<Company>
daniels: I'm pretty sure in this case that wasn't the problem though, and it was just a lack of the newest feature getting into the Vulkan driver in time
<Company>
daniels: which is something that Mesa could have prioritized
<daniels>
Mesa doesn't prioritise making two wildly different APIs pretend to be the same in order to support people breaking the entire premise of buffer exchange
<daniels>
it's nice to have for sure, but it's fundamentally not a problem which can be solved
<daniels>
and there's plenty enough hardware around where you'll throw performance on the floor by trying