On Tue, 31 Dec 2013 21:49:16 +1000 David Seikel <[email protected]> said:
> On Tue, 31 Dec 2013 20:11:18 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > On Sat, 21 Dec 2013 12:52:24 +1000 David Seikel <[email protected]> > > said: > > > > > I'm recovering from major illness I had yesterday, but reading > > > through this I had two brain farts. Might be something worthwhile > > > in them, or they might just be farts. So hold your nose while you > > > read my comments, and be gentle if I'm completely insane. > > > > nose holding now... > > > > > On Sat, 21 Dec 2013 11:07:46 +0900 Carsten Haitzler (The Rasterman) > > > <[email protected]> wrote: > > > > > > > On Fri, 20 Dec 2013 15:25:01 -0200 Iván Briano > > > > <[email protected]> said: > > > > > > > > > The current async render is sending each render command to the > > > > > thread, and here it seems you want a thread to do the whole > > > > > render. That wasn't very clear, let's try again. > > > > > > > > > > Are you planning on messing with the object's render functions > > > > > so they can be called from a thread? As opposed as what we have > > > > > now, where they are called from the main loop, they in turn > > > > > call the engine functions and these will check the do_async > > > > > flag to decide if they draw in place or if they send a command > > > > > to the render thread. > > > > > > > > first i'm just building some basic structure here, so nothing is > > > > set in stone right now. > > > > > > > > i would LIKE parallelize SOME bits of the pipeline before > > > > rendering - but not actually make them async. eg have 2, 4, 8 > > > > threads etc. walk over objects in parallel generating small lists > > > > of update rects as we do now in serial and then merge them back > > > > into parents to finally figure out our update regions. this > > > > basically involves a fully parallelized tree walk, BUT it needs > > > > to handle the "graph" nature of evas where things outside your > > > > tree (smart object) could affect things inside of it (eg > > > > clippers). > > > > > > > > i really am not sure how to do this other than first walk the tree > > > > (and then branch out with the graph) and figure out what is > > > > dependant and in independent and then throw it at N threads. for > > > > now i suspect this will be way too expensive and the gain will be > > > > less than the cost, but i have it marked to have a try at at some > > > > point. i won't know the result until i've tried. > > > > > > > > the other possible solution here is still walk tree like now BUT > > > > put off into async thread. in THIS case we can't reset yet. it > > > > means ALL operations to that canvas after evas_render have to > > > > block and wait for this to finish, unless it's sync rendering OR > > > > the caller wanted an update list - then we have to generate > > > > update list first before returning. > > > > > > > > i'm not fond of going through every evas api call that can affect > > > > the canvas or a child of it and putting in a "if we're doing an > > > > async op in the bg on the canvas itself - then block and wait", > > > > so for now it's on the idea list, and i will structure code to > > > > make it easy to shuffle in later. i'm pondering at the moment how > > > > i would have to change the render pre/post methods of objects to > > > > handle this. i know already i need to create new pre/post methods > > > > per object to make this possible, but for now at least i likely > > > > am going to have to keep the object tree walk inline, generate > > > > update rects, then walk the tree AGAIN generating prepare > > > > commands, draw commands etc. per rect. > > > > > > > > the other thing i want to do is not just have a single render > > > > thread but have multiple other worker threads too so. right now > > > > the infra is a single bg thread. i want to be able to throw 2, 3, > > > > 4, 6, 8+ threads at a problem, IF it can be done. so the above > > > > walk and generate update rects AND commands might be possible to > > > > do with more than 1 thread to speed it up. > > > > > > > > another one of those ways to parallelize is to break up rendering > > > > into more stages. stage 1 hands off to stage 2, stage 2 off to > > > > stage 3, stage 3 off to stage 4 etc. any stage 4 has to wait for > > > > previous stage 4's but a stage 3 can work in parallel to a stage > > > > 4 etc. etc. - we already have a primitive version of this - stage > > > > 1 and 2. 1 is mainloop, 2 is the async render thread. > > > > > > > > an example of the above is in the software renderer, do > > > > pre-rendering of font glyphs we know we will need (or very likely > > > > need) and literally have a pool of 2, 4 or 8 threads and throw > > > > every glyph we have at these to pre-render prior to the text > > > > renderer needing them. another is scalecache. pre-prepare all > > > > "expensive" scaled data in several worker threads (can be shared > > > > with the font thread pool). anything smooth scaled is so costly > > > > that N threads == N times faster. we can also BEGIN image > > > > loads/decodes here in threads (when not already cached) - > > > > admittedly cserve should negate much of the benefit of this by > > > > ensuring all data is already there long before this point, so for > > > > now it's a theoretical talking point, but unlikely to actually > > > > get implemented or have practical value. when preparation pool is > > > > done it hands off rendering to the composition thread. > > > > > > Hmm, correct me if my memory is wrong, but BOB involves building a > > > big Lua blob from lots of bits of boiler plate and custom slices of > > > source. This big Lua blob could then be cut up into separate Lua > > > scripts after some analyses, to be executed by something like the > > > Lua worker threads engine I've mentioned before? This is the sort > > > of thing that your new threaded render work might include? > > > > > > If this is true, I'm beginning to think my LSL -> Lua conversion > > > work might be useful as a source of ideas here to. > > > > ummm but this mail isn't about bob... it's about core evas rendering > > infra... ? (nose being held). > > So, entirely separate things then. That one was an official brain fart. > > > > > for opengl this can be split differently. for gl we still need to > > > > render glyphs BUT we also upload them to textures. the same for > > > > images - we can upload images to textures prior to handing off to > > > > the next stage which is triangulation (the evas gl common pipeline > > > > stuff). triangulation can hand off to an actual dumb "draw the > > > > triangles" thread that just takes a queue of triangles + states > > > > and dumps to the gpu... which hands off to the swapbuffers > > > > thread... > > > > > > > > the questions here are how do i make some shared infra that > > > > engines have in common first. this code is to explore that. > > > > reality is that gl will be hard from the simple point that gl > > > > contexts are limited. a context costs a lot of memory (with mesa > > > > they cost between 10-40mb of ram for a single context depending > > > > on your version of mesa - it's a memory hog to have a gl context, > > > > though it should not be. they shouldn't consume more than the > > > > memory needed to store the gl state at any point - they could > > > > balloon out to store command queues when needed, but then should > > > > trim back down again). > > > > > > > > so having multiple contexts is not a fantastic idea. the other > > > > problem is that a context can ONLY be bound to a single thread at > > > > any time. that presents a problem - we either have a single > > > > context and a single render thread for doing actual gl stuff > > > > (texture uploads, draws, swaps), OR we spend the memory on > > > > multiple, but then we hit another issue... 2 contexts are not > > > > allowed to share the same dest buffers/surfaces. : ( (even if > > > > unused). so gl presents a whole bunch of gotchas. reality is that > > > > i likely can split out triangulation that hands off to the gl > > > > context thread that does everything else (texture uploads, > > > > switching of state, drawarrays of triangles and swapbuffers). > > > > > > My last attempt at getting EFL to share a GL context with a 3D > > > library worked out well, but it has bit rotted since I last worked > > > with it and no longer works with EFL 1.8. Admittedly I had to > > > delve into the dirty guts of EFL to fish out the details of what > > > and how to share the GL context and associated bits. I've not had > > > a chance to look at what needs to be fixed up to get it to work > > > again. > > > > > > One of the goals of EFL is to be the GUI library for games. For 3D > > > games the developers will either need to work with a 3D library, or > > > build stuff from scratch on top of EFL. Either way it's likely > > > they'll need to get to the GL context that EFL is using, or create > > > their own and share it with EFL. Hopefully this sort of thing will > > > get some love. Especially with what you just mentioned about how > > > heavy weight a GL context is, sharing them seems the only sane > > > thing to do. > > > > > > It might even be sane to have a bit more 3D support in the EFL > > > rendering pipeline, but that probably means writing our own 3D > > > stuff. That's something I may end up doing in the future anyway > > > given my big virtual world plans. But for now I just want to get > > > Irrlicht working with EFL, in a stable way that wont bit rot again. > > > > evas_gl api is there not to officially provide a gl context for > > apps... and a opengl-es2 wrapper and compat api that workson desktop > > gl AND gles2 impls with "no changes". > > Did you mean the "not" in "is there not to officially provide"? s/not/now/g :) > But you said above - > > > > > a context costs a lot of memory (with mesa > > > > they cost between 10-40mb of ram for a single context depending > > > > on your version of mesa - it's a memory hog to have a gl context, > > ... > > > > > so having multiple contexts is not a fantastic idea. > > ... > > > > > 2 contexts are not > > > > allowed to share the same dest buffers/surfaces. : ( (even if > > > > unused). so gl presents a whole bunch of gotchas. > > My previous experiments only got the 3D bit to render to the same > windows as Elementary by sharing the GL context that EFL created. > Soooo, what are EFL 3D apps supposed to do that might actually be "a > fantastic idea"? Or more to the point, what is the official way to get > a 3D library written by others to work with EFL, both rendering to the > same window? > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
