|
»
»
»
CUDA benchmarking
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
Re: CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On Mon, May 19, 2008 at 1:59 PM, Evan Lezar <evanlezar@...> wrote:
> I noticed while reading the Dart docs that there is an text/html measure > type, but it seems as if this has not yet been implemented. > > I have done something slightly different - you should be able to see on some > of the later Experimental builds where I generate a table of sorts in the > CDash output. It won't be too much trouble to also have this written to a > comma separated file that can be downloaded and manipulated - afik CDash has > text files implemented at least - and as long as the required dependencies > are there using the data to generate plots as part of the test and store > them as images could also be done. Looking good so far! I suggest moving the non-CUDA timings to a separate test, though. That way, global timings are only influenced by one plugin, and can be tracked using the test time graph. Regards, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Evan Lezar
::
Rate this Message:
Ok ... I will do so
In addition, does that mean a separate test case for each of the image sizes? Thanks Evan On Mon, May 19, 2008 at 10:50 PM, Bart Janssens <bart.janssens@...> wrote:
-- visit http://randomestrandom.blogspot.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> On 5/19/08, Timothy M. Shead <tshead@...> wrote: > >> One item that came-up in my initial work on threading was a desire to >> generate charts as part of the test. I've actually been looking into >> this for awhile - there are lots of Python plotting packages out there, >> unfortunately all of them seem to come with a lot of dependencies, which >> is no good for the regression-test suite. I might gin-up something >> simple with PyCairo one of these days, since it's already a dependency >> for the installer. >> > > What about some sort of web-based generator? Here at work, someone > used JFreeChart to allow you to simply submit parameters to a URL, and > generate the chart. This introduces no dependencies in the test suite, > and we just need to store the data, not the images, assuming we can > put a link to the generator in the dashboard. > > If you like, I could set up a simple prototype, to see how it works. > Cheers, Tim ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On 5/20/08, Timothy M. Shead <tshead@...> wrote:
>> What about some sort of web-based generator? Here at work, someone >> used JFreeChart to allow you to simply submit parameters to a URL, and >> generate the chart. This introduces no dependencies in the test suite, >> and we just need to store the data, not the images, assuming we can >> put a link to the generator in the dashboard. >> >> If you like, I could set up a simple prototype, to see how it works. >> > Sure, knock yourself out ... OK! Any limitations on the architecture to use? I did some googling yesterday, and it seems the Java toolkits, like JFreeChart, produce the nicest charts. This would imply the need for a server that can serve JSP pages, however. Cheers, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On Mon, May 19, 2008 at 11:10 PM, Evan Lezar <evanlezar@...> wrote:
> Ok ... I will do so > > In addition, does that mean a separate test case for each of the image > sizes? No, I'd prefer it if different image sizes remained in the same test. It's an ideal candidate for a graph, so we can visualize the impact of the size increase. Cheers, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> On 5/20/08, Timothy M. Shead <tshead@...> wrote: > >>> What about some sort of web-based generator? Here at work, someone >>> used JFreeChart to allow you to simply submit parameters to a URL, and >>> generate the chart. This introduces no dependencies in the test suite, >>> and we just need to store the data, not the images, assuming we can >>> put a link to the generator in the dashboard. >>> >>> If you like, I could set up a simple prototype, to see how it works. >>> >>> >> Sure, knock yourself out ... >> > > OK! Any limitations on the architecture to use? I did some googling > yesterday, and it seems the Java toolkits, like JFreeChart, produce > the nicest charts. This would imply the need for a server that can > serve JSP pages, however. > CDash, so this doesn't seem very appealing. On deeper reflection, I'd really rather do it in PyCairo since that is an existing dependency, I see significant use for it in the UI, and it's useful training for (me | you | somebody else). Cheers, Tim ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Timothy M. Shead
::
Rate this Message:
Timothy M. Shead wrote:
> Bart Janssens wrote: > >> OK! Any limitations on the architecture to use? I did some googling >> yesterday, and it seems the Java toolkits, like JFreeChart, produce >> the nicest charts. This would imply the need for a server that can >> serve JSP pages, however. >> > I was damned happy to get rid of Java when we switched from Dart2 to > CDash, so this doesn't seem very appealing. > > On deeper reflection, I'd really rather do it in PyCairo since that is > an existing dependency, I see significant use for it in the UI, and it's > useful training for (me | you | somebody else). > http://code.google.com/apis/chart/ Because each chart is encoded as a URL, storage requirements on the dashboard server would be very light. The only thing we'd need is to get HTML measurements supported by CMake/CDash. Cheers, Tim ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Evan Lezar
::
Rate this Message:
Just to clarify,
Do we simply want a graphical display on the Dashboard? Then something like pyCairoChart or simply matplotlib could be used to generate the graphs - save them as images and then upload them to the dash in the same way that the image_comparison is done at the moment. These charts would not be editable, but the raw data could also be sent - either as it is at the moment (directly to the dash) or as a CSV file that is available for download. The latter may enable us to fetch the data and keep track of benchmarks results on a global scale. In terms of the google chart API - CMake/CDash doesn't support html (well ... it isn't implemented yet), it is entirely possible to generate the correct URL for the chart - although the person interested in the results would probably have to copy and paste it into their browser's address bar. I think before I spend too much time on the charting (if any :) ) I will finish the implementation of the other bitmap plugins - and then I need to include things like checking for CUDA capable devices etc. Thanks Evan On Wed, May 21, 2008 at 4:44 AM, Timothy M. Shead <tshead@...> wrote: Timothy M. Shead wrote: -- visit http://randomestrandom.blogspot.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On 5/21/08, Evan Lezar <evanlezar@...> wrote:
> I think before I spend too much time on the charting (if any :) ) I will > finish the implementation of the other bitmap plugins - and then I need to > include things like checking for CUDA capable devices etc. Agreed, focus on the numerical results for now! Perhaps we should look at the benchmarking and make some analyse them before proceeding to implement all plugins. I still think directly connecting through CUDA properties will provide an important performance boost. We could also make a benchmark comparing the performance of a chain of plugins connected directly, and a chain with intermediate device/host copies (using a CUDA <> K3D copy plugin). Regards, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Evan Lezar
::
Rate this Message:
Ok ... so the next step will be to connect multiple CUDA plugins and thereby not require as much data transfer. Tim did mention that he was concerned about transparency (like the OpenGL Painters) from a user point of view - but if we could check whether the receiving plugin was a CUDA plugin and handle things accordingly, it would be good.
How aware is a pipeline node of its dependencies? For example - if I set the input_bitmap of a BitmapAdd plugin to the output bitmap of a BitmapSubtract plugin - does the BitmapSubtract plugin know about this too? On Wed, May 21, 2008 at 9:56 AM, Bart Janssens <bart.janssens@...> wrote:
-- visit http://randomestrandom.blogspot.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On Wed, May 21, 2008 at 10:11 AM, Evan Lezar <evanlezar@...> wrote:
> Ok ... so the next step will be to connect multiple CUDA plugins and thereby > not require as much data transfer. Tim did mention that he was concerned > about transparency (like the OpenGL Painters) from a user point of view - > but if we could check whether the receiving plugin was a CUDA plugin and > handle things accordingly, it would be good. Yes, I'd not worry about that, for now. Inserting conversion nodes automatically could be handled at a higher level, i.e. the UI layer. > How aware is a pipeline node of its dependencies? For example - if I set > the input_bitmap of a BitmapAdd plugin to the output bitmap of a > BitmapSubtract plugin - does the BitmapSubtract plugin know about this too? I think the best method would be to model the CUDA bitmap modifiers after the mesh modifiers, see mesh_modifier.h This uses a local_storage property as input, and a pointer_storage as output. If these are set up correctly with the proper init and update slots, the pipeline should work transparently. The reason I suggest looking at mesh_modifier as example is because bitmap_modifier still uses the deprecated demand_storage policy, which is superseded by pointer_storage. Now, as to what to put in the input and output property. I think you will probably need to create a cuda_bitmap class, which will contain at least a pointer to device memory and size information. The properties should then contain a pointer to an instance of this class. Using pointer_storage requires that this class has a constructor without parameters. As a final note, remember that to ensure proper pipeline behavior, you must never modify the data pointed to by the input, i.e. the pointers into device memory for the input and output need to point to different data if the data is changed (using a DeviceToDevice memcopy, or by allocating a new dataset and populating that). I suggest starting off with just one plugin that is implemented this way, plus a K3DToDevice and DeviceToK3D plugin. We can then chain this example together multiple times to make a benchmark. I think you have already implemented all of the required functionality, it's just a matter of rearranging it into 3 plugins and using properties to share data between them. Hopefully that won't expose too many unforeseen problems ;) Cheers, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Timothy M. Shead
::
Rate this Message:
Evan Lezar wrote:
> Ok ... so the next step will be to connect multiple CUDA plugins and > thereby not require as much data transfer. Tim did mention that he > was concerned about transparency (like the OpenGL Painters) from a > user point of view - but if we could check whether the receiving > plugin was a CUDA plugin and handle things accordingly, it would be good. At the end of the day, there are really two interesting technical challenges to your project - the ongoing question of reducing memory transfer is one. Doing non-trivial mesh operations with the GPU is the other. Ensure that you are leaving yourself plenty of time for the latter ;) > How aware is a pipeline node of its dependencies? For example - if I > set the input_bitmap of a BitmapAdd plugin to the output bitmap of a > BitmapSubtract plugin - does the BitmapSubtract plugin know about this > too? While a node could use the API provided by k3d::ipipeline to determine the nodes that depend on it, there may be more-than-one, and no way to know who is calling. Cheers, Tim ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> I think the best method would be to model the CUDA bitmap modifiers > after the mesh modifiers, see mesh_modifier.h This uses a > local_storage property as input, and a pointer_storage as output. If > these are set up correctly with the proper init and update slots, the > pipeline should work transparently. The reason I suggest looking at > mesh_modifier as example is because bitmap_modifier still uses the > deprecated demand_storage policy, which is superseded by > pointer_storage. > > Now, as to what to put in the input and output property. I think you > will probably need to create a cuda_bitmap class, which will contain > at least a pointer to device memory and size information. The > properties should then contain a pointer to an instance of this class. > Using pointer_storage requires that this class has a constructor > without parameters. > you certain this is the best one? Is there going to be a cuda_mesh, too? Tim ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On Thu, May 22, 2008 at 8:59 AM, Timothy M. Shead <tshead@...> wrote:
> Bart Janssens wrote: >> I think the best method would be to model the CUDA bitmap modifiers >> after the mesh modifiers, see mesh_modifier.h This uses a >> local_storage property as input, and a pointer_storage as output. If >> these are set up correctly with the proper init and update slots, the >> pipeline should work transparently. The reason I suggest looking at >> mesh_modifier as example is because bitmap_modifier still uses the >> deprecated demand_storage policy, which is superseded by >> pointer_storage. >> >> Now, as to what to put in the input and output property. I think you >> will probably need to create a cuda_bitmap class, which will contain >> at least a pointer to device memory and size information. The >> properties should then contain a pointer to an instance of this class. >> Using pointer_storage requires that this class has a constructor >> without parameters. >> > All we've done at this point is enumerate some possible approaches. Are > you certain this is the best one? Is there going to be a cuda_mesh, too? I think it is. On the page, option 1 ("do nothing") currently has no con, but I think this is not correct: - CUDA docs state that host<->device transfers should be limited to the bare minimum (chapter 5 of the programming guide) - Current benchmarks show 80% of the time is spent on these transfers, on an 8800GT. This percentage will only increase as GPUs become more powerful, as typically memory bandwidth does not improve at the same rate as processor speeds. The interchangeability problem with option 2 could be solved by automatically inserting a conversion filter. However, while we discuss on how exactly that should happen, we can still use and benchmark the CUDA plugins manually. Finally, the above method should be the easiest of all options to implement, and it has no impact on the SDK. If the benchmarks confirm it is successful, the rest of the project can be based on building CUDA filters with CUDA-specific properties and the appropriate conversion plugins. All the structures that store the main data set of an operation, such as a bitmap or a mesh, should get an equivalent CUDA structure that will be used in a property to connect CUDA plugins. Regards, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
CUDA priorities [was:] CUDA benchmarking
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> On Thu, May 22, 2008 at 8:59 AM, Timothy M. Shead <tshead@...> wrote: > >> All we've done at this point is enumerate some possible approaches. Are >> you certain this is the best one? Is there going to be a cuda_mesh, too? >> > > I think it is. On the page, option 1 ("do nothing") currently has no > con, but I think this is not correct: > - CUDA docs state that host<->device transfers should be limited to > the bare minimum (chapter 5 of the programming guide) > - Current benchmarks show 80% of the time is spent on these transfers, > on an 8800GT. This percentage will only increase as GPUs become more > powerful, as typically memory bandwidth does not improve at the same > rate as processor speeds. > > The interchangeability problem with option 2 could be solved by > automatically inserting a conversion filter. However, while we discuss > on how exactly that should happen, we can still use and benchmark the > CUDA plugins manually. > > Finally, the above method should be the easiest of all options to > implement, and it has no impact on the SDK. If the benchmarks confirm > it is successful, the rest of the project can be based on building > CUDA filters with CUDA-specific properties and the appropriate > conversion plugins. All the structures that store the main data set of > an operation, such as a bitmap or a mesh, should get an equivalent > CUDA structure that will be used in a property to connect CUDA > plugins. > because it doesn't impose on either the user or the UI layer. Keep in mind that option 2 won't be completely transparent to the user (even *with* UI support), nor will documents be able to seamlessly move to a machine without the CUDA plugins. Regardless, my point is not to argue one approach over another. The wise man knows when *not* to decide, and I claim that right now is too soon. We have nothing to lose and everything to gain by increasing our experience with this new technology before making any sweeping decisions about how CUDA filters will work. Case-in-point: passing images to CUDA and creating a simple kernel is easy. Converting meshes into a data structure and doing useful work is likely to be much more challenging. Or maybe not. We just won't know until we've tried. Figuring-out what we can-and-can't do with mesh data and the GPU should be nailed-down first - that experience may inform the decision in unexpected ways. Cheers, Tim ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA priorities [was:] CUDA benchmarking
by bART Janssens-2
::
Rate this Message:
On Sat, May 24, 2008 at 8:06 AM, Timothy M. Shead <tshead@...> wrote:
> Regardless, my point is not to argue one approach over another. The > wise man knows when *not* to decide, and I claim that right now is too > soon. We have nothing to lose and everything to gain by increasing our > experience with this new technology before making any sweeping decisions > about how CUDA filters will work. Case-in-point: passing images to CUDA > and creating a simple kernel is easy. Converting meshes into a data > structure and doing useful work is likely to be much more challenging. > Or maybe not. We just won't know until we've tried. Figuring-out what > we can-and-can't do with mesh data and the GPU should be nailed-down > first - that experience may inform the decision in unexpected ways. Agreed, the next step should be to investigate mesh data. I'll write up some ideas tomorrow, due to social obligations my K-3D time is limited to Sunday this weekend. Cheers, -- Bart ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: CUDA priorities [was:] CUDA benchmarking
by Evan Lezar
::
Rate this Message:
|
