Sorry for delay in response. Dnia 2011-07-29, pią o godzinie 02:15 -0400, Andreas Kloeckner pisze: > Hi Tomasz, > > On Mon, 21 Mar 2011 20:15:35 +0100, "=?UTF-8?B?VG9tYXN6IFJ5YmFr?=" > <bogom...@post.pl> wrote: > > I attach patch updating pycuda.tools.DeviceData and > > pycuda.tools.OccupancyRecord > > to take new devices into consideration. I have tried to maintain "style" of > > those classes > > and introduced changes only when necessary. I have done changes using my > > old > > notes > > and NVIDIA Occupancy Calculator. Unfortunately I currently do not have > > access to Fermi > > to test those fully. > > - self.smem_granularity = 16 > + if dev.compute_capability() >= (2,0): > + self.smem_granularity = 128 > + else: > + self.smem_granularity = 512 > > Way back in March, you submitted this patch, where smem_granularity is > documented as the number of threads taking part in a simultaneous smem > access. The new values just seem wrong. What am I missing, or rather, > what did you have in mind?
I have taken those values from CUDA_Occupancy_Calculator.xls,
from sheet "GPU Data", cells C11-H12.
Sorry for mess. It looks like I have misunderstood smem_granularity
meaning. I assumed (after xls file) that it was minimum size of shared
memory that can be allocated. It looks like that from analysis of
source code in OccupancyRecord (tools.py:294):
alloc_smem = _int_ceiling(shared_mem, devdata.smem_granularity)
If I understand it correctly, it computes amount of allocated shared
memory, rounding it to the nearest multiplication of smem_granularity.
With such assumptions, my patch makes sense - one can allocate shared
memory in block of 512 for 1.x devices, and blocks of 128 for 2.x
devices.
So I do not understand why there is difference between documentation
" .. attribute:: smem_granularity
The number of threads that participate in banked, simultaneous
access
to shared memory."
and code, which does not take threads into consideration when
dealing with smem_granularity.
Best regards.
>
> In any case, I've reverted them to 16/32 in git.
Why those values (where did you get the original 16 from)?
Regards.
--
Tomasz Rybak <bogom...@post.pl> GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
_______________________________________________ PyCUDA mailing list PyCUDA@tiker.net http://lists.tiker.net/listinfo/pycuda
