hzdr / glados Goto Github PK

Is there a reason why the folder is called "include/glados"? Is "include" not sufficient or do you plan to add more folders into "include"?

GLADOS currently serves two independent purposes:

1. Providing the pipeline pattern
2. Providing a CUDA abstraction layer / C++11 style memory handling / pool allocators

There are no dependencies or interlinks between both components, it is entirely by accident that they are both part of GLADOS. From a software development point of view this bundling doesn't make a lot of sense, especially when considering the different development speeds. The pipeline pattern is (more or less) feature complete and its interface should be -- for the foreseeable future -- considered stable. The CUDA component on the other hand will likely see a lot of changes in the future as it includes only a subset of all current CUDA features and CUDA itself is evolving as well.

I'm currently considering the removal of the CUDA parts from GLADOS and putting them into a separate project. Thoughts?

The user currently has the option to set an input limit on stages. Once this limit is reached thread execution is blocked until the internal buffer has room for more objects.

There are circumstances in which this behaviour might be undesirable. ddrf should therefore offer the following three policies:

• block (default): The current behaviour. Block thread execution until there is room for another object.
• discard: If the buffer is full, discard the current object.
• overwrite: If the buffer is full, delete the oldest object and push the current object.

.. how to use the template. Add functions and their syntaxes in a way that other people can use the template without knowledge of the structure :-). Maybe the Wiki part could be perfectly suited.

... as I described in the email a few minutes ago.

As the pool allocator is not limited to CUDA it would be nice to have some 2D and 3D allocators for CPU memory.

The block sizes which are computed for 2- or 3-dimensional kernels are not multiples of 32.
e.g.: 432x500 2-dimensional threads shall be created which results in this configuration:

• Block size: (2,2) -> no multiple of 32
• Grid size: (216,250)

When invoking the kernel with a block size of (16,16) and (27, 32) the average kernel runtime is nearly 10 times faster.

This is needed for OpenCL compatibility. Unlike CUDA OpenCL returns opaque cl_mem objects instead of pointers upon allocation. In order to use the pool_allocator together with OpenCL we should return a buffer object that encapsulates the runtime memory object.

The current build system relies on Eclipse CDT's .cproject files being shared. This is a nuisance once those files are changed. We should generate those files once with CMake and otherwise ignore them.

While having each stage run in its own thread was all fun and games when working with CUDA, recent examinations have shown that this approach possibly downgrades performance when doing work on the host (with OpenMP for example). This is especially true for stages which have different workloads.

We should therefore be able to run multiple stages in the same thread of execution.

A deleter with cudaFree() is not always desirable for our CUDA smart pointers. We should add a memory pool in order to improve performance.

They still have the "ddrf" name.

This means:

• 4 spaces instead of tabs
• no more camelCaseSyntax, follow the stl_style
• be C++ Library Concepts compliant where applicable

Internal discussions revealed that we'd like to use the LGPLv3 licence for this project.