[00:33] <RAOF> bschaefer: Yo!
[00:34] <bschaefer> RAOF, hey! Sooo questions about render nodes!
[00:34] <RAOF> Cool.
[00:34] <bschaefer> if you had a mythical machine that supported drm buf with multiple render nodes
[00:35] <bschaefer> does it matter which node you pick? From my reading they dont relate to the specific card and is there for legacy reasons only
[00:35]  * RAOF has such a machine, yes.
[00:35] <RAOF> If you've got two different GPUs you'll have two different render nodes, one per GPU.
[00:35] <bschaefer> right
[00:35] <RAOF> So it does indeed matter which render node you pick.
[00:35] <RAOF> But!
[00:35] <bschaefer> RAOF, https://dvdhrm.wordpress.com/tag/drm/
[00:36] <RAOF> Whichever node you pick, you should be able to display.
[00:36] <bschaefer> so if mir is rendering on intel
[00:36] <bschaefer> and youve an amd gpu and you told kodi to render on it
[00:36] <bschaefer> and then picked the amd render node, it wouldnt display on mir?
[00:36] <RAOF> It would.
[00:36] <RAOF> That's what dma-buf is for!
[00:36] <RAOF> Cross GPU sharing.
[00:36] <bschaefer> sooo then it doesnt matter which one you pick!?
[00:37] <bschaefer> :|
[00:37] <bschaefer> RAOF, https://github.com/xbmc/xbmc/pull/10922
[00:37] <RAOF> It *does* matter which one you pick.
[00:37] <RAOF> For example, if you pick the one that doesn't support GPU decoding you won't be able to do GPU decoding on it :)
[00:37] <bschaefer> it matters *but* it'll always display?
[00:37] <RAOF> Yes.
[00:37] <RAOF> Asterisk.
[00:37] <bschaefer> :)
[00:38] <RAOF> The relevant asterisk here is: You can't currently hand a buffer to Mir at all.
[00:38] <bschaefer> hmm so how would one pick a GPU render node that *supports* this? Poke the extension?
[00:38] <bschaefer> from the fd?
[00:39] <RAOF> Correct.
[00:39] <bschaefer> sooo thats *all* that matters is picking a correct render node that supports the extension you want to support
[00:39] <RAOF> You'd just need to initialise vaapi on the render node.
[00:39] <bschaefer> right, soo its up to me to pick a render node that supports what i expect out of vaapi
[00:40] <bschaefer> so for kodi, in this case only supports intel atm
[00:40] <RAOF> Or, rather, you could initialise the vaapi library on *all* render nodes, and then pick!
[00:40] <bschaefer> EGL_LINUX_DRM_FOURCC_EXT
[00:40] <bschaefer> since it *needs* this
[00:40] <bschaefer> based on which one fails?
[00:40] <bschaefer> when you init vaapi?
[00:41] <RAOF> You could happily use both simultaneously if you wanted - picture in picture, or something.
[00:41] <RAOF> There's no requirement that you use a single GPU :)
[00:41] <RAOF> Except, I think, in the kodi code :)
[00:41] <bschaefer> :)
[00:42] <bschaefer> yeah it slightly depends on one va display atm
[00:42]  * bschaefer can possibly come up with a decent solution to query extensions *somehow* from the fd
[00:42] <bschaefer> RAOF, the good news is it *does* work on mir
[00:42] <bschaefer> and works well
[00:43] <RAOF> Oh, sweet.
[00:43] <bschaefer> the drm side of things
[00:44] <bschaefer> so DRM + EGL + Render nodes 100% works (with only liner/bi for scaling)
[00:44] <bschaefer> scaler* since nothing else seems to be implemented in the driver as far as i know?
[00:45] <bschaefer> RAOF, running the same video 3840x2160p60 on mir with the same settings frames dropped 0, frames skipped 0
[00:45] <bschaefer> for X11 dropped 0, skipped 101
[00:45] <bschaefer> err skipped for mir was 3
[00:45] <bschaefer> (for 8 min of that video)
[00:46] <bschaefer> (using mir on kms)
[00:47] <bschaefer> RAOF, are... the extensions part of the inode? ie. stat that fd?
[00:47]  * bschaefer looks around more
[00:50] <RAOF> No.
[00:50] <RAOF> The only way you can check extensions is to bring up a driver on the fd.
[00:50] <RAOF> Because it's the driver that implements the extensions, anyway :)
[00:50] <bschaefer> right, soo bringing up the driver on the fd
[00:50] <bschaefer> opening a gl context?
[00:51] <bschaefer> RAOF, i suppose the kernel does that somewere i can dig around as my googling is missing specific terms atm haha
[00:51] <RAOF> No, not the kernel.
[00:51] <RAOF> The userspace driver.
[00:51] <bschaefer> o so mir would be doing that?
[00:51] <RAOF> No, mesa/libva
[00:52] <bschaefer> RAOF, which would be part of the vaDisplayMir?
[00:52] <bschaefer> bits?
[00:52] <RAOF> Well, which is currently a part of the vaDisplayDRM bits.
[00:52] <bschaefer> right, but the DRM part puts that on the users
[00:52] <bschaefer> well for RenderNodes
[00:52] <bschaefer> since we cant drmOpen a device
[00:52] <bschaefer> since kms already opens it
[00:53]  * bschaefer locked up his machine debugging that a few times...
[00:53] <RAOF> So, if vaDisplayDRM returns non-null you've handed it a rendernode that it has a driver for.
[00:53] <bschaefer> RAOF, but that doesnt mean *it* supports an extension we need
[00:54] <bschaefer> so for kodi it has a specific extension EGL_LINUX_DRM_FOURCC_EXT
[00:54] <RAOF> Right.
[00:54] <bschaefer> that it uses to get a decoded image in an expected format
[00:54] <RAOF> *That* extension is required on the *display* device.
[00:54] <RAOF> So, since you've already got an EGL context on the Mir surface, you can query it.
[00:54] <bschaefer> ooo right and we use
[00:55] <bschaefer> the egl context in vaapi atm
[00:55]  * bschaefer checks if they already do that
[00:55] <bschaefer> hm no they take the current egl context from the windowing system and create a different one
[00:56] <RAOF> Well, whatever EGL context they create on the Mir surface is going to be on the display device.
[00:56] <bschaefer> riht
[00:56] <bschaefer> right*
[00:56] <bschaefer> they make current with
[00:56] <RAOF> (Which is not necessarily the same device that vaDisplayDRM is using, but that doesn't matter much)
[00:56] <bschaefer> err create a context
[00:56] <bschaefer> new_context, mir_context
[00:57] <bschaefer> RAOF, right, which is where i was wrapping around to
[00:57] <bschaefer> soo if mir is using amd
[00:57] <bschaefer> which wont have EGL_LINUX_DRM_FOURCC_EXT, it'll have to bail out *anyway*
[00:57] <bschaefer> before we even get to the drm va display btis
[00:57]  * bschaefer doesnt see any extension checking strangly
[00:57] <bschaefer>   if (gpuvendor.compare(0, 5, "intel") != 0)
[00:57] <bschaefer> o yeah they check for that specificly
[00:58] <RAOF> The proprietary drivers may or may not support EGL_EXT_image_dma_buf_import ; AFAIK all the mesa drivers do, though.
[00:59] <bschaefer> RAOF, i suppose from there is up to me not to pick the wrong render node though?
[00:59] <bschaefer> ie. if we are on render node 130 (the one mir is using with the intel support)
[00:59] <RAOF> Nope, doesn't matter.
[00:59] <bschaefer> as long as the display
[00:59] <bschaefer> right
[00:59] <RAOF> What you *should* do, though, is loop through all available rendernodes.
[01:00] <bschaefer> so that extension is only required on w/e card the mir serve ris running on
[01:00] <bschaefer> RAOF, what im doing currently is just running through 128 --> 128 + 16 and seeing if they exist
[01:00] <RAOF> Because there's no guarantee that vaGetDisplayDRM will return non-null on the first one you pick.
[01:00] <bschaefer> ooo very true
[01:00]  * bschaefer updates branch
[01:01] <RAOF> Argh.
[01:01]  * RAOF notices the lack of ++counter in the test.
[01:03] <bschaefer> thanks for answering those... and enjoy fixing tests!
[05:41] <fritsch> RAOF: bschaefer: this mysticaly machine needed to support RG8 and R8 extensions for the dma_buf transfer - and as besides intel no one implements it ...
[05:42] <fritsch> concerning the post on github: vaPutSurface is no usecase for kodi, we use egl_createImageSomething extension
[05:42] <RAOF> fritsch: Only the EGLImage consumer needs that extension, though, right?
[05:42] <fritsch> jep
[05:42] <fritsch> so intel would be the "consumer"
[05:42] <RAOF> fritsch: So Intel is the only GPU that can *output*, but any dma-buf capable GPU can decode.
[05:42] <fritsch> and amd for example would be the decoder
[05:43] <fritsch> jep
[05:43] <RAOF> Yup. Fierce agreement!
[05:43] <fritsch> yeah, in that github discussion something else, we had a little fight two days before was "discussed" un the vaapi cover ...
[05:43] <RAOF> Why don't you use vaPutSurface, by the way?
[05:43] <fritsch> lol
[05:43] <fritsch> reason in 1 minute, as work is calling:
[05:43] <fritsch> it scales
[05:44] <fritsch> it scales limited video range to full range without dithering
[05:44] <fritsch> killing all the grey ramps
[05:44] <fritsch> 2nd: it does a full copy!
[05:44] <fritsch> so, quality sucks and performance also
[05:44] <RAOF> Urgh.
[05:44] <fritsch> with the dma_buf approach we can directly use a shader on the Y and VU plane
[05:44] <fritsch> and are done
[05:44] <fritsch> without copying anything
[05:45] <fritsch> also vaPutSurface is GLX only
[05:45] <fritsch> there is no EGL alternative to it and also (obviously) no DRM alternative
[05:45] <RAOF> Fair enough. vaPutSurface *should* be able to do zero-copy to display in optimal circumstances, but I don't know if it *does* :)
[05:45] <fritsch> it can't
[05:45] <fritsch> it is basically a texture from pixmap approach
[05:45] <fritsch> or better said: you can use it as texture from pixmap copy
[05:46] <fritsch> that will only work with real opengl
[05:46] <fritsch> oki - got to go. Back in 12 hours :-)
[05:46] <RAOF> :)
[05:46] <fritsch> thx for your post in the bugreport
[05:46] <RAOF> It should be able to use the Present extension and zero-copy it, but probably doesn't :)
[05:46] <fritsch> does anyone on the planet use its present extension?
[05:46] <fritsch> :-)
[05:46] <fritsch> especially if you are an OpenGL / OpenGLES application?
[05:47] <fritsch> s/bugreport/pull request/
[05:54] <RAOF> Yeah, GL uses the Present extension nowadays.
[05:55] <RAOF> GLX (via DRI3)
[15:10] <alan_g> attente: where's the best place for tracking gtk-mir bugs? I've seen them reported against lp:mir and lp:miral and am not 100% sure where to redirect them.
[15:12] <attente> alan_g: against gtk with the tag gtk-mir
[15:13] <attente> alan_g: can you point me to your surface positioning feedback branch? sorry it's taken so long for me to look at it
[15:17] <alan_g> attente: therre's two parts, one is in mir-0.25 (which is in a silo somewhere) the other got released in miral-0.2 but needs the unreleased Mir for you to make much use of it.
[15:17] <attente> alan_g: it's ok, don't need a release, but if you have links to the branches, that works too
[15:18] <alan_g> lp:mir/25 lp:miral/release
[15:34] <kdub> does anyone know if the -egl and -egl_sync flags work on xmir? strange green-screen behavior for me
[15:34] <kdub> sw works alright
[15:36] <anpok> last time i tried I experienced the same..
[15:45] <kdub> anpok, thanks
[19:04] <fritsch> RAOF: can you test the patches with your amd gpu doing vaapi decoding and the intel card doing the rendering?
[19:05] <fritsch> kodi's code blocks non "intel" renderers anyways ...
[19:05] <fritsch> vaapi will be disabled for these when not overwritten
[19:05] <fritsch> anyways
[19:06] <bschaefer> fritsch, he is on UTC + 11 :)
[19:06] <fritsch> ah - so he will wake up soon, right? :-)
[19:07] <bschaefer> hmm maybe 4 hours?
[19:07] <bschaefer> maybe 3 when he'll be on
[19:07] <fritsch> :-)
[19:07] <fritsch> was for the backlog anyways. I met him that morning before I was going to work
[19:07] <fritsch> so just returned
[19:07] <bschaefer> o nice
[19:08]  * bschaefer didnt see the backlog due to sleep and to lazy to setup a way to be on at all times :)
[19:08] <fritsch> isn't it publically logged somewhere?
[19:09] <bschaefer> o yeah i think so
[19:18]  * bschaefer should fix kodi seg faulting when theres no mir socket
[19:20] <bschaefer> hmm actually that happens on x11 as well
[19:20] <fritsch> jep
[19:20] <fritsch> :-)
[21:45] <bschaefer> fritsch, eek... i rebased... and seem to have added random things?
[21:46] <bschaefer> https://github.com/xbmc/xbmc/pull/10898
[21:51] <bschaefer> fritsch, nm fixed, just needed to fetch upstream and rebase
[21:55] <bschaefer> (also thanks for telling me about ctrl+o made me realize I didnt do that for mir :) fixed now