uygn / aparapi

Automatically exported from code.google.com/p/aparapi
Other
0 stars 0 forks source link

OpenCL compile fails... sometimes? (w/ Processing) #165

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Try and run attached kernel. It's a pretty generic convolution of two images.

What is the expected output? What do you see instead?

Expected: Kernel compiles and runs. 

What happens: Without code changes, it sometimes runs just fine (even without 
the -g warning, see below), and sometimes produces this:

May 17, 2015 4:20:20 PM com.amd.aparapi.MethodModel init
WARNING: Method run()V does not contain a LocalVariableTable entry (source not 
compiled with -g) aparapi will attempt to create a synthetic table based on 
bytecode. This is experimental!!
May 17, 2015 4:20:20 PM com.amd.aparapi.KernelRunner warnFallBackAndExecute
WARNING: Reverting to Java Thread Pool (JTP) for class 
StereoMatching$GpuKernel: OpenCL compile failed
clBuildProgram failed
************************************************
:64:10: error: expected expression
         int i_4 = 0;
         ^

error: front end compiler failed build.
************************************************

What version of the product are you using? On what operating system?
Windows, using 2013_01_23 x64 version from googlecode downloads.

Please provide any additional information below.

Writing code in Processing (processing.org).

Before I was trying to use private memory, I got a "source not compiled with 
-g" warning every single time. I don't get why, the only compilation command I 
could find in the processing source has a -g in it, but I don't know much about 
the inner workings so I could be wrong.

Now that I'm trying to use the $private$ buffer, the above problem appears 
frequently, but when it doesn't, the -g warning also doesn't happen. Judging by 
the output when it does work without complaints, the private memory doesn't 
seem to be private either. I just don't get how starting the same code twice 
yields different outcomes for the OpenCL compile...

Another remark: The @PrivateMemorySpace(36) annotation won't work for me, the 
compiler complains about being unable to find that type. This probably (?) has 
something to do with the way Processing works.

Original issue reported on code.google.com by MauranKilom on 17 May 2015 at 3:07

Attachments: