CUDA Subdivide Edges (WAS Re: CUDA Bitmap Plugins complete)

[Evan Lezar]

Bart

I have gotten the subdivide edges working (or the calculate_split_points part at least).  My device mode woes were caused by the fact that I was not allocating device memory for m_edge_list and was thus dereferencing the host pointer on the device. 

I have to admit that performance isn't great (it's still quite a small part), but I am going to put in a couple more pofiler calls so that I can get an Idea of the time distribution.

Will keep you posted.

Evan

PS.  I see that you have not yet filled in the midterm survey.  Please let me know if there is a problem.  Thanks

On Thu, Jul 10, 2008 at 11:10 PM, Evan Lezar <evanlezar@...> wrote:

Thats sounds simple enough. I will give it a go. Hopefully i have
something to wow you with tomorrow!

Evan

On 7/10/08, Bart Janssens <bart.janssens@...> wrote:
> On Thu, Jul 10, 2008 at 4:39 PM, Evan Lezar <evanlezar@...> wrote:
>> Just a quick note that all the bitmap.modifier plugins have now been
>> implemented in CUDA - nothing like a more difficult problem to scare us
>> into
>> working :)
>
> Hi Evan,
>
> Abour SudivideEdges: starting off with just the split_point_calculator
> is a good idea, but you need to build on what happens in create_mesh.
> To be clear, just implementing update_mesh in CUDA requires this
> workflow:
> - copy the output mesh to a device mesh. It is already at correct
> size, everything was set up in create_mesh
> - all the input arrays for the split_point_calculator should be device
> arrays that correspond to the Input mesh. Only the points array is an
> output array, and that should come from the previously generated
> device mesh
> - The resulting mesh is the converted Output, with certain point
> positions recalculated by the split_point_calculator.
>
> Hope this helps!
>
> Cheers,
>
> --
> Bart
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> K3d-development mailing list
> K3d-development@...
> https://lists.sourceforge.net/lists/listinfo/k3d-development
>

--
Sent from Gmail for mobile | mobile.google.com

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Friday 11 July 2008 13:22:39 Evan Lezar wrote:
> I have gotten the subdivide edges working (or the calculate_split_points
> part at least).  My device mode woes were caused by the fact that I was not
> allocating device memory for m_edge_list and was thus dereferencing the
> host pointer on the device.

OK, glad to hear you got it working. Unfortunately, here it won't work,
because of the 64 <-> 32 bit incompatibility. When copying the index arrays
to the device on a 64bit platform, you need to copy the contents of
k3d::uint_t arrays to k3d::uint32_t arrays first, and then feed those to
copy_from_host_to_device.

To make this happen only on 64bit builds, #include <k3d-platform-config.h> and
then enclose the 64-to32 bit copy in an #ifdef K3D_UINT_T_64_BITS condition.

> I have to admit that performance isn't great (it's still quite a small
> part), but I am going to put in a couple more pofiler calls so that I can
> get an Idea of the time distribution.

Don't worry about the global performance too much. I think the main interest
with this plugin is to see how long each step in the algorithm takes on the
device. My guess is that after this plugin, we'll have collected enough data
to support the direct connection between CUDA nodes.

>
> PS.  I see that you have not yet filled in the midterm survey.  Please let
> me know if there is a problem.  Thanks

There's no problem, I'll fill it out this weekend!

Cheers,

Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

>> I have to admit that performance isn't great (it's still quite a small
>> part), but I am going to put in a couple more pofiler calls so that I can
>> get an Idea of the time distribution.
>>    
>
> Don't worry about the global performance too much. I think the main interest
> with this plugin is to see how long each step in the algorithm takes on the
> device. My guess is that after this plugin, we'll have collected enough data
> to support the direct connection between CUDA nodes.
>  

I'm going to restate this a little more strongly - it's an area of open
research whether / how the GPU can be of benefit for mesh operations.  
If the answer is just plain "no", that's valuable information, so I hope
you'll be open to that conclusion if it's true - that wouldn't be a
failure for your project, it would be useful advice for the team.  BTW,
the current results aren't entirely surprising to me, that's why I've
been nagging about the mesh stuff for so long ;)

Food for thought:

* Instead of transferring the complete attributes and structure of a
mesh to the GPU, is there a problem that could be computed efficiently
on the GPU using just a subset of the mesh data?
* If so, could you return the results to the CPU in a format that would
allow it to trivially incorporate them into its output?
* You might try to characterize what the above would look like, and then
we could all go in search of an existing plugin that would be a good fit.
* Important Hint: The topology of a mesh is an undirected graph.  You
could transfer it to the GPU as an adjacency matrix.

Cheers,
Tim

--
Timothy M. Shead, K-3D founder
http://www.k-3d.org



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Evan Lezar]

On Sat, Jul 12, 2008 at 5:03 PM, Timothy M. Shead <tshead@...> wrote:

Bart Janssens wrote:
>> I have to admit that performance isn't great (it's still quite a small
>> part), but I am going to put in a couple more pofiler calls so that I can
>> get an Idea of the time distribution.
>>
>
> Don't worry about the global performance too much. I think the main interest
> with this plugin is to see how long each step in the algorithm takes on the
> device. My guess is that after this plugin, we'll have collected enough data
> to support the direct connection between CUDA nodes.
>
I'm going to restate this a little more strongly - it's an area of open
research whether / how the GPU can be of benefit for mesh operations.
If the answer is just plain "no", that's valuable information, so I hope
you'll be open to that conclusion if it's true - that wouldn't be a
failure for your project, it would be useful advice for the team.  BTW,
the current results aren't entirely surprising to me, that's why I've
been nagging about the mesh stuff for so long ;)

Food for thought:

* Instead of transferring the complete attributes and structure of a
mesh to the GPU, is there a problem that could be computed efficiently
on the GPU using just a subset of the mesh data?
* If so, could you return the results to the CPU in a format that would
allow it to trivially incorporate them into its output?
* You might try to characterize what the above would look like, and then
we could all go in search of an existing plugin that would be a good fit.
* Important Hint: The topology of a mesh is an undirected graph.  You
could transfer it to the GPU as an adjacency matrix.

Cheers,
Tim

--
Timothy M. Shead, K-3D founder
http://www.k-3d.org



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

Thanks Tim

I am aware of the fact that GPGPU code is not a silver bullet and that for certain problems it just plain sucks! or at the very least, the conversion and transfer overhead make it my no means feasible.

I will think a bit on the "food" that you have provided and see what I come up with.

Evan

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development