cmake --build build --target javac --target jaris correct. You may need to edit the CMakeLists.txt to point JAVA_HOME (in the CMakeLists.txt) to your JDK.
We need JAVA_HOME to point to a JDK so we can find javac, java and jar . Also ${JAVA_HOME}/include is where we find jni.h. The error.
Once you change JAVA_HOME (or anything in CMakeLists.txt)
cmake build
cmake --build build --target javac --target jarThe first line rescans the CMakeLists.txt to create the make/ninja files.
I have made a simple app for fractal music.
https://github.com/betaiotazeta/FractalMusicGenerator
It is packaged with jpackage and works well for me with Nvidia 1080. Some users are complaining that the app launches, then crashes with the following message: "child process exited with code 1" when running on AMD 6900XT or Nvidia 3080. They can run the app in a virtual machine. My understanding is that Aparapi switches to JTP automatically when something is wrong with the GPU, but for those high-end cards it doesn't seem to happen and an error occurs instead. I can't debug this issue because I don't have the hardware. How should I deal with this, by testing for something when the app starts? Should I always start in JTP and then give the option to switch to GPU? Thanks for your efforts with Aparapi, have a nice day!
https://github.com/betaiotazeta/FractalMusicGenerator
It is packaged with jpackage and works well for me with Nvidia 1080. Some users are complaining that the app launches, then crashes with the following message: "child process exited with code 1" when running on AMD 6900XT or Nvidia 3080. They can run the app in a virtual machine. My understanding is that Aparapi switches to JTP automatically when something is wrong with the GPU, but for those high-end cards it doesn't seem to happen and an error occurs instead. I can't debug this issue because I don't have the hardware. How should I deal with this, by testing for something when the app starts? Should I always start in JTP and then give the option to switch to GPU? Thanks for your efforts with Aparapi, have a nice day!
@freemo @grfrost Guys, I've found a couple o crticial issues in Aparapi. In this new version 3.0.0 the mapped methods and NoCL methods wrongly trigger an assert condition in Entrypoint.getCallTarget(...) method. Secondly, for a much greater amount of time private memory space arrays are completely broken and unusable. I'll try to provide fixes for them in the next days, if I can. Plus I would also like to add support for the integer correspondent of mad, named mad24, so that I would like to make that a mapped method. Provided there is no objections from any of you. For me it is quite useful when computing indices of 2D arrays mapped as a single array. The 24 bits limitation can also be forced on the Java side through a bit mask. What do you say?
this is an urgency fix that I am trying to bring as my work is depending on this, besides that I am without a minute of free time... almost working round the clock, to get a software ready
1 reply
Private memory arrays cannot be directly initialized from the host, and currently Aparapi sets up Kernel arguments for those, which is completely wrong. In the MRs that I will provide they will be filtered out. Plus Aparapi is currently marking private memory arrays as belonging to the constant memory space. All completely wrong. I am testing fixes for that at this moment.
@CoreRasurae sounds like some good fixes. I certainly have no objections.
I am interested in how to implement the initialization of private memory. Maybe you plan on generating init code in the generated OpenCL?
Would the Mad24 code fall back to Java ok.
I have a private copy of Aparapi native code which compiles sans warnings on modern C++/Clang/Mac + Linux. It is in a set of patches applied to mainline which I have not got around to make pull requests for. If you want them, before you start let me know.
I am interested in how to implement the initialization of private memory. Maybe you plan on generating init code in the generated OpenCL?
Would the Mad24 code fall back to Java ok.
I have a private copy of Aparapi native code which compiles sans warnings on modern C++/Clang/Mac + Linux. It is in a set of patches applied to mainline which I have not got around to make pull requests for. If you want them, before you start let me know.
@grfrost Yes, the private memory arrays can only be initialized in the OpenCL code itself, however those initializations are naturally translated from Java code by Aparapi. I have implemented and tested kernel running with private memory arrays and it didn't show up any issues. Yes, mad24 does have a Java implementation for it. I won't touch Aparapi-native for this changes, my MRs only touch the Java side.
@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