Re: CUDA benchmarking

> 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
>