From e6bfd639b2b730aa12f6f0af226143fa7c300e0e Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Thu, 18 Jul 2024 14:18:33 +0000 Subject: [PATCH] build based on 150dc27 --- dev/functionality/device/index.html | 2 +- dev/functionality/host/index.html | 2 +- dev/index.html | 2 +- dev/interface/index.html | 2 +- dev/search/index.html | 2 +- dev/testsuite/index.html | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/dev/functionality/device/index.html b/dev/functionality/device/index.html index 6090f618..73b6f4b5 100644 --- a/dev/functionality/device/index.html +++ b/dev/functionality/device/index.html @@ -6,4 +6,4 @@ ga('create', 'UA-154489943-6', 'auto'); ga('send', 'pageview', {'page': location.pathname + location.search + location.hash}); -
Edit on GitHub
+
Edit on GitHub
diff --git a/dev/functionality/host/index.html b/dev/functionality/host/index.html index becc0224..8c5ee044 100644 --- a/dev/functionality/host/index.html +++ b/dev/functionality/host/index.html @@ -6,4 +6,4 @@ ga('create', 'UA-154489943-6', 'auto'); ga('send', 'pageview', {'page': location.pathname + location.search + location.hash}); -
Edit on GitHub
+
Edit on GitHub
diff --git a/dev/index.html b/dev/index.html index 1d775c9e..2f3b16da 100644 --- a/dev/index.html +++ b/dev/index.html @@ -6,4 +6,4 @@ ga('create', 'UA-154489943-6', 'auto'); ga('send', 'pageview', {'page': location.pathname + location.search + location.hash}); -
Edit on GitHub

GPUArrays.jl

GPUArrays is a package that provides reusable GPU array functionality for Julia's various GPU backends. Think of it as the AbstractArray interface from Base, but for GPU array types. It allows you to write generic julia code for all GPU platforms and implements common algorithms for the GPU. Like Julia Base, this includes BLAS wrapper, FFTs, maps, broadcasts and mapreduces. So when you inherit from GPUArrays and overload the interface correctly, you will get a lot of functionality for free. This will allow to have multiple GPUArray implementation for different purposes, while maximizing the ability to share code.

This package is not intended for end users! Instead, you should use one of the packages that builds on GPUArrays.jl. There is currently only a single package that actively builds on these interfaces, namely CuArrays.jl.

In this documentation, you will find more information on the interface that you are expected to implement, the functionality you gain by doing so, and the test suite that is available to verify your implementation. GPUArrays.jl also provides a reference implementation of these interfaces on the CPU: The JLArray array type uses Julia's parallel programming functionality to simulate GPU execution, and will be used throughout this documentation to illustrate functionality.

+
Edit on GitHub

GPUArrays.jl

GPUArrays is a package that provides reusable GPU array functionality for Julia's various GPU backends. Think of it as the AbstractArray interface from Base, but for GPU array types. It allows you to write generic julia code for all GPU platforms and implements common algorithms for the GPU. Like Julia Base, this includes BLAS wrapper, FFTs, maps, broadcasts and mapreduces. So when you inherit from GPUArrays and overload the interface correctly, you will get a lot of functionality for free. This will allow to have multiple GPUArray implementation for different purposes, while maximizing the ability to share code.

This package is not intended for end users! Instead, you should use one of the packages that builds on GPUArrays.jl. There is currently only a single package that actively builds on these interfaces, namely CuArrays.jl.

In this documentation, you will find more information on the interface that you are expected to implement, the functionality you gain by doing so, and the test suite that is available to verify your implementation. GPUArrays.jl also provides a reference implementation of these interfaces on the CPU: The JLArray array type uses Julia's parallel programming functionality to simulate GPU execution, and will be used throughout this documentation to illustrate functionality.

diff --git a/dev/interface/index.html b/dev/interface/index.html index a458aa42..7b71854d 100644 --- a/dev/interface/index.html +++ b/dev/interface/index.html @@ -6,4 +6,4 @@ ga('create', 'UA-154489943-6', 'auto'); ga('send', 'pageview', {'page': location.pathname + location.search + location.hash}); -
Edit on GitHub

Interface

To extend the above functionality to a new array type, you should use the types and implement the interfaces listed on this page. GPUArrays is design around having two different array types to represent a GPU array: one that only ever lives on the host, and one that actually can be instantiated on the device (i.e. in kernels).

Device functionality

Several types and interfaces are related to the device and execution of code on it. First of all, you need to provide a type that represents your execution back-end and a way to call kernels:

Missing docstring.

Missing docstring for GPUArrays.AbstractGPUBackend. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.AbstractKernelContext. Check Documenter's build log for details.

GPUArrays.gpu_call — Function
gpu_call(kernel::Function, arg0, args...; kwargs...)

Executes kernel on the device that backs arg (see backend), passing along any arguments args. Additionally, the kernel will be passed the kernel execution context (see [AbstractKernelContext]), so its signature should be (ctx::AbstractKernelContext, arg0, args...).

The keyword arguments kwargs are not passed to the function, but are interpreted on the host to influence how the kernel is executed. The following keyword arguments are supported:

  • target::AbstractArray: specify which array object to use for determining execution properties (defaults to the first argument arg0).
  • elements::Int: how many elements will be processed by this kernel. In most circumstances, this will correspond to the total number of threads that needs to be launched, unless the kernel supports a variable number of elements to process per iteration. Defaults to the length of arg0 if no other keyword arguments that influence the launch configuration are specified.
  • threads::Int and blocks::Int: configure exactly how many threads and blocks are launched. This cannot be used in combination with the elements argument.
  • name::String: inform the back end about the name of the kernel to be executed. This can be used to emit better diagnostics, and is useful with anonymous kernels.
