On Tue, 31 Dec 2013 23:36:18 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> 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 :) Phew, I can proceed with my life's work this new year after all. B-) > > 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. > > -- 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
