Hmm, yeah I can't really do this, as while my programming may suck the
actual IP behind it isn't something I really want to put out into the
wild. Since I have very little idea what kind of increase I was going
to get from doing this I'm not sure if you doubt the amount of increase
or whether
What value are you setting with memset? OSX is a little more forgiving if you
try an set a float value - be aware that memset expects int values.
On 2013-01-14, at 5:50 AM, Stephen Newbold wrote:
> I got a quick chance to try all this over the weekend. I tried altering my
> Op to use memset
Am 14/01/2013 11:50, schrieb Stephen Newbold:
I got a quick chance to try all this over the weekend. I tried
altering my Op to use memset and contiguous memory locations and from
some very unscientific test I think I got around a 13% speed increase
from doing this, which is most pleasing. Th
I got a quick chance to try all this over the weekend. I tried altering
my Op to use memset and contiguous memory locations and from some very
unscientific test I think I got around a 13% speed increase from doing
this, which is most pleasing. This was on an OSX box though and when I
compiled
On 10/01/13 17:10, Steve Booth wrote:
Secondly, you allocate a static vector array. This won’t work in this
application because the width and height values can change after
instantiation – if the frame size is modified up-stream. You would have
to use the ‘new’ keyword to allocate it dynamically
ch is the same, is the crux of the issue
>> which was always to achieve the highest possible execution speed. It seems
>> strange to create a ‘vector’ and then access it like heap memory.
>>
>> ** **
>>
>> Steve
>>
>> ** **
>>
>> ** **
>>
&
ry.co.uk [mailto:
> nuke-dev-boun...@support.thefoundry.co.uk] *On Behalf Of *Bruno Nicoletti
> *Sent:* Thursday, January 10, 2013 8:13 AM
>
> *To:* Nuke plug-in development discussion
> *Subject:* Re: [Nuke-dev] Dynamically creating a tile
>
> ** **
>
> Som
me is 'width' by 'height' pixels, then all you
>> >> need
>> >> to do is malloc a float array, as in:
>> >>
>> >>float* frame = malloc(width * height * sizeof(float));
>> >>
>> >> To access the x't
.uk
<mailto:dev-boun...@support.thefoundry.co.uk>] *On Behalf Of *Jerry
Huxtable
*Sent:* Thursday, January 10, 2013 8:29 AM
*To:* Nuke plug-in development discussion
*Subject:* Re: [Nuke-dev] Dynamically creating a tile
One thing is that if you're compiling for debugging, the compile
; From: nuke-dev-boun...@support.thefoundry.co.uk
> [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Jerry Huxtable
> Sent: Thursday, January 10, 2013 8:29 AM
> To: Nuke plug-in development discussion
> Subject: Re: [Nuke-dev] Dynamically creating a tile
>
> One thin
...@support.thefoundry.co.uk
[mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Jerry
Huxtable
Sent: Thursday, January 10, 2013 8:29 AM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] Dynamically creating a tile
One thing is that if you're compiling for debugging, the compiler pro
ort.thefoundry.co.uk] On Behalf Of Bruno
Nicoletti
Sent: Thursday, January 10, 2013 8:13 AM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] Dynamically creating a tile
Some interesting discussion on this in topic in Stack Overflow.
http://stackoverflow.com/questions/381621
s very simple:
> >>
> >>float pixel = frame[(y * width) + x];
> >>
> >> That's the fastest way to access a frame. You can fill it in the first
> >> call
> >> to 'engine', and then pull lines out as needed in subsequent e
sequent engine
> calls.
> >>
> >> Steve
> >>
> >> -Original Message-
> >> From: nuke-dev-boun...@support.thefoundry.co.uk
> >> [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Stephen
> >> Newbold
> >>
; Steve
>>
>> -Original Message-
>> From: nuke-dev-boun...@support.thefoundry.co.uk
>> [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Stephen
>> Newbold
>> Sent: Wednesday, January 09, 2013 12:03 PM
>> To: Nuke plug-in development discuss
Steve
-Original Message-
From: nuke-dev-boun...@support.thefoundry.co.uk
[mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Stephen
Newbold
Sent: Wednesday, January 09, 2013 12:03 PM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] Dynamically creating a tile
I
Of Stephen
Newbold
Sent: Wednesday, January 09, 2013 1:15 PM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] Dynamically creating a tile
Perfect I'll try this. Excuse my novice question but do I have to do
anything to free this memory again?
Steve
Steve Booth wrote:
&g
] On Behalf Of Stephen
Newbold
Sent: Wednesday, January 09, 2013 12:03 PM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] Dynamically creating a tile
I should probably mention that the Op is accessing this vector for every
pixel, so and speed increase however little could add up.
ded in subsequent engine calls.
Steve
-Original Message-
From: nuke-dev-boun...@support.thefoundry.co.uk
[mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Stephen
Newbold
Sent: Wednesday, January 09, 2013 12:03 PM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] D
I should probably mention that the Op is accessing this vector for every
pixel, so and speed increase however little could add up.
Stephen Newbold wrote:
Is there any way of creating a tile filled with data generated within
the plugin opposed to an input? And if so, is there any benefit to
do
Is there any way of creating a tile filled with data generated within
the plugin opposed to an input? And if so, is there any benefit to
doing this? At present my Op is randomly accessing a vector<
vector > which I'm guessing isn't so fast! I was wondering
whether the same data in 'tile form
21 matches
Mail list logo
