docs: added first draft of common gpu workflows in the GPU Support page

Author: lfenzo

docs/src/gpu.md

@@ -1,6 +1,6 @@
 # GPU Support
 
-NVIDIA GPU support should work out of the box on systems with CUDA and CUDNN installed. For more details see the [CUDA](https://github.com/JuliaGPU/CUDA.jl) readme.
+NVIDIA GPU support should work out of the box on systems with CUDA and CUDNN installed. For more details see the [CUDA.jl](https://github.com/JuliaGPU/CUDA.jl) readme.
 
 ## Checking GPU Availability
 
@@ -86,6 +86,64 @@ julia> x |> cpu
  0.7766742
 ```
 
+## Common GPU Workflows
+
+Some of the common workflows involving the use of GPUs are presented below.
+
+### Transferring Training Data
+
+In order to train the model using the GPU both model and the training data have be transferred to GPU memory. This process can be done with the `gpu` function in two different  ways:
+
+1. Iterating over the batches in a [DataLoader](@ref) object transfering each one of the training batches at a time to the GPU. 
+   ```julia
+   train_loader = Flux.DataLoader((xtrain, ytrain), batchsize = 64, shuffle = true)
+   # ... model, optimizer and loss definitions
+   for epoch in 1:nepochs
+       for (xtrain_batch, ytrain_batch) in train_loader
+           x, y = gpu(xtrain_batch), gpu(ytrain_batch)
+           gradients = gradient(() -> loss(x, y), parameters)
+           Flux.Optimise.update!(optimizer, parameters, gradients)
+       end
+   end
+   ```
+
+1. Transferring all training data to the GPU at once before creating the [DataLoader](@ref) object. This is usually performed for smaller datasets which are sure to fit in the available GPU memory. Some possitilities are:
+   ```julia
+   gpu_x = gpu(xtrain)
+   gpu_y = gpu(ytrain)
+
+   gpu_train_loader = Flux.DataLoader((gpu_x, gpu_y), batchsize = 32)
+   ```
+   ```julia
+   gpu_train_loader = Flux.DataLoader((xtrain |> gpu, ytrain |> gpu), batchsize = 32)
+   ```
+   ```julia
+   gpu_train_loader = Flux.DataLoader(gpu.(collect.((xtrain, ytrain))), batchsize = 32)
+   ```
+
+### Saving GPU-Trained Models
+
+After the training process is done one must always transfer the trained model back to the `cpu` memory scope before saving it to secundary memory. This can be done, as described in the previous section, with:
+```julia
+model = cpu(model) # or model = model |> cpu
+```
+and then
+```julia
+using BSON
+# ...
+BSON.@save "./path/to/trained_model.bson" model
+
+# in this approach the cpu-transferred model (referenced by the variable `model`)
+# only exists inside the `let` statement
+let model = cpu(model)
+   BSON.@save "./path/to/trained_model.bson" model
+end
+```
+The reason behind this is that models trained in the GPU but not transferred to the CPU memory scope will expect `CuArray`s as input. In other words, Flux models expect input data coming from the same kind device in which they were trained on.
+
+In controlled scenarios in which the data fed to the loaded models is garanteed to be in the GPU there's no need to transfer them back to CPU memory scope, however in production environments, where artifacts are shared among different processes, equipments or configurations, there is no garantee that the CUDA.jl package will be available for the process performing inference on the model loaded from the disk.
+
+
 ## Disabling CUDA or choosing which GPUs are visible to Flux
 
 Sometimes it is required to control which GPUs are visible to `julia` on a system with multiple GPUs or disable GPUs entirely. This can be achieved with an environment variable `CUDA_VISIBLE_DEVICES`.