@freemo . I have some patches collected here
https://github.com/grfrost/aparapi-builder-cmake/tree/main/patches
Mostly they suppress clang warnings, some are potential access violations I found running valgrind. The main fix https://github.com/grfrost/aparapi-builder-cmake/blob/main/patches/aparapi-jni.patch allows Aparapi to build on Apple M1 (arch64) machines. Sorry I have not pushed this back to mainline. I moved away from using Maven a long time ago, This project builds from your maven repos using cmake... I know slightly weird for Java but saves me from more grey hairs.
@grfrost: we have to find a way to get it into mainline if we are going to release it partly as a legal obligation of the license if nothing else
Perhaps @CoreRasurae is willing to work with you to make the PR on your behald
*behalf
@freemo:qoto.org Sorry Jeffrey I have no time at this moment. I am just pushing this changes because they are critical bugs, that I ran across while working on my PhD. As result of my work I also expect to publish my software as open-source and as such it would be nice it was using a released version of Aparapi.
@grfrost: I wont have the time for a few weeks probably to do it myself. I'd really love to get the binary in to support the new macs but we really need to make sure it reflects the code base and is compiled from it for obvious security and legal reasons. Would you be willing to put the effort in to make the merge request?
@grfrost: the license issue is that any code distributed as open-source must link to the code present in the binary. Since our license links to our repo if the binary has new code in it it has to be in the repo to distribute it.
@grfrost: can you do that clone, path and apply it to the repo please? Its not hard, i just dont have the time right now (critical time in the company im at for next 2 weeks)
what can I do? do I have to do something on my side, or is it something with git.qoto.org?
@CoreRasurae: give me a day or two to fix it. the license had a issue but im in contact with gitlab onn it.
@freemo:qoto.org The CI stopped working again....
@CoreRasurae: i can look into the CI. did it break on its own or did you introduce breaking changes?
@freemo:qoto.org It does not do anything at all. It fails at start. There are no API breaking changes at this moment, however when using private memory arrays there is behavioral change, but it is absolutely necessary to be OpenCL compliant. I am leaving the breaking changes associated with the Kernel, Device and Range association for another MR, at a later time. I propose that we first solve this broken stuff in Aparapi 3.0.0 before doing the badly needed breaking changes for the Kernel, Device and Range association for Aparapi 4.0.0. This way we give the users an option to progress in small steps, without needing to overhaul their code bases at once, if they just need to use NoCL annotated methods or if they need Private memory arrays.
When I say being OpenCL compliant in terms o private memory arrays I mean that we have to follow OpenCL semantics for private arrays.
That introduces a behavioral change, with respect to previous Aparapi versions, except that previous versions were handling private memory arrays as constant memory space arrays and despite some kernels run and provide correct results, I am almost sure that OpenCL compiler moves those variables out of the constant memory space, back to global memory, since in many kernels those supposedly private variables have to be written to. Thus, despite some kernels will work, there is no performance gain, thus diverging from the expected.
and for sure none of them is private memory, at best it will be constant memory space.
ok let me look at whats going on and try to fix the CI in the next few days
@CoreRasurae: great, i want to bring CI back up first if possible so let me take a stab at that first
@CoreRasurae: By the way if your ever looking for remote work, likely using aparapi, let me know.
Hi @freemo:qoto.org @grfrost I found an issue with AMD OpenCL ICD, that can deadlock an application while executing threaded Aparapi applications that concurrently call OpenCL APIs. Namely when compiling a kernel while another is being executed. This does not happen with NVIDIA which has thread safe OpenCL APIs. I have a simple workaround for this that can be inserted into Aparapi. Do you want me include it in the current MR?
@freemo:qoto.org BTW Do you have an expected date for proceeding with the MR analysis?
Probably this should be reported to AMD too.
Hey @CoreRasurae regarding possible AMD runtime/driver bug. Can you reproduce using a small C++ example? My guess is that AMD will not 'go the lengths' of installing Aparapi. but if you have a C++ test case they will take a look.
I would be happy to validate too if you can produce a C++ testcase.
WRT MR I will defer to @freemo:qoto.org
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
@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
i have AMD linux and can test here.. do we have any unit tests that that trigger this issue that I can test ?
but yea i think an MR for the fix, if for no other reasont han for me to review it, might be worth while