Does the size_t & uint64_t really necessary in opencl kernel.cl? about glow

[opti-mix]

OpenCL kernels should use only fixed width types in method signatures and never size_t, as its width is platform-dependent. For the time being, we should probably use uint64_t in ShapeNCHW and the like to match the OpenCL side.

[lygstate]

I suggest to add glow_size_t that can be controlled by use.
For some small model, size_t be uint32_t are enough, but for some big
model, we need uint64_t.

[nadavrot]

@lygstate The problem that we ran into was that size_t on the device did not match the size of size_t on the host.

[lygstate]

@nadavrot thats why I add a predefined macro in my request

[lygstate]

@opti-mix Does uint64_t would affect the OpenCL performance?
cause it's a really big number. For some embbed OpenCL platform.
do uint64_t arithmatic would be costy, so I would suggest the size couuld be configurable.

[opti-mix]

@lygstate get_global_id and the like return size_t according to the OpenCL specification. But size_t could be < 64bit on some OpenCL platforms.

I checked the code of kernels. We currently seem to pass integers as 32bits in signatures. But in inside function bodies we use size_t, ssize_t and inside ShapeNCHW we use 64bits. So, in principle, we could use smaller fixed-width types there.

do uint64_t arithmatic would be costy,

We currently use uint64_t only in ShapeNCHW when we pass the struct as kernel argument. Inside the kernels they are typically assigned to size_t variables.

Have you really seen any performance issues because of this?

so I would suggest the size could be configurable.

We could do this. PRs are welcome!

In any case, the fact you mentioned about the current inconsistency with regards to ShapeNHWC definitions in kernels.cl and in host's C++ is really an issue. They should be made consistent. The obvious fix would be to make the C++ definition use uint64_t for now. Once we provide a way to configure the width, we should use that configured width on both sides.

[lygstate]

I have already trying to modify the c++ code to be consistentence with opencl， but cause a lot of compiling errors， there is too much code need to modify， so I prefer modify the opencl code first， and after all， we use configured size in one step。

[pjaaskel]

#3542 this PR touches this since it changes "size_t" to a Glow-specific "dim_t" which can be fixed to 64b or 32b across Glow.