Hi, To be honest, long winded discussions on ways how to implement stuff should not take away the freedom for a developer to find out him/ herself the optimal cases. I'm confident that Jeroen is aware of boundary cases here, and he will try to find a good balance for practical usage.
For as long we agree on existing and future demands on compositing in Blender, we should give him our blessings :) Relevant specs are for example: - desired input methods, like storage, types, UI workflow, colorspaces, alpha, (plugins?) - desired output specifications, like memory/cpu/gpu performance and visual feedback -Ton- ------------------------------------------------------------------------ Ton Roosendaal Blender Foundation [email protected] www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 22 Jan, 2011, at 13:28, Aurel W. wrote: >> some gradiant base algorithm & very fast blur are in needs of full >> buffer >> for sure, but I don't understand why some nodes cannot says "I need >> full >> buffer, so I'll wait all my parents to compute and give me a FB as >> input" >> and other nodes (by default) based on tiles. So only a few would >> be slower >> than other, but still everybody would happy ? > > Yes something like that would be necessary. I guess in practice it > will be very hard to determine the required tiles, so maybe there will > be only two cases, one where only one tile is needed and the one where > simply all tiles are needed. > > I am also worried about the memory layout of this. Single tiles would > be computed to separate data structures, maybe just a single array. > All tiles are computed like this for an entire image. The next node, > which needs to operate on the entire image now has to access > individually pixels in all tiles. So you have two options, introduce > some sort of abstraction to access these pixels, or copy all tiles to > a single buffer, which then gets processed. The first one adds a lot > of overhead and cache unfriendliness. The second one also adds > overhead and memory usage by copying. Of course this would need > testing and better analysis, but it can tremendously slow things down. > >> the goal here is to build a compositor and as Matt says, it should >> do what > it's supposed too. > well, of course,... > > aurel > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
