/srv/irclogs.ubuntu.com/2016/11/12/#ubuntu-mir.txt

=== JanC_ is now known as JanC
=== JanC is now known as Guest64473
=== JanC_ is now known as JanC
fritschbschaefer: https://github.com/fritsch/xbmc/commit/372a3ff88360ded6fb09692621cbfe88d34aa9f0 works for me quite fine on X1119:31
fritschthat's basically your work with some kodi glue and proper closing of the handle19:32
fritschthat will really make VAAPI X11 unaware which is really great19:32
fritschthanks very much for that19:33
bschaefer:) yeah was reading the code19:33
bschaeferand *all* the direct calls for the x11 display it self was only used to get the va display19:33
fritschjep19:34
fritsch"historic reasons"19:34
bschaeferyeah it happens :)19:34
fritschwe use glx via vaPutSurface before19:34
fritschused19:34
bschaeferoo yeah that makes sense19:34
fritschwhich was _the only_ way19:34
fritschto use vaapi for a very long time19:34
bschaeferfritsch, here is a cheap RAII for the fd http://paste.ubuntu.com/23467327/19:34
bschaefer(since i wasnt cleaning it up before)19:34
bschaefero i see, well seems like DRM/EGL is a very nice cross display server19:34
* bschaefer was going to look into making a better look up of /dev/dri/renderD19:35
bschaeferand to check for kernel >= 3.1519:35
fritschthere is a better one19:35
fritschlet me find it out - I just "patched it together" for a wayland packager19:35
bschaefero sweet :)19:36
bschaeferi was just reading its somewhere between 128 < 128 + 6419:36
bschaeferfritsch, also the other thing i wanted to ask: CSingleLock lock(g_graphicsContext);19:37
bschaeferwas that just needed to get the X11 display?19:37
fritschthe problem here is19:37
* bschaefer didnt dig around to much about the thread saftey19:37
fritschthat rendering in that does only work from thread 119:37
fritschso whenever you access the display stuff19:37
fritschyou need to make sure to use a more or less global lock :-(19:37
fritschwhich DRM will also solve for us19:37
fritschin that regard19:37
bschaeferi see, but there was no g_Windowing usage there before?19:38
bschaeferit just did a XOpenDisplay() vs a g_Windowing.GetDisplay();19:38
bschaeferor you ment anytime you access the m_X11Display19:39
bschaeferyou'll need to lock, that makes sense19:39
bschaeferfritsch, also the check of the ret of vaInit was only needed because i wasnt checking the FD (was getting a -1 on KMS/mir)19:40
fritschlooking again19:41
fritschit was used from decoder thread19:41
fritschyeah, please pick what you need from that commit19:41
fritschit's yours :-)19:41
fritschnot mine19:41
bschaefer:)19:41
fritschi just fixed it up a bit19:41
bschaeferyeah, anyone can take it :)19:42
fritschconcerning the RAII - I think explicit close is fine19:42
fritschwe have the destroy context anyways19:42
fritschso, something explicit is done never the less19:42
bschaeferyeah thats fine, i was checking when i manually hit exit it wasnt hitting the dtor anyway (not sure why)19:42
* bschaefer assumes someone kills the thread in an unkind way :)19:42
fritschbut do it how you prefer it, you know what you are doing :-)19:42
* bschaefer spend yesterday just reading about drm/vaapi soo still figuring things out19:43
fritschyou exactly hit the 4 points that needed adjustment19:43
bschaeferbut yeah ill attempt to clean it up and would most likely be better in a different branch19:43
fritschso all fine19:43
fritschjep19:43
bschaefer(as this branch would also affect x11 less confined)19:43
fritschThis change can also be PRd separately19:44
bschaeferyeah i agree19:44
fritschthen we can discuss it and you can base your other MIR work on that then19:44
* bschaefer should figure out git a bit more19:44
bschaefersounds good!19:44
fritschwhat kernel version has ubuntu 14.04?19:45
fritsch3.13 right? iirc?19:45
bschaeferdang let me check im always way to far on the ubuntu version ... on yakkety atm19:45
fritsch14.04.4 should have a far newer one19:45
fritschi have zero issues dropping support for any kernel < 4.0 anyways19:45
fritschas we require vaapi 0.34 anyways19:46
bschaeferwell then that makes things easier :)19:46
fritschwhich only 16.04 or later ship (of the supported ones)19:46
fritschit's intel gpus - things were pretty rough back at 3.1319:46
bschaeferlooks like 3.1619:46
fritschnope19:46
fritschthat can't be :-)19:46
* bschaefer checks the actual19:46
bschaefersource list19:46
fritschhttp://packages.ubuntu.com/trusty/linux-image-generic19:47
fritsch3.1319:47
fritschlet's see what the debian stable guys are doing19:47
bschaeferyeah there we go19:47
fritsch3.1619:48
fritschno problem - just write a comment above it19:48
fritschand fine19:48
bschaefersounds good, sounds like if you dont have vaapi 0.36 you disable it anyway19:48
fritschjep19:48
bschaefercool, ill try doing a branch directly from xbmc vs fork19:49
fritschit should all run on 16.04 (concerning vaapi)19:49
fritschwhat do you mean by that? :-)19:49
fritschI'd just fork kodi once to your repo, that you did19:49
fritschnow create a seperate branch: vaapi-dropx11-dependency19:49
bschaeferwell dont think i can fork again... i know bzr but not git very well :)19:49
bschaeferooo19:49
bschaeferfrom my fork dang... well ive been pusing to master in my fork19:49
fritschyou already forked on github :-)19:49
fritschby clicking fork19:50
bschaeferright, then i didnt branch19:50
bschaeferin my fork haha19:50
fritschjep, you dev on your master19:50
fritschnot a problem19:50
fritschstash everything or commit it locally19:50
fritschthen add xbmc-upstream as remote, by doing19:50
bschaeferhmm how do i go back to xbmc master then branch from that? So i can avoid the mir changes?19:50
fritschgit remote add xbmc-upstream https://github.com/xbmc/xbmc.git19:50
bschaefersince the vaapi stuff is differnet19:50
* bschaefer will just have to read up on git19:51
fritschi just tell you19:51
fritschnow do in your master: git commit -m "Squash me later, clean me up" -a19:51
fritschfollowed by:19:51
fritschgit fetch xbmc-upstream19:51
fritschgit checkout -b vaapi-drop-x11 xbmc-upstream/master19:51
fritschnow you are on a vanilla new branch of kodi's master19:51
bschaeferoo that make sense19:51
bschaefercool, thanks!19:51
fritschnow either cherry-pick the commit you have in your master19:52
fritschby doing: git log master19:52
fritschfinding the id19:52
fritschand doing: git cherry-pick id19:52
fritschthat will apply just that commit on top19:52
fritschyou can also add me as remote19:52
bschaefero so i can pick from your commit19:52
bschaefervs commit this19:52
fritschgit remote add fritsch https://github.com/fritsch/xbmc.git19:52
fritschgit fetch fritsch19:52
fritschgit cherry-pick b044a9ff578d3fddb4a717e266d5e6f8b32bb67819:53
fritschthat gets you my commit I showed you19:53
fritschnow do your changes, commit them19:53
fritschgit commit -m "squash me" -a19:53
fritschnow comes the git magic after you are finished with everything:19:53
fritschgit fetch xbmc-upstream19:53
fritschgit rebase -i xbmc-upstream/master19:53
fritschnow squash the squash commit in the first one (writing squash in front of it instead of pick)19:54
bschaeferthat happens on the rebase?19:54
fritschafterwards: git push -f origin vaapi-drop-x1119:54
fritschon the rebase it uses the xbmc-upstream/master branch19:54
fritschas a given base19:54
fritschand tries to apply your commits on top of it19:54
bschaeferto *base* the changes against (something i wish bzr had)19:54
fritschyou can see them (-i <- interactive)19:54
fritschand either pick them, or squash them19:55
bschaefero cool, ill be using that19:55
fritschpick 123419:55
fritschsquash 456719:55
bschaeferfritsch, from there do a pull request from that branch?19:55
fritschthat will squash 4567 into 123419:55
fritschjep exactly19:55
bschaefersweet19:55
fritschyou should never rebase if you are the upstream19:55
fritschas rebasing means: loosing history19:55
* bschaefer now knows git until something goes wrong horribly :)19:55
fritsch:-)19:55
fritschyeah, just ping me - I can help you19:55
bschaefercool, and thanks again!19:56
fritschoki, so let's as next step try to get that DRM PR out to us19:56
fritschi hope I convince everyone to branch in a very near future19:56
bschaeferdo the PR now before clean up?19:56
bschaefer(for at lease conversation)19:56
fritschnope, after you are finished with everything19:56
bschaefero ok sounds good19:57
fritschas you like it19:57
bschaeferyeah19:57
fritschthen we can discuss on the final commit19:57
fritschconcerning printf and kodi19:57
* bschaefer likes printf19:57
fritschfor kodi we use CLog and its static method Log19:57
fritschthere is LOGNOTICE, LOGDEBUG, LOGERROR19:57
bschaeferi tried looking for this log before...19:57
fritschnotice spams everything, LOGDEBUG only when debug logging is enabled19:57
fritschERROR makes it red in the log19:57
fritschhehe19:57
bschaeferis it an env var?19:58
fritschnope19:58
bschaeferor compile time?19:58
fritschyou include it19:58
fritsch#include "utils/log.h"19:58
bschaeferi mean umm how do i read these logs?19:58
fritschall that stuff lands in ~/.kodi/temp/kodi.log19:58
fritschtail -f ~/.kodi/temp/kodi.log19:58
bschaefero ok thats where i was missing19:58
bschaeferfritsch, yeah i usually use printf for my own debugging to stdout/err but usually switch to loggers :)19:59
* bschaefer will attempt to just use the logger19:59
fritschFor DIVX: Player Settings (Expert Hierarchy) -> Enable Mpeg420:00
fritschwe have it disabled by default. As you know: in the times of divx and mpeg-420:00
fritschthe standard was not so standard as h264 was20:00
bschaefero dang, yeah i can imagine20:00
fritschhehe20:00
fritschoki, for the DRM change I think it won't make it into v17 - as it is a majore change and we are near to RC20:02
bschaeferyeah i agree (it has possible problems not tested out)20:02
fritschbut if the code is written and ubuntu will ship mir + kodi20:02
fritschyou can easily pick your "upstream" commit20:02
fritschinto your package as upstream backport patch20:02
bschaeferyeah i can also push a pathc20:02
bschaeferyeah20:02
* bschaefer was my plan :)20:02
fritschthat's why it's brilliant if we get it upstream20:03
bschaeferif it wasnt part of the release20:03
fritschwe often need to cope with the other way round :-(20:03
* bschaefer prefers upstream == less patches20:03
fritschdistros patch and patch20:03
bschaeferyeah20:03
fritschand we don't see the patches - and more severe - cannot tell what is wrong20:03
bschaefergets very crazy trying to debug someones binary when they have all these patches20:03
bschaeferyeah!20:03
fritschif you can make the first mir release with a fully mir aware kodi + hw accel20:03
fritschpeople will realize something: it's easy to use mir20:03
fritschand it just works20:04
fritschat the end ubuntu is aimed at the desktop20:04
fritschnot at the frickler, that is hacking everything together20:04
fritschso out of the box experience is the most important for such a goal20:04
bschaeferyup, soon *hopefully* people will realize they wont even notice what display server they are running20:04
fritschthat's the goal, exactly20:04
bschaeferyup :)20:04
fritschperhaps there is even a "better way" of surface sharing without egl20:05
fritschwith just drm20:05
fritschi know there is, but zero copy rendering is not just about copying20:05
fritschbut yeah, displaying it directly20:05
fritschcurrent limitation with vaapi is, that there is no way to transfer yuv420p1020:05
fritschvia egl / mesa20:05
fritschmeans: hevc-10 decoded content we can currently not display20:06
fritsch(won't work on your laptop anyways)20:06
fritschneed to wait for the T47020:06
bschaefero so its planned but not released?20:06
fritschbut we are working on that with the mesa guys20:06
bschaefervery nice!20:06
fritschi have a poc already that decodes and shows what is missing for the render part20:06
fritschbasically we miss the R16 G16 and RG16 transfer format20:07
bschaeferalso, to really see the difference between a hw accel vs software for the video...20:07
bschaefershould i just stress my system?20:07
* bschaefer cant really tell when software seems to render fine20:07
bschaeferi assume the embedded devices will be a big difference20:07
fritschhttps://github.com/fritsch/xbmc/blob/372a3ff88360ded6fb09692621cbfe88d34aa9f0/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1238 <- see20:08
fritschyou can do: kodi-send -a PlayerDebug20:08
fritschthere you see render skips and render drops20:08
fritschif you don't get any skips20:08
fritschall fine20:08
bschaeferooo very good to know20:08
fritschif you want to test mir's throughput20:08
fritschthere is a 3840x2160p60 <- 60 progressive frames20:09
fritschof a h264 big buck bunny20:09
fritschthat's a good throughput test20:09
bschaefero geez, yeah that sounds like a good test20:09
* bschaefer goes to download20:09
fritschas you run windowed, make sure to set the scaling to bilinear20:09
fritschyour broadwell (T450) won't be fast enough to do it with lanczos320:09
bschaeferfritsch, well the screenshots i usually show is in the X11 platform (ie. Mir on X)20:10
bschaeferwhich is not great for throughput testing20:10
bschaefersince theres the added X11 layer20:10
* bschaefer will test on the metal for that in KMS which will be fullscreen20:10
fritschyou can press enter while playback20:10
fritschgo to the video settings comming up20:11
fritschand choose: Deinterlace-Method: VAAPI-MCDI20:11
fritschand Scaling-Method: Bilinear20:11
fritschand do: save for all videos20:11
fritschnormally we prefer lanczos3 (quality of course)20:11
fritschbut it makes no sense to upscale 1080p to 1080 display with a lanczso scaler20:11
fritsch:-) as nothing is scaled20:11
bschaeferhmm i only see VAAPI-Bob, VAAPI-MotionAdaptive20:12
bschaeferand motion comp20:12
fritschjep20:12
fritschmcdi <- motion compensation deinterlacing20:12
fritschthe "translation" guys :-)20:12
fritschhad fun20:12
fritschhttp://forum.kodi.tv/showthread.php?tid=231955 <- here is a bit of a read up why vaapi is as it is now20:12
bschaefero cool im trying to read up a bit more on this whole thing20:13
fritschand also some settings - but "slow" :-) too much information currently20:13
fritschdon't stress yourself, please - I am a bit in ahurry, that's why I post so much information20:13
fritschhehe20:13
bschaefero no worries :)20:13
bschaeferi can always re-read the logs (which i usually end up doing to double check things)20:13
fritschoki, then I wish you good luck on the rest of the way to a working mir + vaapi20:14
fritschi think if you have some nice screenshots up and running20:14
bschaeferthanks, and thanks again for all the info!20:14
fritschthe "linux bild zeitung" <- german for news paper stuff20:14
fritschwill make something about it20:14
fritschphoronix.com20:14
bschaeferyeah ill make sure to get some screen shots of mir + x11 as well20:15
bschaeferto show both still working20:15
fritschnot for me - if you want some positive publicity about "how easy it is" to support mir20:15
fritschthen www.phoronix.com is a good thing ... (only for that ;-))20:15
bschaefertrue, depends on how its spinned :)20:15
fritschwe sometimes ask them to publish things whenever hw vendors don't make good drivers20:15
fritschthere was a "fglrx time"20:16
fritschin shorT: their driver sucked, their xvba sucked, we made it public. amd oss devs implemented vdpau with us20:16
fritschwe dropped fglrx completely20:16
bschaefer:)20:16
fritschtadaaa :-) dead of fglrx in linux world for any video decoding stuff20:16
fritschand since then we still work with the amd oss devs together, especially when we plan new stuff20:17
fritschwayland support, egal buffer sharing20:17
fritschand so on20:17
bschaefernice! That helps a lot i can imagine!20:17
fritschoki - afk now :-) good luck with all the stuff20:17
fritschand do not hessitate to ping me20:17
bschaeferthanks! (only about noon here)20:17
fritschor send me an email20:17
fritschor github20:17
fritschwhatever you prefer20:17
bschaefercool, sounds good20:17
fritschbschaefer: PlayerProcessInfo -> just press "o"20:25
fritsch(so, now I am really gone)20:25
fritschbut this does not show PlayerDebug info20:25
bschaeferill hvae to use that debug command from above i assume?20:25
* bschaefer can dig around20:26
fritschor map it to another key, e.g. ctl-o20:34
bschaefergood idea20:36

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!