Forgot about thisa, been busy.. i think IIRC the CI had broken.. i can take a look this week
AS long as the CI fix isnt too crazy I should have time for it
@freemo:qoto.org That would be great, as I am finalizing my application and nearing the first release. This would allow me release it against an official Aparapi release. BTW can I publish my code for the application, which will also be open source, on qoto.org?
@CoreRasurae: wonderful, i will be sure to work on it for you then... and yes you are most welcome. Anything open source for any purpose is always welcome onn qoto
@freemo:qoto.org There is one thing that is not addressed with this MR though, which I found at a later stage, which is that AMD OpenCL ICD drivers do not deal well with concurrent kernel compile and execute calls at least. I haven't had the time to map to actual OpenCL calls, however the OpenCL ICD driver can deadlock, causing the application to stall. This does not happen with NVIDIA OpenCL ICD. This happens on Windows AMD drivers. I wasn't able to test on Linux, since none of my machines with AMD GPUs have working AMD drivers on Linux. I have a simple fix for this issue, which is to synchronize Aparapi-JNI calls for kernel compile and kernel execute. I am not sure if the OpenCL spec says something about the need for the API calls to be thread safe, or not, so this may, or may not be an AMD driver bug. Still, since this issue is already happening with current AMD released Windows drivers, it may be best to protect Aparapi that way. Should I add an MR for this?
Another thing that seem to be happening is that I may have introduced a regression with compiled kernel caching in 3.0.0 that seems that Aparapi is always compiling the same kernel on the same cards, again and again, when called concurrently for the same device from different threads. I have to fix this too, its just that I am lacking the time due to still being quite involved in the PhD... final stages... big boss... :D
@marco.stefanetti_gitlab: works for me jsut fine.. but one of our load balancers had bad hardware for a few days.. was fixed ysterday
there is a mirror on github also
Hi we have micro service running in kubernetes which is listening to kafka topic. Expected to receive million of messages in a day and need to calculate expensive calculation and the results need to be updated in MSSQL. We are planning GPU node in kubernetes and planning to use aparapi. Let me know your thought on this use case and how best we can utilize the GPU so that the processing of Kafka message is near real time
Only thought that comes to mind, which you are already aware of id imagine, is you need to batch jobs, cant do them real time (one at a time) on GPU but in groups.. so you need some sort of latency calculator that decides how long its willing to wait and if the size is large enough its worth doing on a GPU but if you need ito get it out to reduce latency in the system but not ehough of a batch has accumulated you'd want to fall back to CPU
Hello everyone! I'm very new to Aparapi and I'm trying to get it to work on my Mac. I'm using NetBeans to test the GPU capabilities of Aparapi but whenever I try running my test, I keep getting an error saying that the opencl.dll/opencl.so files can't be located. It looks like this error is only relevant to Linux and Windows machines, so I'm trying to figure out how to get Aparapi to recognize/locate OpenCL, since the OpenCL framework does exist within my machine. Is there anything I'm missing? Does anyone know if there's a fix for this for Mac machines? Any help is appreciated.