Perfect. Thanks Jonathan. That's pretty much what I was thinking that
I needed to avoid Tile:at().
So right now I create a tile that encompasses my entire row plus the
additional surrounding pixel needed for the filtering. This is done in
the same way that it is done in the SimpleBlur.cpp example in the docs.
Now, in the docs it says this,
'Note in this example we could have created a new Tile for every pixel
rather than one big Tile up front for the whole Row.' -
http://docs.thefoundry.co.uk/nuke/63/ndkdevguide/2d/iops.html
So instead of creating one big tile per row (and using chucks of it per
pixel) I assume this means that a new Tile is created for every pixel in
the row. My question is how and when is this faster to do this, under
what conditions?
The way I was looking at doing this was to just access the out row
passed to the engine() to check each pixel value (to see if I need to do
the filtering) and therefore avoiding creating the Tile at all if not
necessary. But I assume that this is only worthwhile if I went down the
route of creating a tile per pixel rather than how I have it right now
using a tile per row. So really I'm coming back to the question of when
using a lots of smaller tiles per row is faster than the one large tile
per row as mentioned in the docs. I was hoping someone would just tell
me so I can be lazy rather than testing it out ;)
Cheers,
Steve
Jonathan Egstad wrote:
Well, you definitely don't want to use Tile::at() as that does bounds checking.
Using tile[z][y][x] is relatively fast except that it's doing the pointer
multiplies at each pixel - it's fastest to do organize the loop by channel (z)
and initialize a pointer to the start of each line (y) and iterate across
pre-incrementing the pointer.
Not sure what a tile-per-pixel means relative to a tile-per-row - got a
reference to that quote in the docs?
-jonathan
On Jun 6, 2012, at 5:00 AM, Stephen Newbold wrote:
Hi,
I have a IOP that uses a largish tile to do some filtering. I'm looking to do
some basic optimisation to speed things up by skipping doing the filtering on
any back pixel. What's the most efficient way of checking the value of the
current pixel, which is also the centre value of my tile?
My tile is the size of my entire row plus the width/height of the filter. I'm
iterating through each X value in the row, should I just directly access the
pixel from the tile with tile[z][y][x]. Or is there a more efficient way of
doing this?
Also, in the docs there is talk of maybe creating a tile per pixel is faster
than a tile per row. Is there a clear distinction for when one is faster than
the other (ie. does tile size determine this)?
Cheers,
Steve
--
Stephen Newbold
Compositing Lead - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
--
Stephen Newbold
Compositing Lead - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
