Official releases

[blueberry]

Since CLBlast 0.7.0 is out, maybe we can prepare the release 0.7.0 of JOCLBlast (and also RC01 of JOCL)? We have people that can build for all 3 major operating systems...

[gpu]

Sounds like a plan. I have some (time and technical) constraints this week, but I should be able to

• create a tag for JOCL-2.0.0-RC01 and
• (check if there are relevant changes in CLBlast and) create a tag for JOCLBlast-0.7.0-RC01

These tags could then be used to build

• the JOCL natives
• the CLBlast natives (for 0.7.0) (!)
• the JOCLBlast natives

so that, if everything works out as expected, both can be released to Maven Central next week

[blueberry]

Cool. As for JOCLBlast, I vote to go straight to 0.7.0, since:

1. CLBlast is itself beta, and 0.7.0 has already been released
2. We have the minor version number for eventual fixes
3. Currently there is a handful of users anyway, and CLBlast itself will have new versions every month or two.

I propose to:

1. Create JOCLBlast 0.7.0-SNAPSHOT (or RC)
2. We build CLBlast 0.7.0 for each OS, and test the latest JOCLBlast snapshot with our libraries/tests/apps (I guess this will work, since there weren't many changes since the last batch of issues)
3. If everything is OK, you release 0.7.0 final with the same CLBlast binaries that we used to test the snapshot (RC)?

[gpu]

OK, a first attempt:

• JOCL 2.0.0 release candiate tag: https://github.com/gpu/JOCL/releases/tag/2.0.0-RC00
• JOCLBlast 0.7.0 release candiate tag: https://github.com/gpu/JOCLBlast/releases/tag/0.7.0-RC00

The versions in the POMs are now "...0-SNAPSHOT", as this is the usual maven convention. The tags are both called "RC00".

I hope that the MVN install of JOCLBlast works as desired: I had to extend the POM a bit to specify the native library location of the CLBlast library for the unit tests.

(Again, I have some constraints this week, but have already built the CLBlast and JOCLBlast natives for Windows, x86 and x86_64. When the Linux x86 and x86_64 and the MacOS ones are available, I can (fingers crossed) publish both to Maven Central)

[blueberry]

@gpu @amherag Here are osx and linux builds for JOCL and JOCL blast: linux-dragan.zip osx-amaury.zip

[gpu]

Thanks @amherag and @blueberry !

@blueberry Could you also compile them for 32 bit? That would be great, as it is the "only" library that is missing now.

[blueberry]

As far as I know no, because I don't have a 32 bit system. If it can be done on the 64 bit system then yes, but I'd need smeone to point me to the information on how to do that.

Is 32 bit still a thing? I understand why someone woud need that on windows, but I haven't seen a 32 bit desktop linux for a looong time.

[gpu]

For Windows, the compiler toolchain can explicitly be selected in CMake ("Visual Studio..." vs "Visual Studio Win64"). For Linux, it should be possible as well, according to http://stackoverflow.com/questions/1272357/how-to-compile-a-32-bit-binary-on-a-64-bit-linux-machine-with-gcc-cmake . However, if you think that it is not worth the effort (I'm not sure how prevalent 32bit Linuxes still are...) then I'd try to assemble 2.0.0 tomorrow.

[blueberry]

I had looked at that page before, but on linux there are many more variables outside the project, starting with the dependent libraries.

I'd go with what we have since: 1) clblast is going to be released often, so there will be opportunities for adding new platforms and architectures soon. 2) there is a number of users who are eager to use linux/mac/windows 64bit libraries as soon as possible. 3) if someone who needs linux 32bit appears - great! he will have the needed 32bit system and we can help him build the binaries and fill that gap!

[gpu]

OK then, I'll try to build the package tomorrow (unfortunately, I'm not entirely sure whether this will be possible, but in any case, I'll do it ASAP)

[blueberry]

Thank you.

[gpu]

So after a bit of a hassle and back and forth *, JOCL and JOCLBlast should soon be available in Maven Central as

<dependency>
    <groupId>org.jocl</groupId>
    <artifactId>jocl</artifactId>
    <version>2.0.0</version>
</dependency>

and

<dependency>
    <groupId>org.jocl</groupId>
    <artifactId>jocl-blast</artifactId>
    <version>0.7.0</version>
</dependency>

respectively.

---

* Having several GitHub- and Sonatype-accounts always makes this a bit fiddly. I still think it's a nuisance that Maven performs the POM update and SCM tagging before it notices that it can not upload anything to the staging server. Once more, I had to delete tags and roll back the GitHub history to fix this...

And now, preparing everything for 2.0.1 and 0.7.1, because I'm pretty sure that something will have gone wrong with this release nevertheless ;-)

[gpu]

It turned out that for (JO)CLBlast, users may have to download and install https://www.microsoft.com/en-us/download/confirmation.aspx?id=48145 , because the runtime libraries are linked dynamically by default (c.f. https://github.com/CNugteren/CLBlast/issues/59 ). Apart from that, after a quick test on a different PC, it basically seemed to work - at least, on Windows.

[blueberry]

@gpu @amherag Cedric have just released CLBlast 0.7.1 that solves the Windows runtime issue, and also two very important AMD performance issuse.

@gpu, can you please prepare 0.7.1, so @amherag and I can build OS X and Linux version? As soon as JOCLBlast 0.7.1 is in the maven central, I am going to release Neanderthal.

[gpu]

I'll try to do this ASAP (not sure whether I can do it today - hopefully tomorrow, but can not promise it)

[gpu]

@blueberry @amherag A tag https://github.com/gpu/JOCLBlast/releases/tag/0.7.1-RC00 has been created for version 0.7.1, which may be used to build the binaries.

[amherag]

Got it. I'll build the OS X binaries today.

[blueberry]

I'll probably do it tomorrow.

[blueberry]

@gpu jocl-blast-0.7.1-linux.zip

[amherag]

@gpu jocl-blast-0.7.1-apple.zip

Sorry for the delay.

[gpu]

Thanks @blueberry and @amherag I'll pack it together ASAP (maybe today, more likely tomorrow).

[gpu]

JOCLBlast 0.7.1 has been released and will soon be available in Maven central as

<dependency>
    <groupId>org.jocl</groupId>
    <artifactId>jocl-blast</artifactId>
    <version>0.7.1</version>
</dependency>

[blueberry]

@gpu I just want to notify you that CLBlast 0.8.0 is out, so we can prepare the releases that fix the OS X bug https://github.com/uncomplicate/neanderthal/issues/15.

It will require JOCL code generation, since there are new functions in CLBlast.

[gpu]

Thanks for this pointer. Unfotunately, I'll hardly be able to do it this week, but will try to schedule it ASAP (likely Monday).

[blueberry]

Thank you. Monday is perfectly fine. I'll include a pointer for @amherag so he can expect it.

[gpu]

I managed to allocate some time today, and updated it, in https://github.com/gpu/JOCLBlast/releases/tag/0.8.0-RC00

There haven't been many new functions, except for the (non-BLAS) omatcopy ones, and the ones that operate on cl_half. Since this data type is not supported in Java at all, I now omitted these.

[blueberry]

@gpu @amherag Here is the linux build. Please note that you forgot to update the version in Maven pom - I updated that to 0.8.0-SNAPSHOT, but it should not affect native binaries that are relevant here (their version is OK). jocl-blast-0.8.0-SNAPSHOT.zip

[amherag]

@gpu @blueberry And here is the mac build.

jocl-blast-0.8.0-SNAPSHOT.jar.zip

When I issued mvn clean install on JOCLBlast 0.8.0, the jar was named as version 0.7.2. (Oh, nevermind, I just read @blueberry post before mine. I'll rename it to 0.8.0-SNAPSHOT too).

Sorry for the delay, although I'm already on vacation, I've been very busy.

[blueberry]

Thank you, Amaury.

[gpu]

Thanks @blueberry and @amherag for the contribution!

(The version number in the POM: Indeed, I created this tag (which was only intended for the binaries) before updating the maven build part - but it would indeed have been better to update the version number in the POM as well)

The new version should be available in Maven Central soon, at

<dependency>
    <groupId>org.jocl</groupId>
    <artifactId>jocl-blast</artifactId>
    <version>0.8.0</version>
</dependency>

Hopefully, this will also resolve https://github.com/uncomplicate/neanderthal/issues/15

[blueberry]

@gpu @amherag Hi guys. CLBlast has just released new version 0.9.0. https://github.com/CNugteren/CLBlast/pull/99 Marco, please let us know when you have some time to prepare the release, so we can plan in advance and set up some time to do the osx and linux build. I personally am not in a hurry, but it would be nice if we can keep up with Cedric's fantastic work on this.

[gpu]

Thanks for this ping. Right now, I have minor other tasks and strict deadlines in the next few days, but should be able to tackle the update next tuesday (and then, it should not take so long). I'll ping you when the update is committed.

[gpu]

I just had a look at the new version, and it seems that there are no new functions. (Maybe I overlooked something...?)

Then I'd just tag the current version of JOCLBlast, and the new version could just be built based on the current source code state, but linked against the new version of CLBlast.

Is this OK for you?

[CNugteren]

Yes, there are no new functions indeed. Just performance improvements and bugfixes.

[gpu]

Thanks for confirming. So the tag to build the libraries against is https://github.com/gpu/JOCLBlast/releases/tag/0.9.0-RC00

[blueberry]

@gpu I wanted to build the library today, but it seems it has not been updated since 6th July (or 16th July for the zip file). Shouldn't at least version number be bumped up?

[gpu]

Apologies. This was embarassingly stupid. I have deleted the draft-RC-tag, will create the updated one, and drop a note here ASAP. (Likely on monday, most likely not later than wednesday)

[blueberry]

@gpu Luckily, your projects are so useful, that you can afford as much simple oversights as you like, you still kick ass! :)

[gpu]

Sorry for the delay here. I prepared everything, and cleanly rebuilt everything locally, and it seemed to work. But during one test, I encountered a very strange error with event handling:

• An event object is passed to CLBlastSgemm, to be filled there
• It is filled properly. In the native CLBlast sample, everything works. Even hackily inserting a clWaitForEvents with this event in the JNI call around the CLBlastSgemm function works.
• The event is properly returned to Java (it really is the event obtained from CLBlastSgemm)
• The event is passed to clWaitForEvents, and it arrives there properly. Still exactly the same event object as generated by CLBlastSgemm
• The native clWaitForEvents crashes with an access violoation in the OpenCL DLL

This already is strange enough, but ...

• Events that are created in the other pure JOCL samples work. All of them.
• The same program works with (JO)CLBlast 0.8.0, but not with 0.9.0

All this is really odd. In the unlikely case that someone has an idea, I'd be glad to hear it. Otherwise, I'll continue trying to figure out what might cause this behavior...

[blueberry]

Are you sure that the event is not incidentally released somewhere? Are there many changes in CLBlast code related to that, or the occurrence is completely mysterious? If you can share the exact prepared project that just needs to be built/run, I can try running it on linux with AMD drivers and see how it goes there.

Does 0.8.0 work now, or it only worked a couple months ago when you built 0.8.0? If only the latter, maybe the update in the drivers introduced something?

And, I would still try to restart Windows and try again with the clean slate! You never know... :)

