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"? 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.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
