| RAOF | bschaefer: Yo! | 00:33 |
|---|---|---|
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| RAOF | Oh, sweet. | 00:43 |
| bschaefer | the drm side of things | 00:43 |
| 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:44 |
| 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:45 |
| bschaefer | (using mir on kms) | 00:46 |
| bschaefer | RAOF, are... the extensions part of the inode? ie. stat that fd? | 00:47 |
| * bschaefer looks around more | 00:47 | |
| 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:50 |
| 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:51 |
| 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:52 |
| * 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| RAOF | The proprietary drivers may or may not support EGL_EXT_image_dma_buf_import ; AFAIK all the mesa drivers do, though. | 00:58 |
| 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. | 00:59 |
| 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:00 | |
| RAOF | Argh. | 01:01 |
| * RAOF notices the lack of ++counter in the test. | 01:01 | |
| bschaefer | thanks for answering those... and enjoy fixing tests! | 01:03 |
| === chihchun_afk is now known as chihchun | ||
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| fritsch | s/bugreport/pull request/ | 05:47 |
| RAOF | Yeah, GL uses the Present extension nowadays. | 05:54 |
| RAOF | GLX (via DRI3) | 05:55 |
| === dandrader is now known as dandrader|afk | ||
| 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:10 |
| attente | alan_g: against gtk with the tag gtk-mir | 15:12 |
| 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:13 |
| 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:17 |
| alan_g | lp:mir/25 lp:miral/release | 15:18 |
| 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:34 |
| anpok | last time i tried I experienced the same.. | 15:36 |
| kdub | anpok, thanks | 15:45 |
| === dandrader|afk is now known as dandrader | ||
| fritsch | RAOF: can you test the patches with your amd gpu doing vaapi decoding and the intel card doing the rendering? | 19:04 |
| 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:05 |
| bschaefer | fritsch, he is on UTC + 11 :) | 19:06 |
| fritsch | ah - so he will wake up soon, right? :-) | 19:06 |
| 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:07 |
| * 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:08 |
| bschaefer | o yeah i think so | 19:09 |
| * bschaefer should fix kodi seg faulting when theres no mir socket | 19:18 | |
| bschaefer | hmm actually that happens on x11 as well | 19:20 |
| fritsch | jep | 19:20 |
| fritsch | :-) | 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 | ||
| bschaefer | fritsch, eek... i rebased... and seem to have added random things? | 21:45 |
| bschaefer | https://github.com/xbmc/xbmc/pull/10898 | 21:46 |
| bschaefer | fritsch, nm fixed, just needed to fetch upstream and rebase | 21:51 |
| bschaefer | (also thanks for telling me about ctrl+o made me realize I didnt do that for mir :) fixed now | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!