- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using code buiider 1.3.0.92 under windows 7 and VS 2010 sp1....
If I run a hack kernel like this...
__kernel void test_local()
{
__local int s_testValue[10][10];
__local int* rowStartThisThread = &(s_mcuValues[0][0]);
s_mcuValues[0][0] = 5;
}
and set a breakpoint after the setting of the 5, then the VS memory and watchlists don't see the '5' (they only see zeros), however the rowStartThisThread pointer does show it correctly. Am I making some bad assumptions here?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you mean kernel like this:
__kernel void test_local()
{
__local int s_testValue[10][10];
__local int* rowStartThisThread = &(s_testValue[0][0]);
s_testValue[0][0] = 5;
}
?
What happens if you put the barrier after assigning 5 and observe things after the barrier?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Robert, thanks for the impressively quick response! Yes sorry I changed the variable names inconsistently at the last minute before posting.
But sigh.
I put a barrier(CLK_LOCAL_MEM_FENCE) in, and, yes, it all sprang to life as I would have expected. But I then restored the code back to what it was, only to have it continue working. I really dislike heisenberg faults.....
I can't think of any unaccounted variables in play here (btw I'm only launching a single thread). Meanwhile the problem in the real part of the code continues, with or without a barrier. Very frustrating.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page