I guess he is talking of algorithm where the entire buffer needs to be
evaluated before processing the pixels. Like knowing which is going to be
the Max Luma value in your buffer to divide all your pixels by this value.
(very simple example, but just for the case) or something like Retinex
Hi Jeron,
Please help me to determine the case when a whole output image is
needed. IMO input is readonly and output is writeonly. I don't see the
need atm to support whole output images in a 'per output pixel'
approach. And every 'per input pixel' approach can be written by a 'per
output
On Sat, Jan 22, 2011 at 8:11 PM, Aurel W. aure...@gmail.com wrote:
I also realize that the argument it would work with the current
compositor is a strong argument. But I got some problems with that.
First of all I think that a compositor should be in principal be able
to support all image
On the contrary, I think the compositor should be designed and
optimised for its purpose, compositing CGI/vfx imagery. It doesn't
need to be a completely generalised image processing system, it just
needs to do what it's intended for, well. So far I've seen a mostly
theoretical objections
Jeron : Like what are tiles in the perspective of a user/artist and
what are tiles in perspective of parallelization.
Both definitions are right, but developers and users mix the definition
and the meaning. Sorry for that.
Thats what I thought :)
Aurel : Again, just examples for
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
Hi,
j.bak...@atmind.nl (2011-01-22 at 0952.44 +0100):
image. The highest/lowest value is calculated once (not parallelized)
the pixel processor is parallelized.
Not very good example ;] as this searching problem is near as much
parallelizable as the pixel processor would be. Split the work
Hi Vilem
On 01/21/2011 01:12 AM, Vilem Novak wrote:
I'd like to have 2 more questions:
Where did go the idea of integrating gegl as the library
driving compositor processing(originally 1 of durian targets?)?
I don't know, perhaps one of the durianers can elaborate on this. I
myself see pro's
Another question, I am concerned with.
What do you mean with tiles in the context of the compositor. That a
node just processes patches/tiles of an image, so the basic entity,
which is processed becomes a tile or even a single pixel?
I hope it's commonly realized that a compositing node always
On 21 January 2011 15:34, Martin Poirier the...@yahoo.com wrote:
Not all effects needs access to all of the buffer. A lot of them only need
access to a neighbourhood around each pixels, for which a system of slightly
overlapping tiles fits the problem.
You are talking about things such as
Hi Jeroen,
I'll comment on the tiling / OpenCL proposal itself in another mail later.
I agree with Matt that it would be good to address a number of design
issues first. Perhaps these could be implemented before work on tiling
or OpenCL begins.
* Automatic data type conversion between nodes.
*
Hi Jeroen,
Node compiler. I really dislike code going through a node compiler.
OpenCL is basically C with some restrictions and a few extra
qualifiers, let's take advantage of that and for the CPU just compile
as part of the regular compilation process. It's not clear to me why
this node compiler
On Fri, Jan 21, 2011 at 8:29 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Automatic data conversion between nodes. What I'm not sure about is
the different color data types (RGBA, HSVA, YUVA, ..). This would no
be exposed to the user, all they would know is that it's a Color,
right?
Hi Brecht,
Great remarks, and several of these I can assist on too. The get-pixel
one will be toughest though... I know several nodes have been heavily
optimized to use rows.
I need to study Jeroen's proposal in detail still, can't say much...
but based on all the feedback he received,
--- On Fri, 1/21/11, Ton Roosendaal t...@blender.org wrote:
- A tile-based subdivision schedule is for two reasons;
efficient
memory use (valid for cpu and gpu alike) and for a
potential efficient
threading setup. The latter has to be carefully designed,
to prevent
bottlenecks on
DOF and Blur you can take care of with overlapping source tiles as long as
you know the maximum fetch distance (the blur radius, basically). Takes a bit
more memory but it means you can parallelize them pretty much how you want
(with diminishing return because the overlap zone size is
Hi,
On Fri, Jan 21, 2011 at 10:31 PM, Aurel W. aure...@gmail.com wrote:
DOF and Blur you can take care of with overlapping source tiles as long as
you know the maximum fetch distance (the blur radius, basically). Takes a
bit more memory but it means you can parallelize them pretty much how
Another solution is to execute kernels multiple times, and load/unload
tiles each time. For each iteration you only need the same region, not
a larger region.
Things start to get a little confusing now. I thought that the entire
graph or one output node can be evaluated for a single tile. At
On 01/21/2011 04:14 PM, Aurel W. wrote:
You are talking about things such as convolution with a defined kernel
size. There are other operations and a compositor truly transforms an
image to another image and not pixels to pixels etc. If it's
implemented in such a naive way, the compositor will
There are a couple of things i'd like to note, especially those not
directly related to OpenCL vs. CPU code (most arguments have been
voiced already):
* On the question whether horizontal layout (Blender nodes,
Softimage), vertical layout (Houdini, Aviary) or completely customized
layout (Nuke)
Hi Lukas,
Spaghetti vs Expressions :) : I agree with your conclusion. I really see
this as that there are to few control parameters on a node and limited
node implementations. Also currently we have different granularities of
nodes. We have very functional nodes, and very mathematically nodes
btw, you confirm that Expression PY Python Pixelizer are two different
thing right ?
by Expression PY, I meant behing able to type some python for each
parameter. (I don't have any UI design for that, but it could be something
like : right click on a param click on Set Expression a textfield
On Fri, Jan 21, 2011 at 4:49 AM, Jeroen Bakker j.bak...@atmind.nl wrote:
Hi Lukas,
Spaghetti vs Expressions :) : I agree with your conclusion. I really see
this as that there are to few control parameters on a node and limited
node implementations
It doesn't have to be a matter of spaghetti
I'd like to have 2 more questions:
Where did go the idea of integrating gegl as the library
driving compositor processing(originally 1 of durian targets?)?
Btw, gegl just released a new version 0.1.4
Will it be harder to develop nodes for the tile based system than now? will it
still be
thx for answering to my blog post via your proposal, to answer some of your
questions there :
*expression py* - only because it is User/Artist oriented. While python is
great for doing this kind of stuff and pretty popular to most people, I'm
not so sure about openCL language. by the way this is
I would just like to chime in on this proposal with my personal experience
developing in OpenCL for use in the Blender Game Engine.
As has been pointed out, not everything can be sped up with OpenCL, and
because it supports multiple device architectures, a code optimized for the
GPU won't run fast
On 01/15/2011 03:55 PM, (Ry)akiotakis (An)tonis wrote:
On 15 January 2011 09:19, Matt Ebbm...@mke3.net wrote:
While I can believe that there will be dedicated online farms set up
for this sort of thing I was more referring to farms in animation
studios, most of which are not designed around
Bullet uses its own MiniCL fallback, it requires no external references, the
main issue is that it is not a full OpenCL implementation (no barriers yet
etc). We developed MiniCL primarily for debugging and secondary to run the
Bullet OpenCL kernels on platforms that lack an OpenCL
On 01/15/2011 08:19 AM, Matt Ebb wrote:
Thanks, Jeroen.
On Sat, Jan 15, 2011 at 6:04 PM, Jeroen Bakkerj.bak...@atmind.nl wrote:
Farms
are already being migrated to OpenCL farms. As they are cheaper in
hardware costs.
BTW. renderfarm.fi should be capable of running OpenCL as this is
: [Bf-committers] Proposal: Blender OpenCL compositor
Datum: 15.1.2011 08:19:25
Thanks, Jeroen.
On Sat, Jan 15, 2011 at 6:04 PM, Jeroen Bakker j.bak...@atmind.nl wrote:
Farms
are already being migrated to OpenCL farms. As they are cheaper in
hardware
While some of the GPU based stuff nowadays looks very spectacular, I
personally still feel hesitant - I don't think CPUs (and especially
multiprocessing) should be left by the wayside. Not only due to the
increasing prevalence of multicore systems nowadays, but also for
render farms, which
Beside, OpenCL does not specially mean GPU. OpenCL can be executed by CPU
and even be accelerated by multiple CPU/Cores
2011/1/14 Knapp magick.c...@gmail.com
While some of the GPU based stuff nowadays looks very spectacular, I
personally still feel hesitant - I don't think CPUs (and
And next gen cpus are incorporating the arch from what i read
Sent from my iPhone
On Jan 14, 2011, at 8:17 AM, Xavier Thomas xavier.thomas.1...@gmail.com wrote:
Beside, OpenCL does not specially mean GPU. OpenCL can be executed by CPU
and even be accelerated by multiple CPU/Cores
2011/1/14
From a user's perspective, it seems a few node (blur, defocus, vector blur)
is responsible for over 90% of the node-compositing time in a real
production, accelerating these will probably have a far larger impact/effort
ratio than overhauling the entire framework.
also, sorry about the LinkedIn
Thanks, Jeroen.
On Sat, Jan 15, 2011 at 6:04 PM, Jeroen Bakker j.bak...@atmind.nl wrote:
Farms
are already being migrated to OpenCL farms. As they are cheaper in
hardware costs.
BTW. renderfarm.fi should be capable of running OpenCL as this is
proposal is implemented!
While I can believe
Hi,
I do think having openCL support is very cool for some nodes as I also
believe it should be build on strong foundation. And as we discussed at
several point, Blender Compositor structure is getting a bit old (Matt did
mention some of the low level issues here :
Hi all,
The last few months I have worked hard on a the proposal of the OpenCL
based compositor. Currently the proposal is ready that it is clear how
the solution should work and what the impact is. As the proposal is on
the technical level the end-user won't feel a difference, except for a
You should probably put who you are and what your qualifications are on the
donation site as well. I stumbled on the site through a twitter link
initially and had no idea who was doing the project.
-Sean
On Wed, Jan 12, 2011 at 10:07 AM, Jeroen Bakker j.bak...@atmind.nl wrote:
Hi all,
The
38 matches
Mail list logo
