[CL_INVALID_WORK_GROUP_SIZE]
Closed this issue · 22 comments
I downloaded the latest binary from the forum and it is throwing this error on launch.
[12/11/12 5:46:28 AM] ERROR: [CL_INVALID_WORK_GROUP_SIZE] : OpenCL Error : clEnqueueNDRangeKernel failed: local_size[0] (256) != required local_size[0] (1024) [12/11/12 5:46:28 AM] ERROR: Failed to queue kernel, error -54
This can however be fixed by the -w 256 parameter.
UPDATE: I am still getting #48 after a little while.
What hardware are you on? Because thats a driver bug. DiabloMiner, by default, uses the highest -w supported, which the driver itself reports. I've never seen any platform or hardware say 1024, virtually everything is 256 except for a few Nvidia GPUs that do 512.
I'm on a Macbook Pro 17' so it should be a AMD Radeon HD 6750M 1024 MB. (According to System Info)
I would also point out that if I do -w 512 that it says that my card only support 256 MB.
-w isn't measured in mb. Anyhow, I think you're seeing a repeat of a known bug in OSX. It says maximum local work sizes 4x bigger than the hardware actually supports. Before, it'd say 256, but require users to manually -w 64. This is detailed in the forum thread.
I can't usefully fix this in DiabloMiner, Apple is going to have to stop releasing broken drivers. So, in the mean time, just do -w 256
OK. I still get #48 though 👎
With the absolutely newest version? I'm pretty sure I just fixed #48 this morning.
Yeah. If the binaries on the forum are up to date (I'm getting errors with maven package).
Also I'm sorry I've accidentally been saying #43 for a while haha
Yeah, I figured you meant #48. Yes, whats linked to from the forums is always up to date.
BTW, since you're on OSX, you may not be able to build DiabloMiner. Launch4j still does not include 64bit OSX binaries, and even though it produces WIndows exes you still need to be able to build said Windows exes on all platforms.
Then yes. Everything is up to date.
It seems like now it is throwing #48 but it continues on and gets the occasional block through, but really after the first error you get more errors than blocks sent.
Er, whoops. That should have remained fatal.
Everything seems to work with the newest commit 😄
Well, I just committed a test case: Spurious CL_INVALID_GLOBAL_OFFSET error, offset: ######. I need the number when it happens.
So far I have no gotten an error except the occasion connection dropout. I'll update this post when it happens but I don't think it will...
... its not outputting an error because I accidentally set that testcase to output as debug instead of error, and debug isn't on by default. Derp.
Go download the new update I just pushed.
[12/12/12 6:48:03 AM] ERROR: Spurious CL_INVALID_GLOBAL_OFFSET error, offset: -360448 [12/12/12 6:48:03 AM] ERROR: Spurious CL_INVALID_GLOBAL_OFFSET error, offset: -1376256
These happened at the same time.
Fredrick, download the newest version of DM and give me those errors again.
Should I work with or without a work size?
Until Apple fixes their drivers, with. It won't effect the bug either way, though.
I'm not getting an error...
It won't stop the miner, so you have to watch for it.
I've been watching... The only errors I'm getting are read timeouts. It has gone through 121 blocks already without your error
Heh. I wonder if the error ever really existed then.
I wonder...