aboutsummaryrefslogtreecommitdiff
path: root/result
diff options
context:
space:
mode:
authorAdrian Kummerlaender2019-06-29 23:45:47 +0200
committerAdrian Kummerlaender2019-06-29 23:45:47 +0200
commitb3acd514c5d629781e816b847aff9891015fa7bd (patch)
tree431c4630c0e8570a343b5e923cf6c266f5106f0c /result
parente3f0f2cf010ccb90bca647af88f5395794496b5f (diff)
downloadsymlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.tar
symlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.tar.gz
symlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.tar.bz2
symlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.tar.lz
symlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.tar.xz
symlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.tar.zst
symlbm_playground-b3acd514c5d629781e816b847aff9891015fa7bd.zip
Implement layout and memory padding
There are at least two distinct areas where padding can be beneficial on a GPU: 1. Padding the global thread sizes to support specific thread layouts e.g. (32,1) layouts require the global lattice width to be a multiple of 32 2. Padding the memory layout at the lowest level to align memory accesses i.e. some GPUs read memory in 128 Byte chunks and as such it is beneficial if the operations are aligned accordingly For lattice and thread layout sizes that are exponents of two these two padding areas are equivalent. However when one operates on e.g. a (300,300) lattice using a (30,1) layout, padding to 128 bytes yields a performance improvement of about 10 MLUPS on a K2200. Note that I am getting quite unsatisfied with how the Lattice class and its suroundings continue to accumulate parameters. The naming distinction between Geometry, Grid, Memory and Lattice is also not very intuitive.
Diffstat (limited to 'result')
0 files changed, 0 insertions, 0 deletions