[Bf-committers] Proposal: Blender OpenCL compositor

[Ton Roosendaal]

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   ton at blender.org    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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>