work-group / threadBlock sizes

[zjin-lcf]

Can a user simply decrease the work-group size of the kernels used in ethier ?

For example:

Decrease from 1000 to 256 for the following kernels:
cdsMassMatrixQuad2D
cdsInvMassMatrixQuad2D
cdsMassMatrixHex3D
cdsInvMassMatrixHex3D
nrsMassMatrixHex3D
nrsInvMassMatrixHex3D
nrsPressureAddQtl
nrsPressureUpdate
nrsSubCycleLSERKUpdate
nrsSubCycleERKUpdate
nrsSubCycleExt
ellipticBlockJacobiPrecon
ellipticPartialBlockJacobiPrecon
ellipticApproxBlockJacobiSolver
ellipticBlockJacobiPrecon
ellipticPartialBlockJacobiPrecon
nrsMultiExtrapolate
nrsExtrapolate

Decrease from (10,10,10) to (8,8,4) for the kernel:
nrsStrongAdvectionVolumeHex3D
nrsSubCycleStrongVolumeHex3D

Decrease from 600
nrsPressureDirichletBCHex3D

[tcew]

You might wish to look into specifying a later version of OpenCL that supports more than 256 work-items per work-group.

From libParanumal (thanks to Noel Chalmers for reminding me where this is) the first compiler flag selects the OpenCL 2.0 standard.

void platform_t::DeviceProperties(){
...
if(device.mode()=="OpenCL"){ // add backend compiler optimization for OPENCL
    props["compiler_flags"] += " -cl-std=CL2.0 ";
    props["compiler_flags"] += " -cl-strict-aliasing ";
    props["compiler_flags"] += " -cl-mad-enable ";
    props["compiler_flags"] += " -cl-no-signed-zeros ";
    props["compiler_flags"] += " -cl-unsafe-math-optimizations ";
    props["compiler_flags"] += " -cl-fast-relaxed-math ";
  }
...
}

You will need to make these properties changes before the compilation phase.

If OpenCL 2.0 is not available then this will not help.

[zjin-lcf]

AMD and Intel GPUs do not necessarily support a work-group size that is larger than 256. Thank you for your suggestions.

[tcew]

If you are using a recent gen AMD GPU I recommend switching to the OCCA:HIP backend. In the near future I anticipate that AMD HIP will robustly support >256 threads per thread-block.

[stgeke]

Here a related discussion: #89