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