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.
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. > 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. -- 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
