ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
rasterman has quit [Quit: Gettin' stinky!]
Seirdy has quit [Ping timeout: 480 seconds]
st3r4g has quit [Quit: おやすみ]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
enick_805 has left #wayland [#wayland]
DrNick has joined #wayland
leon-p has quit [Quit: leaving]
remanifest has quit []
vivekk has joined #wayland
vivek has quit [Ping timeout: 480 seconds]
boistordu has joined #wayland
DwarfSec has joined #wayland
boistordu_old has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Read error: Connection reset by peer]
co1umbarius has joined #wayland
naveenk2 has quit []
rasterman has joined #wayland
naveenk2 has joined #wayland
pnowack has joined #wayland
danvet has joined #wayland
vivekk has quit [Ping timeout: 480 seconds]
st3r4g has joined #wayland
<jadahl>
will dri-prime in mesa rely on getting tranches for secondary gpus or does that involve internal magic in mesa still?
hendursa1 has joined #wayland
gryffus has joined #wayland
hendursaga has quit [Ping timeout: 480 seconds]
gryffus has quit [Ping timeout: 480 seconds]
mjs_11 has joined #wayland
<daniels>
jadahl: -EPARSE
<jadahl>
DRI_PRIME=1 weston-simple-egl will run on nouveau, while everything else is on intel. does mesa need tranches for nouveau to make that happen with v >= 4?
<emersion>
jadahl: do you want the compositor to be able to emulate DRI_PRIME's behavior via dmabuf-hints?
<jadahl>
i want to avoid regressing
<jadahl>
so mosty asking if mesa depends on more from hints than it did pre-hints
<daniels>
well, assuming both devices support modifiers, then hints would let them negotiate something mutually satisfactory ... but also tbf so would non-hints?
<jadahl>
so sending tranches for secondary GPUs will effectively give me .. nothing of immediate value?
<daniels>
huh?
<jadahl>
i typed down basic support for v4 yesterday in mutter and just came to mind whether this effects DRI_PRIME or not since I only currently send tranches for the primary gpu
<daniels>
I'm not sure how you'd send it for the secondary anyway unless you're using that to actually do composition
<daniels>
otherwise it's irrelevant
<jadahl>
ok, I think that answers my question; I shouldn't bother with anything that isn't used for compositing
<jadahl>
if I want to allow scanout in the hybrid gpu case (scanning out nouveau buffer on the nouveau connector), I would, though, right?
flacks has quit [Quit: Quitter]
flacks has joined #wayland
mjs_11 has quit []
<emersion>
yes, with a scanout tranche
<emersion>
and no nouveau non-scanout tranche
<jadahl>
that'll "risk" resulting in a buffer intel can't composite, doesn't it?
<emersion>
yes, compositor needs to try to import on intel at dmabuf creation time
<emersion>
just to make sure a fallback is possible
gryffus has joined #wayland
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
leon-p has joined #wayland
<daniels>
^
Net147 has quit [Remote host closed the connection]
Net147 has joined #wayland
gryffus has quit [Remote host closed the connection]
gryffus_ has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
gryffus_ has quit [Remote host closed the connection]
gryffus has joined #wayland
gryffus has quit [Remote host closed the connection]
<jadahl>
a fallback as in on-demand copied to the right gpu?
<emersion>
on-demand accessed from intel
<emersion>
it doesn't necessarily need to be a copy
<jadahl>
what is the api for creating an on-demand "copy"?
<emersion>
just import the nouveau dmabuf into an intel EGL context
<emersion>
and use the texture as usual
<jadahl>
ah, "just to make sure the fallback is possible" is done by the driver you mean
<emersion>
the driver will fail the import if the dmabuf isn't accessible
<jadahl>
and the buffer allocated must be able to do so
gryffus has joined #wayland
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
<MrCooper>
emersion: one issue with that is it may migrate the BO from VRAM to system memory, which will slow things down a lot for dGPUs
<emersion>
MrCooper: the migration should only happen in the driver if it's needed…
<emersion>
the import just checks whether the migration is _possible_
<emersion>
i don't see any possible alternative here
<MrCooper>
yeah, it is needed normally though unfortunately
<MrCooper>
the import already pins the BO to system memory if needed
<emersion>
as needed as in when there's a draw command submitted which tries to access the buffer data
<emersion>
hm
<emersion>
that isn't great
<MrCooper>
nope, it happens at import time
<emersion>
rip
<emersion>
things will be slow and we can't do anything about it, then
<wlb>
wayland Merge request !42 closed (Move wayland-cursor and wayland-client documentation from implementation to header)
<emersion>
what if the compositor imports, then destroys the EGLImage immediately?
<emersion>
will that allow the buffer to be migrated back at some point?
<emersion>
or is it forever "pinned"?
<MrCooper>
the BO remains pinned as long as the importing device has a reference to it
<emersion>
ok, so if the compositor just tries, it should pin the unpin
<MrCooper>
i.e. as long as it can access the BO
<emersion>
then*
<MrCooper>
if the compositor does something which unpins, importing again later could still fail
<emersion>
eh
<emersion>
which kind of failure?
<emersion>
hm, many kinds i guess
<MrCooper>
e.g. not enough memory
<emersion>
including ENOMEM
<emersion>
yea
<emersion>
would be nice to have some kind of "please make sure the resources are reserved in case i need to use the fallback, but please don't pin the buffer"
<emersion>
… or just make the drivers smarter
<MrCooper>
it's tricky to guarantee something can work without actually doing it :)
gryffus has quit [Ping timeout: 480 seconds]
hendursa1 has quit []
hendursaga has joined #wayland
gryffus_ has quit [Remote host closed the connection]
<kennylevinsen>
Or Make GPUs better/sensible and have them agree on memory layouts and capabilities :|
gryffus has joined #wayland
<MrCooper>
emersion: BTW, the pinning to system RAM also prevents scanout with AMD dGPUs
gryffus_ has joined #wayland
<emersion>
sounds like direct scanout on dGPU will not work anytime soon
<emersion>
… on multi-dGPU
<MrCooper>
kennylevinsen: this is more about the importing GPU being able to access the buffer contents at all than about their layout
<emersion>
tbh i feel like dmabuf hints is all kinds of premature
<emersion>
maybe should stop pushing for it
<emersion>
the whole stack isn't ready for good multi-gpu support
<LaserEyess>
does any of this work on other OSes (windows, I guess)? if you have multiple GPUs on windows feeding multiple displays or devices, do things Just Werk™ in terms of minimizing copies and ensuring cross-GPU talk is minimized?
<LaserEyess>
I would imagine these cases are very niche but I do wonder if it's been "solved" before
<emersion>
from what i've heard, multi-gpu on windows works by having intel-specific code in the nvidia driver or the other way around
gryffus_ has quit [Remote host closed the connection]
gryffus has quit [Read error: No route to host]
<LaserEyess>
hm, something like that is rather unmaintainable, and also impossible for nvidia I guess
<emersion>
no idea how it works
gryffus has joined #wayland
<kennylevinsen>
Heh, that definitely sounds exactly like something proprietary closed source drivers would do - "feature works, boss is happy, moving on"
<LaserEyess>
actually I guess for windows, the only cases that you'd immediately care about is intel<->AMD (rarer) and intel<->nvidia, and AMD/nvidia drivers would just handle the AMD+AMD and nvidia+nvidia cases
<LaserEyess>
so not a huge need to design a driver agnostic system
<MrCooper>
I guess in addition to modifiers, relevant APIs also need to allow querying if BOs can be shared without moving them to different memory; if not, a separate shared BO is likely needed for transferring data between the GPUs when needed