Archives Discussions

[arsenm]

I have a kernel that worked correctly in 2.2. When I tried running it after the 2.3 update, my kernel appears to do nothing and finishes almost instantly compared to how long it should take. If I do a #define __constant __global at the top, it starts working again (although much slower than before). Did something change that would somehow break constant memory?

[arsenm]

It seems having any constant arguments now prevents anything from happening on the GPU. 

A kernel with just a printf (or anything else) doesn't run if I have any __constant kernel arguments.

[himanshu_gautam]

Please provide your system details:CPU,GPU,DRIVER,OS.

Do you find such behaviour in samples also or only in your kernel.

If so Please post the kernel too.

[arsenm]

This is only happening on the GPU. I'm using Catalyst 10.12, a Radeon 5870, and it happens on Linux x86_64 and Windows 7 x86_64 (though building as 32 bit).

There aren't really any AMD provided examples that use __constant memory from a buffer. The only one seems to be under MicroBenchmarks/ConstantBandwidth. The problem as I observe it wouldn't be evident from it; there isn't an explicit error. It's just the kernel doesn't actually run and appears to run instantly. The constant bandwidth demo doesn't doesn't really any expected output.

Also I am well below the 64k limit on constant buffers.

[arsenm]

I figured it out. It was a really bizarre problem. So I had a bunch of structs I was passing in constant buffers. I share this between some host code which doesn't use OpenCL. The last element was a function pointer used on the host, which I preprocessed out to be a void* in the kernel. The problem was the pointer size was different on the GPU, and all of the __constant elements after and including it would cause the problem. This struct was the first argument in my kernel. Making the padding the correct size makes it work. Fixing this also helped tremendously with some performance problems I've been having.

Edit: It actually didn't matter that it was a different sized pointer. Replacing the pointer with other types had the same effect; only being a pointer made it break. It also didn't actually change performance from before, and I was just testing the wrong thing.

[Rom1]

Originally posted by: arsenm ...

Edit: It actually didn't matter that it was a different sized pointer. Replacing the pointer with other types had the same effect; only being a pointer made it break. It also didn't actually change performance from before, and I was just testing the wrong thing.

We had the same problems using a pointer in a struct getting pass from host to device even in a __global mem. We had to modify a little bit our code and suppress this pointer.

OK it is better now, the pointer was a not very nice programming way...