From ce50141dde991e30dda6a039c94fffb771209a6e Mon Sep 17 00:00:00 2001 From: Mike Harsch Date: Sun, 5 Jul 2015 09:34:22 -0600 Subject: [PATCH 1/4] fix typos in parallella stdcl app note --- ...note_programming_parallella_using_stdcl.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/application_notes/programming_parallella_using_stdcl/app_note_programming_parallella_using_stdcl.md b/doc/application_notes/programming_parallella_using_stdcl/app_note_programming_parallella_using_stdcl.md index acd20a8d..2bcc2f26 100644 --- a/doc/application_notes/programming_parallella_using_stdcl/app_note_programming_parallella_using_stdcl.md +++ b/doc/application_notes/programming_parallella_using_stdcl/app_note_programming_parallella_using_stdcl.md @@ -88,7 +88,7 @@ int main() ~~~~~~~ The elements of the program are rather simple. Storage for the matrix and -vectors are allocated and initialized. The matrix-vector multiply calculation +vectors is allocated and initialized. The matrix-vector multiply calculation is performed producing the result vector, which is subsequently printed out.   @@ -104,7 +104,7 @@ important to understand that architecture matters, and Parallella is actually unique. Understanding the unique features, capabilities, and limitations is key to programming the Parallella platform. -Turning back to our matrix-vector multipl example, porting this program to use +Turning back to our matrix-vector multiply example, porting this program to use the Epiphany co-processor on Parallella introduces three basic requirements for modifying the code: @@ -194,7 +194,7 @@ device-shareable memory, float* c = (float*)clmalloc(stdacc,n*sizeof(float),0); where `stdacc` is the STDCL context for the Epiphany accelerator, the second -argument is just the size of the allocations in bytes, and he flags argument in +argument is just the size of the allocations in bytes, and the flags argument in this case can be left as 0. Next we must ensure that the memory is synchronized with the Epiphany device @@ -204,7 +204,7 @@ consistency is a basic requirement for proper operation. Although it is quite possible to create an API premised on automatic memory consistency, such approaches have not been successful thus far with accelerators, and all APIs have inevitably exposed this control to the programmer. STDCL introduces this -programming requirement directly and with clean syntax as compred to the +programming requirement directly and with clean syntax as compared to the implicit syntax found with `#pragma` mark-up APIs. Modifying our program to ensure the data is synchronized with the device memory @@ -236,7 +236,7 @@ execution are launched on the co-processor, Notice here that the kernel symbol, `matvecmult_kern`, is the name of our kernel function. Additionally, the arguments passed to the kernel are `n,aa,b,c` specified as the last arguments to the `clexec()` call. The -`clexec() call is non-blocking and therefore it is required that the host +`clexec()` call is non-blocking and therefore it is required that the host code eventually block until all device operations are completed. Next we must ensure that the device memory where the results are stored is @@ -382,7 +382,7 @@ parallelism. The basic problem with our initial port is exemplified by two related observations. First, when we defined the index range used to launch threads, -we asked for n threads executed in local workgroups of 16to match the number of +we asked for n threads executed in local workgroups of 16 to match the number of cores on the Epiphany processor. Second, when we examime our kernel code, we find that we have a very "light" kernel that perofrms a single summation over n products. @@ -394,7 +394,7 @@ for thousands of threads. Epiphany is not a GPU and this alters the fundamental Based on our architecture, we know how we would like the program to behave. Specifically, we would like to perform our parallel calculation using 16 -threads corresponding to the 16 phisial RISC array cores. Any over-threading +threads corresponding to the 16 physical RISC array cores. Any over-threading beyond this cannot bring any benefit and can only incur penalties for increased overhead. So we take this into account as a basic design strategy when porting our program to Parallella. @@ -442,7 +442,7 @@ void matvecmult_kern2( unsigned int n, float* aa, float* b, float* c ) ## Modifying the Host Code -The modifications to the host code are much simpler, and in fact our trivial. +The modifications to the host code are much simpler, and in fact are trivial. The only required change is to modify the index range over which the kernel is executed, changing this from n to 16, @@ -572,7 +572,7 @@ here consisting of only a single line of code, must be pulled out and used to create a kernel for parallel execution on the Epiphany device. The approach discussed in Section 3 in which the parallelism is matched -the phyical cores of the RISC array will be employed here from the +to the phyical cores of the RISC array will be employed here from the start. The idea is quite simple. The work of adding the elements of the data vector will be distributed as evenly as possible over the 16 phyisical cores to calculate partial sums. Subsequently the 16 partial sums will be @@ -898,7 +898,7 @@ this as an exercise. The kernel below will apply the stencil operation to a tile (approximately) 1/16th the size of the data array. The bookkeeping implements the constraint -that elements on the outer edge of the array is not calculated since the +that elements on the outer edge of the array are not calculated since the stencil leaves the update of these points ill-defined. ~~~~~~~ From 763e0bfb1f65499723e8cc18a302eff5d3b374a0 Mon Sep 17 00:00:00 2001 From: Mike Harsch Date: Mon, 6 Jul 2015 10:14:37 -0600 Subject: [PATCH 2/4] fix typos in mic build app note --- .../mic_build/app_note_mic_build.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/application_notes/mic_build/app_note_mic_build.md b/doc/application_notes/mic_build/app_note_mic_build.md index 08046877..89c659d9 100644 --- a/doc/application_notes/mic_build/app_note_mic_build.md +++ b/doc/application_notes/mic_build/app_note_mic_build.md @@ -36,7 +36,7 @@ provide a powerful code development tool. ## Configure the package -### For root installation as a priveleged admin +### For root installation as a privileged admin If you have root access, the build itself should work with all of the defaults. The target install directory will be `/usr/local/browndeer`. @@ -56,7 +56,7 @@ installed in non-standard locations, the options `--with-libelf`, `--with-libconfig`, and `--with-libevent` may be used to make adjustments. See `./configure --help` for a full listing of customizations. -### For user installation as an unpriveleged user +### For user installation as an unprivileged user If you do not have root access on the platform it is still possible to do a private "user install". The following paths are assumed to be defined: @@ -89,7 +89,7 @@ If configured for a user installation type, make install That's it. Note that `make clean` will remove files generated by the build -process and `make distclean` will restored things to their pre-configure +process and `make distclean` will restore things to their pre-configure state.   @@ -173,7 +173,7 @@ COPRTHR provides robust support for pre-cross-compiled kernels. Building the COPRTHR SDK for MIC native execution requires cross-compilation on the host using --enable-user-install configuration option. In order to support -the cross-compilation the path to the location of the required MIC libraries +the cross-compilation, the path to the location of the required MIC libraries must be specified. This should be the location where the libimf.so library built for MIC is installed on the host as part of the Intel SDK. This directory will be designated MIC_LIBS_DIR. @@ -209,7 +209,7 @@ The absence of JIT compilation support when running with MIC native execution can be mitigated using cross-compilation support for kernels provided by the COPRTHR SDK. This cross-compilation support is simply an extension of the robust support provided for a standard compilation model and workflow - -something OpenCL lack. There are two approaches - one that works now, +something OpenCL lacks. There are two approaches - one that works now, and one that will hopefully work in the near future. We will mention first what does not work and why. @@ -286,7 +286,7 @@ section below: The above modifications will cause the `libocl.so` loader to provide an application code using OpenCL a unique OpenCL platform for each server -represented the exported resources. Using the STDCL API the resources are +representing the exported resources. Using the STDCL API the resources are combined to form a single context. The result is that the application code will "see" a context, `stdnpu`, containing four (4) MIC accelerators with device numbers 0,1,2, and 3. From 67a3bf5d09126ba3cfd6f92cccb772ef55788297 Mon Sep 17 00:00:00 2001 From: Mike Harsch Date: Mon, 6 Jul 2015 13:36:51 -0600 Subject: [PATCH 3/4] fix typos in coprthr primer --- doc/coprthr_primer/coprthr_primer_clrpc.md | 20 ++++----- .../coprthr_primer_hello_stdcl.md | 8 ++-- doc/coprthr_primer/coprthr_primer_libocl.md | 2 +- doc/coprthr_primer/coprthr_primer_overview.md | 4 +- .../coprthr_primer_stdcl_examples.md | 44 +++++++++---------- doc/coprthr_primer/coprthr_primer_tests.md | 2 +- 6 files changed, 40 insertions(+), 40 deletions(-) diff --git a/doc/coprthr_primer/coprthr_primer_clrpc.md b/doc/coprthr_primer/coprthr_primer_clrpc.md index e8245106..a707de46 100644 --- a/doc/coprthr_primer/coprthr_primer_clrpc.md +++ b/doc/coprthr_primer/coprthr_primer_clrpc.md @@ -8,7 +8,7 @@ OpenCL host calls to be executed on remote platforms. By design this may require no changes at all to the host application when using the OpenCL loader provided with the COPRTHR SDK. For more complex and specialized applications, client host code can be linked directly with libclrpc and a few extensions are -provided for specifying the remote CLRPC server or servers tht the application +provided for specifying the remote CLRPC server or servers that the application should be connected to. At the present time many of the complex OpenCL semantics have been tested, @@ -23,8 +23,8 @@ by bandwidth issues. There is no magic to be found and, much like the early issues with the PCIe bus transfers dominating any theoretical performance gains from a GPU, the network latency and bandwidth must be addressed in order to successfully utilize CLRPC. Fortunately many examples of use cases can be -identified where the use of remote compute devices can be made ot perform with -an overal advantage in terms of reduced time-to-solution for the compute task +identified where the use of remote compute devices can be made to perform with +an overall advantage in terms of reduced time-to-solution for the compute task at hand. @@ -46,9 +46,9 @@ Options: : Specify the port the server should listen on. By default the server will bind to `127.0.0.1` port `2112`. -These defaults may be overiden with the command line options as shown. +These defaults may be overridden with the command line options as shown. The following example shows how to run the server such that it will listen on a -platforms external IP address to export the OpenCL platforms over a network, +host's external IP address to export the OpenCL platforms over a network, clrpcd -a 192.168.1.5 @@ -93,14 +93,14 @@ CLRPC and exposes a problem with the OpenCL approach to the concept of a "platform" that may be decribed as the vendor platform barrier. A more complete discussion of this issue is provided below along with a solution through the use of the STDCL context `stdnpu` that includes all networked -devices. The simple answer to question stated above is that one must still +devices. The simple answer to the question stated above is that one must still select a single platform, whether local or remote, based on the name of the platform, and construct an OpenCL context and get device IDs as one is normally required to do in OpenCL. If one wants to use multiple CLRPC servers this would then mean managing multiple platforms at the application level. As an alternative, the introduction of a more precise mechanism for specifying OpenCL -platforms (`ocl.conf`) to be presented to an allication using the `libocl` -loader can be used for controlling individual CLRPC server that an application +platforms (`ocl.conf`) to be presented to an application using the `libocl` +loader can be used for controlling individual CLRPC servers that an application uses. Fortunately STDCL provides a better way provided (`stdnpu`). @@ -108,13 +108,13 @@ uses. Fortunately STDCL provides a better way provided (`stdnpu`). For some specialized applications it may be desireable to link to the `libclrpc` OpenCL implementation directly and set the remote CLRPC server -connections from within a client application, by passing entirely the use of an +connections from within a client application, bypassing entirely the use of an OpenCL platform loader. For this purpose, extensions are provided for defining CLRPC server connections prior to the OpenCL call `clGetPlatformIDs()`. The following example shows the current API extension. However **please note** that these extensions are not fully developed and should be expected to be -changed in subsequented releases. The are described here only because they may +changed in subsequent releases. They are described here only because they may be of interest for early experimentation by developers. Programmers are strongly encouraged to use the method described above involving the use of `ocf.conf` files for defining connections to CLRPC servers. diff --git a/doc/coprthr_primer/coprthr_primer_hello_stdcl.md b/doc/coprthr_primer/coprthr_primer_hello_stdcl.md index af5052f6..0bc3c955 100644 --- a/doc/coprthr_primer/coprthr_primer_hello_stdcl.md +++ b/doc/coprthr_primer/coprthr_primer_hello_stdcl.md @@ -1,6 +1,6 @@ # Hello STDCL -As with most programming, its best to begin with a hello world example that +As with most programming, it's best to begin with a hello world example that captures the most important aspects of the API. This section will describe a hello STDCL program that provides everything a programmer needs to know to get started with the interface. A basic understanding of OpenCL is @@ -32,7 +32,7 @@ __kernel void matvecmult_kern( ~~~ Next, we need host-code to run on the CPU and manage the execution on the GPU. -The host code below contains everything needed to executute the above kernel. +The host code below contains everything needed to execute the above kernel. By using STDCL this program is many times smaller than what would be required to use OpenCL directly, and its also a lot simpler based on the use of better syntax and semantics. @@ -45,7 +45,7 @@ syntax and semantics. int main() { - stdcl_init(); /* requred for Windows only, Linux and FreeBSD will ignore this call */ + stdcl_init(); /* required for Windows only, Linux and FreeBSD will ignore this call */ cl_uint n = 64; @@ -125,7 +125,7 @@ New to this release is support for Fortran bindings to STDCL. Quite simply, this allows nearly all of the functionality provided by STDCL to be available to Fortran programmers, providing a simple powerful interface to OpenCL programming from Fortran applications. The example below is nearly identical to -the hello STDCL example above, except it is written in Fortran. On detail to +the hello STDCL example above, except it is written in Fortran. One detail to note is that the opaque OpenCL and STDCL types, which are merely pointers in practice, must be referenced directly and generically as C pointers since Fortran does not support type alising. diff --git a/doc/coprthr_primer/coprthr_primer_libocl.md b/doc/coprthr_primer/coprthr_primer_libocl.md index bf726bf6..f5946fbb 100644 --- a/doc/coprthr_primer/coprthr_primer_libocl.md +++ b/doc/coprthr_primer/coprthr_primer_libocl.md @@ -25,7 +25,7 @@ with the OpenCL 1.1 specification. The 'libocl' loader replaces the random enumeration of '.icd' files placed in the '/etc/OpenCL/vendors/' directory with a precise configuration file that -may be set by the system admin and then overriden by any user following +may be set by the system admin and then overridden by any user following a well-defined ordering of search paths. The following order for search paths provides for an increasingly specialized diff --git a/doc/coprthr_primer/coprthr_primer_overview.md b/doc/coprthr_primer/coprthr_primer_overview.md index f2f34cb8..610329d2 100644 --- a/doc/coprthr_primer/coprthr_primer_overview.md +++ b/doc/coprthr_primer/coprthr_primer_overview.md @@ -59,7 +59,7 @@ workflow employed by serious programmers developing serious applications. ## libclelf The ELF extensions for OpenCL (CL-ELF) are formally implemented withing the -library libclelf which is use by the offline compiler and linker to create +library libclelf which is used by the offline compiler and linker to create cross-compiled linkable object files. The dynamic loader that is provided as part of the STDCL implementation uses this same library to load the correct source or binary kernel for use within an application. @@ -70,7 +70,7 @@ The SDK includes an OpenCL loader that is backward compatible with the conventional libOpenCL ICD loader. The purpose of libocl.so, which may be aliased to libOpenCL.so, is to provide a much greater set of capabilities than what is provided with the standard loader. Among these -capabilities are more sensible system configuraton and resource management +capabilities are more sensible system configuration and resource management options, as well as the creation of custom contexts based on the hardware that is actually installed on a given system. OpenCL platform configuration issues are more reliably addressed by the user or system administrator, and not the diff --git a/doc/coprthr_primer/coprthr_primer_stdcl_examples.md b/doc/coprthr_primer/coprthr_primer_stdcl_examples.md index b87eb304..b3156fc8 100644 --- a/doc/coprthr_primer/coprthr_primer_stdcl_examples.md +++ b/doc/coprthr_primer/coprthr_primer_stdcl_examples.md @@ -15,9 +15,9 @@ those examples are now provided under the msvs2010/examples/ directory. STDCL provides different ways to manage OpenCL kernel code. The examples in clopen_example/ demonstrate the functionality. First we need some kernel code - to use, and so we will start with a simple outer product kernel with macro - defining a coefficient to included in the operation. In the kernel code below, - note that if COEF is note defined it will be set to 1. + to use, and so we will start with a simple outer product kernel with a macro + defining a coefficient to be included in the operation. In the kernel code below, + note that if COEF is not defined, it will be set to 1. ~~~ /* outerprod.cl */ @@ -43,7 +43,7 @@ file outerprod.cl is assumed to be available in the run directory for filename containing the kernel code, which it will open and compile, returning a handle to the result in a manner patterned after the Linux dynamic loader call dlopen(). The kernel program is compiled and built immediately, and a - subsequent call to clsym() returns the actual kernel object o opaque type + subsequent call to clsym() returns the actual kernel object of opaque type cl_kernel, ready to use in subsequent OpenCL calls. ~~~ @@ -116,8 +116,8 @@ int main() ~~~ In example 2, we make use of the macro COEF to modify the outer product - calculation so as to multiple the result by a fixed constant value. In order to - do this we replace the previous clopen() and clsym() calls with the code shown + calculation so as to multiply the result by a fixed constant value. In order to + do this, we replace the previous clopen() and clsym() calls with the code shown below. Notice the flag CLLD_NOBUILD. This flag tells clopen() to defer the compilation and build. Then we call clbuild() which allows us to pass in arbitrary compiler options that will be used in the compilation of the kernel @@ -188,7 +188,7 @@ clld --cl-source outerprod_three.cl which generates the file out_clld.o that contains the OpenCL kernel source embedded as an ELF object. Then this object file is linked in to the executable - just like any other object file. Its possible to see that the executable has + just like any other object file. It's possible to see that the executable has embedded OpenCL kernel code by using the command readelf to examine the added ELF sections, @@ -301,8 +301,8 @@ The host code is compiled using, gcc example_strong_binding.c outerprod.o -and the resulting executable will simple work, no management of OpenCL -programs or kernels, all of that management is eliminated. +and the resulting executable will simply work. No management of OpenCL +programs or kernels; all of that management is eliminated. ## image2d_example - Using Texture Memory for Fast Lookup Tables @@ -314,13 +314,13 @@ used to manipulate a memory allocation created by clmalloc() and is patterned after the UNIX ioctl() call insofar as it is intended to be a generic utility to avoid the proliferation of specialized calls within the STDCL interface. The use of texture memory from within OpenCL remains somewhat clumsy from an HPC -perspective, but the performance benefits it very attractive. The method for +perspective, but the performance benefits make it very attractive. The method for using texture memory with STDCL retains some of the awkward semantics of OpenCL, but introduces nothing further. The kernel code below shows the use of a simple table to create a specialized matrix-vector multiply operation. The calculation is a normal matrix-vector -multiple, however, in the summation a coefficient is introduced that depends on +multiplication, however, in the summation a coefficient is introduced that depends on the indices i and j which are used to lookup a coefficient in a 24 x 24 table stored as a read only image2d_t type memory. @@ -450,12 +450,12 @@ int main() The STDCL interface now provides run-time inter-process device management, whereby environment variables can be used to create platform behaviors for typical multi-GPU (or multi-device in general) use cases. A typical example is - assigning one GPU to each MPI process on a multi-GPU platform. It is certainly + assigning one GPU to each MPI process on a multi-GPU platform. While it is certainly possible to have the MPI processes work out for themselves who should be using a particular device on a node with multiple devices, such a solution is inelegant. STDCL provides a better way. Assume we have a platform with 2 GPUs per node and we intend to launch 2 MPI processes per node. We would like each - MPI process to have its own GPU. To achieve this simply set the environment + MPI process to have its own GPU. To achieve this, simply set the environment variables, export STDGPU_MAX_NDEV=1; @@ -476,7 +476,7 @@ The example code uses the same outerprod.cl kernel code used in the clopen_example, which will not be repeated here. The host code is shown below, wherein MPI code has been added so as to allow the outer product of two vectors two be distributed across multiple MPI processes, each performing the - calculation on a GPU provided to it exclusively. Notice that no where in the + calculation on a GPU provided to it exclusively. Notice that nowhere in the code is there an effort to determine which GPU should be used on a multi-GPU platform. For every processes, devnum=0. @@ -738,7 +738,7 @@ int main() As another example of a C++ container class using OpenCL device-sharable memory, boost::multi_array is used to create clmulti_array. This container inherits from the boost class and thus provides all of its functionality with the addition of -using device-sharable memory for OpenCL devices. in the example code, a +using device-sharable memory for OpenCL devices. In the example code, a matrix-vector multiplication is carried out on the GPU where the data structures are manipulated on the host as data structures equivalent to 1D and 2D boost multi_arrays. @@ -896,16 +896,16 @@ Notwithstanding vendor promotional material, GPU acceleration has remained programmer with no desire to exert any significant effort to rework their code. The example below combines CLETE (Compute Layer Expression Template Engine) with -the clvector contain class described above to enable GPU acceleration with +the clvector container class described above to enable GPU acceleration with virtually no effort. The single burden on the programmer is that they must include a #define prior to including the clvector.h header. By defining the macro `__CLVECTOR_FULLAUTO`, C++ magic happens of the kind that only expression-templating can achieve. In the spirit of this example, being targeted toward programmers who really do not care how one accelerates code - using a GPU, exactly how this works will not be explained here. (Its actually + using a GPU, exactly how this works will not be explained here. (It's actually quite complicated.) All that will be described is the result. When the code below is compiled, it will be automatically instrumented and when run, it will - automatically generate an OpenCL kernels and the computation inside the inner + automatically generate an OpenCL kernel and the computation inside the inner loop will be performed on the GPU, which is assumed to be available. What may at first glance appear to be a hack is actually quite robust, e.g., the expressions that can be evaluated may be of arbitrary size and contain any @@ -929,7 +929,7 @@ using namespace std; // #define __CLVECTOR_FULLAUTO to enable CLETE automatic GPU acceleration // for pure SIMD operations on clvector data objects. // -// Set the environmaent variable COPRTHR_LOG_AUTOKERN to see the automatically +// Set the environment variable COPRTHR_LOG_AUTOKERN to see the automatically // generated OpenCL kernels used to execute the computation on GPU. // // With the #define commented out standard expression-templating is used @@ -1000,7 +1000,7 @@ using namespace std; // #define __CLMULTI_ARRAY_FULLAUTO to enable CLETE automatic GPU acceleration // for pure SIMD operations on clvector data objects. // -// Set the environmaent variable COPRTHR_LOG_AUTOKERN to see the automatically +// Set the environment variable COPRTHR_LOG_AUTOKERN to see the automatically // generated OpenCL kernels used to execute the computation on GPU. // // With the #define commented out standard expression-templating is used @@ -1058,7 +1058,7 @@ int main() One nice feature of STDCL is that it provides default contexts that are ready to use by the programmer. In some cases, it might be interesting or useful to -examine exactly what is contained in a give context. The following example +examine exactly what is contained in a given context. The following example exercises some utilty routines that can be used to query a CL context for a description of what they contain. @@ -1138,7 +1138,7 @@ The COPRTHR SDK example/ directory also contains two demo applications - bdt_nbody and bdt_em3d. The N-body demo (bdt_nbody) is very similar to the BDT NBody Tutorial, however, the source code is a bit more complex since it includes an OpenCL display and the kernel is optimized for performance. The 3D - FDTD electromegnetic demo (bdt_em3d) also provides an OpenGL display. Note that + FDTD electromagnetic demo (bdt_em3d) also provides an OpenGL display. Note that due to the interaction with OpenGL, these examples sometimes have difficulty working properly. The issue is normally a problem with the installed OpenGL utility libraries. diff --git a/doc/coprthr_primer/coprthr_primer_tests.md b/doc/coprthr_primer/coprthr_primer_tests.md index 7cee1c5f..c7bb8d1b 100644 --- a/doc/coprthr_primer/coprthr_primer_tests.md +++ b/doc/coprthr_primer/coprthr_primer_tests.md @@ -8,7 +8,7 @@ operation. However, failing to pass these tests provides an immediate indication that something is wrong. There are two sets of test scripts designed to test libstdcl and libocl. The tests themselves consist of kernels and C code automatically generated by a set of PERL scripts. The full suite of tests will -execute close to 3,000 unique OpenCL kernels executions. There are two variants +execute close to 3,000 unique OpenCL kernel executions. There are two variants - the "test" and the "quicktest" - and it is highly advisable to use the quicktest unless you plan to let your machine run for an hour or so. After installation, the tests can be executed from the root COPRTHR directory by From 5831d8493789f2b6e7030052c5dc6ae81f1eadb9 Mon Sep 17 00:00:00 2001 From: Mike Harsch Date: Mon, 6 Jul 2015 13:37:45 -0600 Subject: [PATCH 4/4] fix markdown in coprthr primer tools section --- doc/coprthr_primer/coprthr_primer_tools.md | 65 +++++++++++++--------- 1 file changed, 38 insertions(+), 27 deletions(-) diff --git a/doc/coprthr_primer/coprthr_primer_tools.md b/doc/coprthr_primer/coprthr_primer_tools.md index 1038e819..b5394c76 100644 --- a/doc/coprthr_primer/coprthr_primer_tools.md +++ b/doc/coprthr_primer/coprthr_primer_tools.md @@ -101,9 +101,15 @@ Options: : Generate an object file that is linkable with clld. This is the default behavior and the flag is provided only to maintain conventional compiler - semantics.-fopenclSpecify the language dialect for compilation to be strict + semantics. + +-fopencl + : Specify the language dialect for compilation to be strict OpenCL, overriding that which is inferred from the file - extensions.-fcuda(Reserved) + extensions. + +-fcuda + : (Reserved) -fopenmp : (Reserved) @@ -115,37 +121,40 @@ Options: : Print a brief help message. --I - : Add to the include path for compilation. +-I `` + : Add `` to the include path for compilation. -mall : Include binaries for all devices supported by all available platforms. -mavail : Include binaries for only those devices available on the host - system.-mdevice=Select exclusive list of devices to include where - is a comma separated list with no spaces. Device names are vendor + system. + +-mdevice=`` + : Select exclusive list of devices to include where + `` is a comma separated list with no spaces. Device names are vendor specific. Note that the naming convention will in some cases employ device aliases, e.g., all x86_64 processors are identified with that simple tag regardless of the exact processor name. --mdevice-exclude= - : Select list of devices to exclude where is a comma separated +-mdevice-exclude=`` + : Select list of devices to exclude where `` is a comma separated list with no spaces. Device names are vendor specific. Note that the naming convention will in some cases employ device aliases, e.g., all x86_64 processors are identified with that simple tag regardless of the exact processor name. --mplatform= +-mplatform=`` : Select exclusive list of platforms to include where is a comma separated list with no spaces. --mplatform-exclude= - : Select list of platforms to exclude where is a comma separated +-mplatform-exclude=`` + : Select list of platforms to exclude where `` is a comma separated list with no spaces. --o +-o `` : Specifiy the output filename for the final ELF object file. The default naming convention for compiling a single OpenCL kernel file is the filename base with the .o extension. The default naming convention @@ -183,7 +192,7 @@ Options: source code. This prevents the kernels from being JIT compiled on target platforms and devices not included in the offline compilation. --h--help +-h --help : Print a brief help message. -mall @@ -192,28 +201,30 @@ Options: -mavail : Include binaries for only those devices available on the host system. --mdevice= - : Select exclusive list of devices to include where is a comma +-mdevice=`` + : Select exclusive list of devices to include where `` is a comma separated list with no spaces. Device names are vendor specific. Note that the naming convention will in some cases employ device aliases, e.g., all x86_64 processors are identified with that simple tag regardless of the exact processor name. --mdevice-exclude= - : Select list of devices to exclude where is a comma separated +-mdevice-exclude=`` + : Select list of devices to exclude where `` is a comma separated list with no spaces. Device names are vendor specific. Note that the naming convention will in some cases employ device aliases, e.g., all x86_64 processors are identified with that simple tag regardless of the exact processor name. --mplatform= - : Select exclusive list of platforms to include where is a +-mplatform=`` + : Select exclusive list of platforms to include where `` is a comma separated list with no spaces. --mplatform-exclude= - : Select list of platforms to exclude where is a comma - separated list with no spaces.-o Specifiy - the output filename for the final ELF object file. The default naming +-mplatform-exclude=`` + : Select list of platforms to exclude where `` is a comma + separated list with no spaces. + +-o `` + : Specify the output filename for the final ELF object file. The default naming convention for compiling a single OpenCL kernel file is the filename base with the .o extension. The default naming convention for compiling multiple OpenCL kernel files is out_clcc.o . @@ -271,11 +282,11 @@ libraries and tools provided in the SDK. cldebug [-v level] [-t tempdir] -- ./program [options ...] -v level - : set the level of reporting + : set the level of reporting -t tempdir - : set the full path to a temp directory to use for JIT compilation; - specifying this option will also prevent the temporary files from being - removed in order to allow them to be examined + : set the full path to a temp directory to use for JIT compilation; + specifying this option will also prevent the temporary files from being + removed in order to allow them to be examined