AutoDock-GPU: AutoDock4 docking moved onto OpenCL, CUDA and SYCL

AutoDock4.2.6 with the genetic algorithm parallelised

AutoDock-GPU is developed by the Forli lab at Scripps Research and is described in the README as an OpenCL and Cuda accelerated version of AutoDock4.2.6. The acceleration is not a rewrite of the search. It keeps AutoDock4's Lamarckian Genetic Algorithm and exploits the fact that the LGA is embarrassingly parallelisable, processing ligand-receptor poses in parallel across multiple compute units. The search itself also changed in a way that matters for comparing results with the original tool. Alongside the gradient-based local search methods, for example ADADELTA, the project includes an improved version of Solis-Wets from AutoDock 4. The OpenCL implementation was developed with TU-Darmstadt and can target CPU, GPU and FPGA architectures, and the CUDA implementation was developed with Nvidia for the Summit system at Oak Ridge National Laboratory, including a batched ligand pipeline from Jubilee Development. The README reports observed speedups of up to 4x on a quad-core CPU and 56x on GPU over the original serial AutoDock 4.2 Solis-Wets on CPU.

DEVICE=GPU probes for CUDA and quietly falls back to OpenCL

The build is driven by a single make variable and the Makefile logic is worth reading before you trust your binary. When DEVICE=GPU is chosen, the Makefile tests whether CUDA can compile successfully, and if that test fails it prints that CUDA is not available and switches to OpenCL. You can force the choice with DEVICE=CUDA or DEVICE=OCLGPU, and the CPU target is only supported through OpenCL. The Makefile in the repository spells out the conditions for the automatic CUDA detection, which require nvcc to exist, GPU_INCLUDE_PATH and GPU_LIBRARY_PATH to be set, and a test program including cuda_runtime_api.h to compile and link against cuda and cudart. The subtlety is the failure mode. A build that lands on the OpenCL path still produces a working binary, though the Makefile does print a notice, so the acceleration you get may not be the one you asked for. The Makefile also distinguishes two CUDA compute capability floors, MIN_COMPUTE of 50 normally and 80 when TENSOR is turned on, which decides which GPU architectures the compiled kernels will target.

NUMWI names the binary and sizes the work-group

The second build variable is NUMWI, the work-group or thread block size, and the acceptable values are 1, 2, 4, 8, 16, 32, 64, 128 and 256. The compiled binary encodes both choices in its name, autodock_<type>_<N>wi, and is placed under the bin directory, so a build directory can hold several tuned binaries side by side and you can compare them on the same workload. The README is direct about how to choose. The best work-group size depends on the GPU and the workload, and the suggestion for modern cards with the example workloads is NUMWI=128 or NUMWI=64, while on macOS you should use NUMWI=1 for CPUs. That last point is not a general rule so much as a consequence of how the OpenCL runtime on Apple hardware behaves. The Makefile also defaults OVERLAP to ON, which compiles an OpenMP-enabled overlapped pipeline for setup and processing, so the host and device work overlap instead of running in sequence.

A C++17 compiler and a CUDA 11 floor

Compilation has prerequisites that the README states directly. Since commit 846dc2b, AutoDock-GPU requires a C++17-capable compiler, which in practice means GCC 9 or newer. The same change means the minimum CUDA version supported for compilation is CUDA 11. Because every CUDA version ships an OpenCL implementation as well, older CUDA installations can still work by using the OpenCL code path with DEVICE=OCLGPU. That fallback is what keeps a large installed base usable, and it is also why the setup table lists a CPU column with the Intel SDK for OpenCL 2017 and a GPU column with OpenCL or CUDA 11 and above. The environment variables GPU_INCLUDE_PATH and GPU_LIBRARY_PATH must be set before compiling, following the guidance in the project wiki that the README links to. The supported table itself is dated, listing CentOS 6.7 and 6.8, Ubuntu 14.04 and 16.04 and macOS Catalina 10.15.1, and the README says other environments or configurations likely work as well but are untested.

Docking runs take a maps file, a ligand and a run count

The host binary takes the usual AutoDock style inputs. A basic invocation names the protein grid maps with --ffile, the ligand with --lfile, and the number of runs with --nrun:

./bin/autodock_<type>_<N>wi \
  --ffile <protein>.maps.fld \
  --lfile <ligand>.pdbqt \
  --nrun <nruns>

Both file options are mandatory, and both can instead be supplied through a batch file given with --filelist or through an AD4 dpf file with --import_dpf, though the README marks the dpf import as only partially supported. The documented example uses the 64 work-group build with the shipped sample input:

./bin/autodock_gpu_64wi \
  --ffile ./input/1stp/derived/1stp_protein.maps.fld \
  --lfile ./input/1stp/derived/1stp_ligand.pdbqt

By default the output log is written to the current working directory, with example logs in the examples/output folder. The supported argument table is broad and includes flexible residue files, xray reference ligand files for RMSD analysis, xml to dlg conversion, contact analysis, and output controls for xml, dlg and stdout. A batched ligand pipeline is available in both the OpenCL and CUDA builds, which is the feature that turns the tool into a screening engine for many ligands against one receptor.

A SYCL path for recent Intel GPUs is still in development

Three backends exist and they are not equally finished. OpenCL and CUDA are the shipped, supported paths in this repository. A SYCL version that also supports recent Intel GPUs is under development as a joint work of TUDa and Intel, and the README links to a separate repository for it, so a SYCL build is not something you obtain from this tree. The distinction matters for planning, because SYCL is often presented as the portable future of the project while the code you can compile today is OpenCL and CUDA. The repository layout reflects that split into separate source trees, with common, cuda, device, host, wrapcl and wmma_extension directories, separate Makefile.Cuda and Makefile.OpenCL files, and a Visual Studio project for Windows. The Windows project files and the AutoDock-GPU.sln sit at the top level next to the Unix Makefiles, so the same codebase is meant to be built from either toolchain, and the python directory suggests scripting support alongside the compiled binaries.

GPL-2.0 with a major release in 2024

The licence is GPL-2.0, with a LICENSE_LGPL file also present in the repository for parts that carry the more permissive terms, and there are scripts in the tree for adding or removing the license preamble in source files. For commercial users this is the first thing to read, because GPL obligations on distributed derivatives do not disappear because the binaries are free, and the mixture of GPL and LGPL files means you need to know which parts you are shipping. On the release side, the project published v1.6 as a major release on 2024-11-19, before that v1.5.3 with Apple M1 fixes and the Boron atom type on 2021-12-17 and v1.5.2 on 2021-09-17. The repository is not archived and the last push was on 2026-08-11, which is more recent than the newest tag. That gap tells you the develop branch is moving without tagged releases, so if you are pinning a version for a production screening campaign you should record the commit you built rather than rely on the tag list.

Editorial conclusion

Adopt AutoDock-GPU if you run AutoDock4 style docking or virtual screening and want the same algorithm on a GPU or a CPU accelerator, and confirm your compiler is GCC 9 or newer before you start. Do not expect a SYCL path yet, since that version is still under development, and check whether DEVICE=GPU detected CUDA or silently fell back to OpenCL in your build.

Frequently asked questions

Official sources

1. ccsb-scripps/AutoDock-GPU on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases