On Fri, May 2, 2008 at 5:43 AM, Timothy M. Shead <
tshead@...> wrote:
> Forgot to mention my skepticism on this issue earlier. When a call to
> iproperty::property_value() returns, its result must be completely
> up-to-date, otherwise the caller will fail. Thus, a CUDA plugin will
> still have to marshal data back to the host whenever the pipeline executes.
Well, if the benchmarks confirm it's worth it, I think we should have
a system whith properties that keep data on the host that would work
as follows:
- Connection between CUDA plugins: Pass data purely in device memory
- Connection to a non-CUDA pugin: copy data to host
> FWIW, I didn't really expect much of an improvement in image-processing
> speed - just like our experiments in threading, we're going to have to
> tackle larger problems before we see real improvements in performance.
I think this depends on the length of the pipeline. From what I
understand, device memory is a lot faster than host memory. For a
chain of mesh modifiers, if they are all implemented in CUDA, the mesh
data would never leave the device memory, since the result can be
dumped direcly into a VBO for OpenGL rendering. Only control data,
such as component selection and transformation matrices would have to
be transfered.
Either way, we'll have to see what the benchmarking says. If memory
transfers are only 1% of the time spent, it's not worth the trouble :)
Cheers,
--
Bart
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development