airlied has quit [Remote host closed the connection]
airlied has joined #dri-devel
Daaanct12 has joined #dri-devel
yuq825 has joined #dri-devel
<kode54>
cheako: spilling is where referenced data exceeds the size of the register file, and it spills over into writing temporaries to scratch space and rereading things from memory
<kode54>
My cup runeth over
<kode54>
Literally, running out of registers and having to use ram for temporary data
Danct12 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
Daaanct12 is now known as Danct12
kts has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
jmondi has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mbrost has joined #dri-devel
greaser|q has quit []
GreaseMonkey has joined #dri-devel
sudeepd has joined #dri-devel
mbrost_ has joined #dri-devel
sudeepd_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
sudeepd_ has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
sgruszka has joined #dri-devel
sudeepd_ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
sudeepd_ has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
fab has quit [Quit: fab]
Duke`` has joined #dri-devel
tzimmermann has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
rasterman has joined #dri-devel
simon-perretta-img has quit []
simon-perretta-img has joined #dri-devel
jmondi has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
frieder has joined #dri-devel
fab has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
rasterman has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
mvchtz has joined #dri-devel
simon-perretta-img has quit []
simon-perretta-img has joined #dri-devel
glennk has joined #dri-devel
rgallaispou has joined #dri-devel
elongbug_ has joined #dri-devel
elongbug has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
tursulin has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
donaldrobson has joined #dri-devel
<pq>
wv, what you are asking for is explicitly forbidden in DRM KMS. The rationale is to have a single process noted as "the DRM master" be in control of all the display on a device, so that random programs cannot mess things up. However, DRM leasing is a feature that allows co-operating processes to lease parts of KMS to another process, but that it mostly meant for whole-monitor hand-off on multi-head cards.
<wv>
pq, what I want to do is explicitely telling my application (cog/wpewebkit) to be sitting at the back layer, and playing video (kmssink) on the top layer. This is the sole usecase I have. I've been playing with wayland, but I don't get things right like that..
<wv>
and in my head, it looks so easy :-p
<pq>
wv, if you don't use any service (e.g. a Wayland compositor) beneath both application, you get to either hack out security checks in the kernel or modify both apps so that one creates a DRM lease and hands it over to the other to use. Neither I'm not sure how well it works, mind, for both hardware and driver reasons.
KitsuWhooa has joined #dri-devel
<wv>
per default, video is played through the GPU compositor, but I'm lacking performance there. So I just want to keep the video on the hardware plane. Don't want to do fancy stuff anyway
<wv>
I've been plaing aroungd with drm-lease manager, which purpose would be as you describe
<wv>
handing out leases
<wv>
but cog fails to start with a lease for some authenticate reason. It gets a lease, detects properties and all, but fails to get through (wl_display fails to authenticate)
<pq>
wv, the hardware reason why this is a bad idea might even be relevant to you: a single output is driven by a single CRTC, which determines the timings (update times) for the output. If you have two processes independently submitting updates to the same CRTC, they will randomly block or even fail each other, causing no-one to get a steady framerate.
<wv>
pq, I have 2 hardware planes available
<pq>
using two hardware planes really is fancy stuff :-)
<wv>
in the old days, there were just to fb's available (/dev/fb0 and /dev/fb1)
<pq>
yes, but they both feed to the same CRTC if you want both to show on the same monitor.
<pq>
the legacy fb API was full of full frame copies and no defined timings
<pq>
full frame copies on the CPU, even
<pinchartl>
wv: wayland really seems the way to go for this, picking a compositor that supports KMS planes
<pinchartl>
I got asked the very same question yesterday
<pinchartl>
it's a common one
xroumegue has joined #dri-devel
<wv>
pinchartl, what compositor supports kms planes? you mean one can specify which application goes to what plane then?
<wv>
and defining the hardware plane?
<pq>
(disclaimer: I'm a Weston developer); Weston is probably one of the best compositors to get app contents straight to KMS planes without compositing on GPU when at all possible.
<pq>
OTOH, if you have two completely independent apps and you want to make them look like one coherent app, with Weston that will need some extra development work to make happen.
sarahwalker has joined #dri-devel
<pq>
that work would be window placement in the compositor
Haaninjo has joined #dri-devel
<pq>
wv, you don't explicitly define window-plane associations, because that can conflict with your window placement and z-order. Instead, the compositor automatically uses KMS planes for the windows.
<wv>
well, usecase is really rather simple. I have cog/wpewebkit, which per default renders video in a proper glimagesink, so using gpu. But mine is to slow to handle all that. So wpewebkit also has a holepunch approach, where you delegate the video to a custom sink. This sink would be waylandsink (or kmssink) on a proper overlay plane
<wv>
and that's all I need
<wv>
no other apps, or other windows, or minimize/maximize stuff
<pq>
Two processes working together on the same screen is definitely not simple.
<daniels>
pq: s/probably one of // :P
<pq>
at least, if you care about smooth performance and coherent appearance.
<daniels>
wv: and yeah, hardware doesn't let allow you to control the planes independently anymore, so neither does the KMS API. you need one coherent process which can handle the whole thing for you. generally people use lightweight Wayland compositors (such as Weston) which try very hard to use hardware planes where possible. this lets the apps focus on being apps and not a presentation layer
<pq>
wv, that wpewebkit punch-through - sounds like you *could* do all KMS programming in the same process, can you?
anholt has joined #dri-devel
<pq>
even if you use Wayland, it would be best to have both wpewebkit and the custom sink use the same Wayland connection, whinh means they would need to be in the same process, so that they could use sub-surfaces, and you don't have to hack a Wayland cmopositor for window placement.
<wv>
pq, I think UI and Webprocess are different processes
<pq>
wv, are you sure that if you were to run webkit on Wayland, it still would not use Wayland sub-surfaces for the video on its own?
<wv>
yes, as it renders to a glappsink => it uses the GPU for compositing
<wv>
but thing is, I'm trying this out. I put cog fullscreen in wayland
<pq>
if webkit used sub-surfaces, you don't need a custom sink at all, and the Wayland compositor would automatically put the video on its own KMS plane and the rest of webkit on another KMS plane.
<wv>
and then I just do a gst-launch videotestsrc ! waylandsink, but this is not visible at all
<wv>
if I don't put cog fullscreen, it is working though
pochu has joined #dri-devel
<pq>
you are starting a new process. Don't do that.
camus has quit []
<pq>
The absolutely best design would be to have webkit use a Wayland sub-surface for the video. The you'd have a single Wayland client which makes the whole app coherent, and the compositor would automatically all the KMS capapbilities for the best performance.
<daniels>
yeah, you need a compositor here, you can't have separate processes both directly driving different parts of the display
<pq>
*automatically use all
i509vcb has quit [Quit: Connection closed for inactivity]
<pq>
We've talked about two different designs: a) wpewebkit and the custom sink as separate processes, and b) wpewebkit using a Wayland sub-surface for the video. Both designs require a Wayland compositor in practise.
donaldrobson has quit [Ping timeout: 480 seconds]
<pq>
option a) is strictly inferior, because you would need to patch the compositor to make this arrangement look like a single app, instead of two separate apps.
donaldrobson has joined #dri-devel
<pq>
Both designs allow using two KMS planes the way you want.
vliaskov has joined #dri-devel
<pq>
Well, I'm not quite sure of option a) if the video must be an underlay instead of overlay, but b) does.
camus has joined #dri-devel
<wv>
well, video should be an overlay. I'm on rgb565 planes (reducing bandwith), so no alpha channel
<pq>
ok
<pq>
but that also means it cannot be punch-through hole
<wv>
well, punch through... What's in a name. As long as the area is foreseen to put the video. whether it's beneath or above, I don't care. Agree, I'll not be able to put content on top of the video
<pq>
you need alpha to have a hole (or colorkey)
<pq>
right, that's important: not needing to put anything on top of the video
<pq>
so you don't need a hole, you will be fine with a simply overlay
<wv>
option b looks like the better option, and a nice addition to webkit anyway. I'm only afraid that implementation wise, this goes over my head
<wv>
so you don't need a hole, you will be fine with a simply overlay => that's correct
<pq>
I would be surprised to learn if webkit didn't support sub-surfaces yet.
<pq>
if it doesn't, I'm sure many would want it to, just like you
hansg has joined #dri-devel
<pq>
you said you can get video already to a custom sink and out of webkit, so to me that would be like the hardest part already done
<pq>
then again, I'm familiar with Wayland and have no idea what cog/wpewebkit looks like inside. :-)
MrCooper has joined #dri-devel
<wv>
Well, I'm reading through the code and options a bit right now. And it appears that maybe I'll need some other options
<wv>
USE_WPE_VIDEO_PLANE_DISPLAY_DMABUF and USE_GSTREAMER_GL look promising
<pq>
video plane dmabuf sounds very interesting, GL I
<pq>
I'm not sure
<pq>
does it refer to decoding with GL or display with GL?
<pq>
while "display with GL" might end up on a KMS overlay plane too, it may also imply a copy done on the GPU, just in the app side.
<wv>
display with GL I think, but copy done on the GPU. Dits som dot examination yesterday, and there's a glupload moving textures from decoder to gpu
MrCooper has quit [Read error: No route to host]
MrCooper has joined #dri-devel
kts has joined #dri-devel
<pq>
wv, I was thinking of a rendering pass because EGL or GL does not have a way to send a texture to the window system as-is, so glupload might even be a second copy in the worst case, or zero-copy if dmabuf import succeeds.
<pq>
if you have a GL texture, then I see no other way to push that to the window system than doing a GPU rendering pass (a copy).
MrCooper_ has joined #dri-devel
<wv>
I'm not completely following. What comes out the decoder is not a gl texture. It only becomes a gl texture when passing the gpu. So if I now disable this GSTREAMER_GL, and enalble this WPE_VIDEO_PLANE_DISPLAY_DMABUFF, I hope it'll be able to just pass from decoder to plane, without passing gpu
MrCooper has quit [Ping timeout: 480 seconds]
<pq>
yes
<pq>
I was simply explaining the "display with GL" path, not that
<pq>
it sounded to me like you were thinking about enabling USE_GSTREAMER_GL rather than disabling it, hence my confusion.
MrCooper_ is now known as MrCooper
elongbug_ has quit [Remote host closed the connection]
elongbug_ has joined #dri-devel
<wv>
pq, no, USE_GSTREAMER_GL was enabled, and the other one disabled, so...
<Company>
FINISHME: support YUV colorspace with DRM format modifiers
<Company>
sounds like Vulkan is indeed the future
sgruszka has joined #dri-devel
<tnt>
:)
clamps has quit []
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
<Company>
my code works neither on AMD nor on Intel, and now I don't know if my code is broken or it's too futuristic because I get those warnings...
<Company>
but I guess there aren't that many people importing YUV dmabufs on Vulkan yet
eerii has quit [Remote host closed the connection]
eerii has joined #dri-devel
eerii has left #dri-devel [#dri-devel]
Haaninjo has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
ficoPRO10 has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #dri-devel
Haaninjo has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
<anholt>
robclark: prepare-artifacts.sh is the script to change
<robclark>
anholt: looking at manpage, --strip-debug looks plausible
anholt has quit [Ping timeout: 480 seconds]
<Lynne>
Company: an issue is that you need two different dmabuf formats on intel and amd
<Lynne>
since intel demands that both planes are close in terms of memory
<Company>
and amd demands that things are far apart, so stride can be a multiple of 256, I know
<Company>
so far I just get a red image on AMD (despite no validation errors), so no clue who's at fault there
<Company>
and that fixme on Intel
<Company>
and I think AMD doesn't do disjoint dmabufs either, though I stopped caring about that when I figured out my webcam doesn't give me disjoint buffers
<dj-death>
is that importing a dmabuf for 3d or video?
Duke`` has joined #dri-devel
<Company>
dj-death: for video - I'm trying to get my webcam's NV12 dmabuf into Vulkan
<emersion>
you can look at wlroots maybe
<Company>
well, I get it into Vulkan - I'm trying to get it rendered
<dj-death>
yeah but you're not using vulkan video?
<Company>
no
<Company>
not Vulkan video
<emersion>
we're importing client DMA-BUFs and then rendering them via the YUV vk ext
<dj-death>
so I don't think there is any restriction for disjoint stuff in terms of placement
<Company>
actually, on Intel I'm using YUYV
<Company>
because that laptop doesn't speak NV12
<Company>
*that laptop's camera
<dj-death>
I guess you can bind the same VkDeviceMemory with a different offset
<Company>
I should try the NV12 one there
<Company>
yeah, the NV12 dmabuf is just one fd
<Company>
with offsets
anholt has joined #dri-devel
kts has joined #dri-devel
kzd has joined #dri-devel
kts has quit []
MrCooper has quit [Read error: No route to host]
vliaskov_ has joined #dri-devel
ficoPRO10 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
kzd has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
yuq825 has quit [Remote host closed the connection]
diego1 has quit []
AnuthaDev has quit []
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<Company>
ha, progress - my NV12 cam works on Intel
<Company>
well, the anv works, and the cam does - my code seems not to
frieder has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat_ has quit [Remote host closed the connection]
<anholt>
in particular, UnexpectedPass has become UnexpectedImprovement(Pass) so that we can also express Fail->Skip as UnexpectedImprovement(Skip)
vliaskov_ has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
sudeepd_ has joined #dri-devel
vliaskov has joined #dri-devel
<kisak>
Thanks to everyhody participating and attending XDC. The live stream is appreciated. I hope that everybody has safe travels on their way home.
vliaskov_ has joined #dri-devel
<eric_engestrom>
anholt: is fail->skip really an improvement?
<anholt>
eric_engestrom: yeah. otherwise you end up with junk left around in your xfails that looks like your driver sucks when you fixed it long ago. or, people try to fix things by dropping features and being surprised and asking me why it wasn't caught.
mbrost_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
<eric_engestrom>
ok
<eric_engestrom>
(not really convinced, but also I have to go)
mbrost has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
donaldrobson has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
donaldrobson has joined #dri-devel
kzd has joined #dri-devel
hansg has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
oneforall2 has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
junaid has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
djbw has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]