[gpu]

Thanks for your input. I found the culprit, and it was me, of course: There was a missing pointer dereference in the JOCLCommon utility functions. My initial debugging attempts have been useless in this sense, because I always compared the pointer values, and not the pointed-to event objects.

you can afford as much simple oversights as you like

At some point, things become questionable nevertheless. I'll have to take measures to prevent this from happening again.

The "update 1" of the tag for the 0.9.0 version is now at https://github.com/gpu/JOCLBlast/releases/tag/0.9.0-RC01 .

I have also added a tag in the JOCLCommon project, https://github.com/gpu/JOCLCommon/tree/jocl-blast-0.9.0-RC01 - I think it's a good idea to have something like this, so that one knows the state of the JOCLCommon project that one JOCL library was built with.

[CNugteren]

(I was just about to write a comment, but good to hear that you've fixed it)

Things did change regarding events in the latest CLBlast. See https://github.com/CNugteren/CLBlast/issues/74#issuecomment-230104247 and the change-log:

Fixed memory leaks related to events not being released

[blueberry]

@gpu just to clarify, JOCLCommon also changed and needs to be rebuilt to build JOCLBlast?

[gpu]

@CNugteren Yes, I had noticed that in https://github.com/CNugteren/CLBlast/commit/7cf2f8c26882aee4cd3e95fe22967f04318b6bf7#diff-48d386b2900ad3210bb7dd2c72a0fb11 a new clReleaseEvent appeared, and thought that blueberry might be right with his guess about the event erroneously being released there. But it seems to be a different event, and more importantly, the original sample worked properly - so it basically had to be an error on my side.

@blueberry : JOCLCommon has to be updated (git pull). It is supposed to reside in a sibling directory of JOCLBlast

root\
    JOCLCommon\
    JOCLBlast\

and from there, it is picked up automatically. So no dedicated build steps are necessary for building it. It will automatically be compiled when building the JOCLBlast library.

[amherag]

@gpu @blueberry 0.9.0 Mac build done ;)

jocl-blast-0.9.0-SNAPSHOT.jar.zip

[gpu]

Thanks @amherag . Was this built with the matching/latest version of JOCLCommon? (The regression unit test for the event bug will be added ASAP)

[blueberry]

@gpu here is the linux build (I used new JOCLCommon, at least I hope I do :)

jocl-blast-0.9.0-SNAPSHOT.zip

[gpu]

Thanks @blueberry !

One test would be the sample from https://forum.byte-welt.net/byte-welt-projekte-projects/jocl/18180-joclblas-java-bindings-clblas-2.html#post131422 , but commenting in the line 93,

clWaitForEvents( 1, new cl_event[] { event });

---

Beyond that, I'd likely be able to build the package in the next few days (Tuesday or Wednesday)

[blueberry]

Just kidding. I updated JOCLCommon source, and also all neanderthal tests pass.

[amherag]

@gpu Yes, I used the latest version of JOCLCommon and tested the jar with JOCLBlastSample :)

[gpu]

Thanks again to @amherag and @blueberry ! The release will soon be in Maven Central, at

<dependency>
    <groupId>org.jocl</groupId>
    <artifactId>jocl-blast</artifactId>
    <version>0.9.0</version>
</dependency>