=== shuduo-afk is now known as shuduo
[07:58] <zzarr> hello!
=== sil2100_ is now known as sil2100
[08:57] <anpok_> tjaalton: hm I am trying your vulkan binaries..
[08:57] <anpok_> and I have a problem within X ..
[08:57] <anpok_> vkcube and other examples I pulled complain that there is no DRI3 support..
[08:57] <anpok_> but I actually rebuilt the most recent intel xorg video driver .. enableing dri2 in debian/rules..
[08:58] <anpok_> did I miss a step?
[08:58] <anpok_> dri3 of course..
[08:58] <anpok_> stuff runs fin on top of drm/kms though
[08:59] <anpok_> zzarr: any news form your endevaours?
[09:01] <zzarr> anpok_, it's hard to understand what parts of the kernel I need to make an Android container work/run
[09:01] <anpok_> .. write a detailed description when you figure that out..
[09:02] <anpok_> i want to try that too next time i get some more free time..
[09:03] <zzarr> right now it's more like if I figure it out
[09:03] <anpok_> :)
[09:04] <zzarr> is there a more detailed block diagram of the kernel/libhybris and all of it?
[09:08] <zzarr> anpok_, what would be the best approach? trying with the Android driver or wrap the freon driver?
[09:12] <zzarr> if the question is not clear by wrapping the freon driver I mean making a Mir-server that runs on top of freon
[09:15] <anpok_> zzarr: well you need to solve the problem of transfering a rendering result from a client to the server.. if the freon driver has capabilities to do that - then this will be the more intersting approach because you get to write some code..
[09:16] <tjaalton> anpok_: you missed reading the ppa description :)
[09:17] <anpok_> my (maybe outdated?) understanding of the chrome os rendering system is that they only have a single process doing the actual rendering with the gpu driver.. the other processes just use an inter process version of GLES/EGL and maybe some 2D drawing library
[09:18] <zzarr> anpok_, I think so too I would get a much deeper knowledge and it would work on any Chrome OS device (Intel/ARM alike)
[09:18] <anpok_> zzarr: but yeah that would also be an interesting integration task.. let USC do all the rendering..
[09:18] <anpok_> tjaalton: yeah I am good at that
[09:20] <zzarr> anpok_, I'm still not familiar with all the terms, what does USC stand for *feeling like I should know*
[09:20] <anpok_> unity-system-compositor the system compositor in the default ubuntu touch setup
[09:20] <anpok_> usually the thing that posts to screen
[09:21] <zzarr> anpok_, okey
[09:21] <anpok_> with kms/android drivers it just posts the buffer of the nested server to screen
[09:21] <anpok_> so it is a process that runs a mirserver
[09:22] <zzarr> anpok_, is that a good approach here too?
[09:23] <anpok_> what do you refer to:
[09:23] <anpok_> ?
[09:25] <anpok_> ah you mean having usc there too ..
[09:26] <anpok_> yes you need something with the necessary permissions to access the gpu.. and the screen.. and you want to allow as processes as possible
[09:26] <anpok_> thats actually even safer than with kms/android drivers..
[09:31] <zzarr> anpok_, good call
[09:32] <anpok_> *as few processes
[09:37] <zzarr> anpok_, could you help me figure out  where to start? (I'm still new to graphics in general)
[09:38] <anpok_> hm first I would try to figure out where and how chrome os sets up rendering with the drivers you have..
[09:38] <anpok_> then try to get that workin outside of chrome os..
[09:39] <anpok_> then take that as a basis for a mir graphics platform
[09:39] <zzarr> anpok_, Is the lack of console a problem or is that bypassed if I get freon running?
[09:40] <anpok_> hm no i do not think so..
[09:41] <anpok_> it might just make stuff harder to try out :)
[09:42] <zzarr> I have a kernel with console right now, so I don't think that would hinder anything
[09:51] <anpok_> i guess figuring those things out will keep you busy for a while ... then you have to look into getting the IPC services working..
[09:51] <anpok_> and after that you might have to make some changes to mir to get all of that working as a graphics platform
[09:51] <zzarr> IPC?
[09:51] <anpok_> interprocess communication
[09:52] <zzarr> okey, yes
[09:52] <anpok_> http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
[09:52] <zzarr> thanks anpok_
[09:52] <anpok_> https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome..
[09:53] <anpok_> oops
[09:53] <anpok_> strip the last two dots
[09:57] <zzarr> thanks again :-)
[09:58] <zzarr> anpok_, the second link is a bit outdated, (Chrome OS used X back then, and Freon as of Q3/Q4 last year)
[10:00] <anpok_> tjaalton: yay works..
[10:04] <anpok_> tjaalton: oh.. those demos at //github.com/SaschaWillems/Vulkan.git make the i915 reset the gpu in various ways..
[10:06] <zzarr> anpok_, it's hard to find any info about how freon works
[10:08] <zzarr> anpok_, this might be interesting https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone
[10:14] <zzarr> Vulkan looks nice
[10:16] <alan_g> alf_: I'd like your eyes on this (as you wrote the original). I tried reverting the associated changes and this appeared reproduce the original failure, but it was hardly a clean merge so I can't verify I've captured the intent: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/rework-DeadlockLP1491566/+merge/286698
[10:18] <tjaalton> anpok_: which cpu?
[10:21] <alf_> alan_g: ack, I will take a look
[10:23] <anpok_> tjaalton: i7-4750HQ .. so haswell iris 5200
[10:24] <tjaalton> anpok_: hmm might be a known issue then
[10:25] <anpok_> there is an incomplete support warning on startup of each demo..
[10:26] <anpok_> zzarr: hm there was a mir port of that one once -- running ozone as a mir client -- not what you need as far as i can tell..
[10:27] <tjaalton> yeah, the driver is in flux and moving stuff around upstream, so i haven't bothered updating it yet
[10:58] <zzarr> anpok_, I guess that I could have a look at that but only to get a general feel
=== mariogrip_ is now known as mariogrip
[12:17] <zzarr> anpok_, is there an picture or description how the components communicate in Mir?
[12:20] <zzarr> I have found this, what parts don't I need? http://i1-linux.softpedia-static.com/screenshots/Mir_1.png
[12:20] <zzarr> If I ported QtMir and QtUbuntu, would that be enough?
[12:21] <alan_g> zzarr: as it port them to something other than Mir?
[12:21] <zzarr> or is it everything below libhybris?
[12:22]  * alan_g should probably read backchat
[12:22] <zzarr> I guess I was thinking a bit wrong
[12:23] <zzarr> I should have the freon driver in the position where libhybris is now
[12:25] <anpok_> probably..
[12:26] <anpok_> there is no nice colorful picture that guides you through the source code
[12:26] <anpok_> you will have to provide an implementation of the mir::graphics::Platform interface
[12:28] <zzarr> anpok, the image I found as well as knowing that the interface mir::graphics::Platform is a colorful image ;-)
[12:29] <alan_g> zzarr: does this help? https://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/design/Architecture.dia (You need dia to view it)
[12:33] <zzarr> I was about to install dia from the repository... but I could not... it says that it don't know about a package called "dia-gnome-gnome-gnome-gnome"... I suspect I know why
[12:41] <zzarr> alan_g, nice diagram
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|lunch
=== greyback__ is now known as greyback
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader