DPointNet performance and GPU setup

Start with a working example in DPointNet. Performance depends on network size, activity, batch, precision, inputs and outputs; there is no universal speedup or memory requirement.

Use automatic acceleration

For ordinary use, leave rnn_cell_params.acceleration_profile omitted or set it to "auto". The resolver selects compatible paths based on the GPU, loaded operators, precision, batch and network structure. It does not change your dynamics or lower precision to fit memory.

After building a model, inspect its choices:

rnn.build()
print(rnn.precision_report)
print(rnn.acceleration_report)

These reports explain requested/resolved settings; they do not prove that every topology-specific kernel executed. Without compatible custom operators, automatic selection retains supported TensorFlow paths. Explicit unsupported kernel requests raise rather than silently switching implementations. Explicit acceleration_profile=null disables profile expansion.

Automatic state selection checks optional event-gradient, history, voltage-penalty and type-indexed entry points individually, retaining compatible fallbacks when a loaded library lacks them. Explicit fused NEST state requests on Pascal also require the rebuilt occupancy-aware launch capability; disabling automatic selection does not bypass this safety check.

Do not copy a long list of flags from a different GPU or benchmark. For Pascal hardware, read Pascal GPU compatibility before adopting a model. A visible NVIDIA GPU alone does not establish compatibility with every TensorFlow or DPointNet execution route.

Precision and memory

The switches in DPointNet defaults and configuration migration control compute precision and state/gradient accuracy. Full voltage sequences are optional and often expensive; use compact voltage regularization when your objective permits it.

Batch size is an experimental choice, not an automatic speed setting. Some implementations have specialized batch/basis requirements; other shapes retain general paths. Measure initialization, representative activity and optimizer updates with memory headroom, not just an idle model. Changing condition layout can change the number and meaning of updates.

use_device_poisson remains false by default. Its device sampler is still Poisson, but changes seeded realizations. Treat enabling it as an input-policy change and check replay, rather than assuming it is an identical speed switch.

FP32 derivatives across time

To check weak or long-lag learning signals under mixed precision, merge this JSON fragment into a complete configuration:

{
  "run": {
    "precision": {
      "mixed_precision": true,
      "fp32_voltage_and_asc": true,
      "fp32_temporal_gradients": true
    }
  }
}

This uses FP32 derivatives across time while retaining the chosen forward precision. It is not equivalent to a full FP32 simulation and does not widen all synaptic forward state.

The supported temporal runner records projected synaptic currents so backward replay uses the original forward trajectory. Omitted/null rnn_cell_params.current_replay_mode resolves to "record" for this route. Explicit "recompute" saves that recording but repeats current projection and is approximate when GPU reductions are nondeterministic. Explicit replay modes require FP32 temporal gradients.

Recording requires approximately batch * neurons * steps * basis_count * bytes_per_current of host memory, in addition to the model. For FP16 currents, bytes_per_current=2. Chunked replay reduces per-transfer size, not this total recording. Measure host RAM, GPU memory and transfer costs on your model.

FP32 temporal gradients require selective state and a supported TemporalAdjointRunner or ExplicitStateRNN. A direct cell tape or a custom loop does not become FP32-temporal just by setting the option. Do not force FP16 packed backward kernels, nest another gradient-replay runner around it, or assume independent GPU forwards become bitwise equal. Masked, time-major, backwards, stateful and explicitly unrolled execution are unsupported by this route. Custom-runner details are in DPointNet contributor reference.

Build optional CUDA operators

Skip this section for the CPU first-run example. For custom GPU acceleration, build in the same environment used to execute BMTK. You need GPU-enabled TensorFlow, a CUDA toolkit containing nvcc and a compatible C++17 compiler. The toolkit/compiler must match TensorFlow’s build requirements; installing TensorFlow’s runtime CUDA packages alone does not supply the full build setup.

From the intended checkout:

python -c 'import bmtk; print(bmtk.__file__)'
nvcc --list-gpu-code
python -m bmtk.simulator.dpointnet.custom_ops.build

The build produces both _csr_spike_ops.so (synaptic-current operations) and _glif_state_ops.so (neuron-state operations). Inspect their .archs manifests to check which GPU architectures were included. Use the current checkout, not an unrelated installed BMTK.

For a shared installation spanning Pascal through Hopper, explicitly build a fat binary: one operator library containing code for multiple GPU architectures. This is a deployment option, not a first-run requirement:

DPOINTNET_CUDA_ARCHS="61 70 75 80 86 89 90" \
  python -m bmtk.simulator.dpointnet.custom_ops.build

Compute capability	Example hardware
6.1	GTX1080Ti / Titan Xp
7.0	V100
7.5	Quadro RTX8000
8.0	A100
8.6	RTX3090
8.9	L40S
9.0	H200

Keep targets ascending and space-separated. The final target also gets PTX, an intermediate GPU code format (PTX90 for this list). Pascal 6.1 requires an explicit target; it is not in the implicit build list. If the compiler cannot cover your intended devices, use a compatible toolchain or separate declared builds; do not silently omit a required device.

These libraries are reusable across included GPUs only with compatible TensorFlow/CUDA binary interfaces. Rebuild after CUDA source, signature or binary-interface changes. Do not replace a library in use by another process. On clusters, follow the site’s rules for compilation and compute allocations.

Warning

A successful multi-architecture build is not a test of every device. Check the actual model, inputs, precision, updates, restoration and memory on each new GPU family. Pascal automatic routing requires the repaired, capability-marked state operators described in Pascal GPU compatibility; physical multi-GPU execution is not established by the build.

Measure an improvement

Compare the same hardware, inputs, activity, precision, losses, update protocol and output mode. Exclude tracing/compilation and warm up before timing. For repeatable measurements, use at least three warmups and twenty synchronized samples, and report variation as well as a median.

Separate input generation, the model update, validation and result writing. TensorFlow allocation differs from driver memory reservations; neither is a standalone fragmentation measure. See the training callback’s memory reports. Default launchers use TensorFlow’s BFC memory allocator; importing BMTK does not override an application’s allocator environment.