source
Missing docstring.

Missing docstring for GPUArrays.thread_block_heuristic. Check Documenter's build log for details.

You then need to provide implementations of certain methods that will be executed on the device itself:

GPUArrays.AbstractDeviceArray — Type
AbstractDeviceArray{T, N} <: DenseArray{T, N}

Supertype for N-dimensional GPU arrays (or array-like types) with elements of type T. Instances of this type are expected to live on the device, see AbstractGPUArray for host-side objects.

source
GPUArrays.LocalMemory — Function

Creates a block local array pointer with T being the element type and N the length. Both T and N need to be static! C is a counter for approriately get the correct Local mem id in CUDAnative. This is an internal method which needs to be overloaded by the GPU Array backends

source
Missing docstring.

Missing docstring for GPUArrays.blockidx. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.blockdim. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.threadidx. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.griddim. Check Documenter's build log for details.

Host abstractions

You should provide an array type that builds on the AbstractGPUArray supertype:

Missing docstring.

Missing docstring for AbstractGPUArray. Check Documenter's build log for details.

First of all, you should implement operations that are expected to be defined for any AbstractArray type. Refer to the Julia manual for more details, or look at the JLArray reference implementation.

To be able to actually use the functionality that is defined for AbstractGPUArrays, you should provide implementations of the following interfaces:

Missing docstring.

Missing docstring for GPUArrays.backend. Check Documenter's build log for details.

+
Edit on GitHub

Interface

To extend the above functionality to a new array type, you should use the types and implement the interfaces listed on this page. GPUArrays is design around having two different array types to represent a GPU array: one that only ever lives on the host, and one that actually can be instantiated on the device (i.e. in kernels).

Device functionality

Several types and interfaces are related to the device and execution of code on it. First of all, you need to provide a type that represents your execution back-end and a way to call kernels:

Missing docstring.

Missing docstring for GPUArrays.AbstractGPUBackend. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.AbstractKernelContext. Check Documenter's build log for details.

GPUArrays.gpu_call — Function
gpu_call(kernel::Function, arg0, args...; kwargs...)

Executes kernel on the device that backs arg (see backend), passing along any arguments args. Additionally, the kernel will be passed the kernel execution context (see [AbstractKernelContext]), so its signature should be (ctx::AbstractKernelContext, arg0, args...).

The keyword arguments kwargs are not passed to the function, but are interpreted on the host to influence how the kernel is executed. The following keyword arguments are supported:

  • target::AbstractArray: specify which array object to use for determining execution properties (defaults to the first argument arg0).
  • elements::Int: how many elements will be processed by this kernel. In most circumstances, this will correspond to the total number of threads that needs to be launched, unless the kernel supports a variable number of elements to process per iteration. Defaults to the length of arg0 if no other keyword arguments that influence the launch configuration are specified.
  • threads::Int and blocks::Int: configure exactly how many threads and blocks are launched. This cannot be used in combination with the elements argument.
  • name::String: inform the back end about the name of the kernel to be executed. This can be used to emit better diagnostics, and is useful with anonymous kernels.
source
Missing docstring.

Missing docstring for GPUArrays.thread_block_heuristic. Check Documenter's build log for details.

You then need to provide implementations of certain methods that will be executed on the device itself:

GPUArrays.AbstractDeviceArray — Type
AbstractDeviceArray{T, N} <: DenseArray{T, N}

Supertype for N-dimensional GPU arrays (or array-like types) with elements of type T. Instances of this type are expected to live on the device, see AbstractGPUArray for host-side objects.

source
GPUArrays.LocalMemory — Function

Creates a block local array pointer with T being the element type and N the length. Both T and N need to be static! C is a counter for approriately get the correct Local mem id in CUDAnative. This is an internal method which needs to be overloaded by the GPU Array backends

source
Missing docstring.

Missing docstring for GPUArrays.blockidx. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.blockdim. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.threadidx. Check Documenter's build log for details.

Missing docstring.

Missing docstring for GPUArrays.griddim. Check Documenter's build log for details.

Host abstractions

You should provide an array type that builds on the AbstractGPUArray supertype:

Missing docstring.

Missing docstring for AbstractGPUArray. Check Documenter's build log for details.

First of all, you should implement operations that are expected to be defined for any AbstractArray type. Refer to the Julia manual for more details, or look at the JLArray reference implementation.

To be able to actually use the functionality that is defined for AbstractGPUArrays, you should provide implementations of the following interfaces:

Missing docstring.

Missing docstring for GPUArrays.backend. Check Documenter's build log for details.

diff --git a/dev/search/index.html b/dev/search/index.html index b6b4c249..43cdada9 100644 --- a/dev/search/index.html +++ b/dev/search/index.html @@ -6,4 +6,4 @@ ga('create', 'UA-154489943-6', 'auto'); ga('send', 'pageview', {'page': location.pathname + location.search + location.hash}); -

Loading search...

    +

    Loading search...

      diff --git a/dev/testsuite/index.html b/dev/testsuite/index.html index 4a330086..5c3301f7 100644 --- a/dev/testsuite/index.html +++ b/dev/testsuite/index.html @@ -21,4 +21,4 @@ TestSuite.test_mapreduce(T) # mapreduce sum, etc TestSuite.test_indexing(T) # indexing tests TestSuite.test_random(T) # randomly constructed arrays -TestSuite.test_io(T) +TestSuite.test_io(T)