LWJGL Forum

Programming => Bug Reports / RFE => Topic started by: staffanu on March 27, 2019, 15:42:05

Title: [BUG] clEnqueueReadBuffer using non-blocking read to java array fails
Post by: staffanu on March 27, 2019, 15:42:05
The version of clEnqueueReadBuffer that reads into a java array does not work correctly when doing non-blocking reads. The reason is that the java array itself is pinned in memory using GetPrimitiveArrayCritical only for the duration of the call. So, sometimes the array is moved before the read completes (frequently enough that I eventually found out what is wrong...). Therefore having the parameter to select whether to block or not does not make sense.

I understand that the function itself is generated, but some possible fixes could be 1) remove the blocking_read argument from the function that reads into a java array, 2) add an assertion so that calling the function with blocking_read==false is caught, 3) at least document this problem somewhere.

As for 3), I haven't really found the tutorials and other docs to be incorrect, but they refer to possible non-blocking reads (which works fine for ByteBuffers). Since buffers created, e.g., with BufferUtils.createIntBuffer do not support the array() method sometimes using the methods that take java arrays as arguments is really useful.

Staffan
Title: Re: [BUG] clEnqueueReadBuffer using non-blocking read to java array fails
Post by: spasi on March 27, 2019, 16:13:51
The case you describe is one of a few reasons that made me regret the decision to support Java arrays in LWJGL bindings. You may have noticed that newer bindings do not expose array overloads, but it's too late for old bindings. Though, we can selectively disable array overloads for asynchronous functions, which is what will happen with clEnqueueReadBuffer in the next 3.2.2 snapshot.

Thank you for reporting this issue.
Title: Re: [BUG] clEnqueueReadBuffer using non-blocking read to java array fails
Post by: staffanu on March 28, 2019, 13:06:15
Ok, thanks -- at least that confirms I didn't misunderstand the problem. When you say removing the overload, notice that the same function can be used in a synchronous manner, so if that's a possible configuration it would be great to keep _some_ overload for reading into arrays, but to force it being blocking.

Also, related to me wanting to read into an array: if there is an alternative way to get the data into a java array through some kind of Buffer without making a second copy on the host, a pointer would be appreciated! :)

Staffan
Title: Re: [BUG] clEnqueueReadBuffer using non-blocking read to java array fails
Post by: spasi on March 28, 2019, 17:04:15
it would be great to keep _some_ overload for reading into arrays, but to force it being blocking.

After a few changes to LWJGL's code generator, I was able to keep the array overloads. They will now throw an IAE if called with blocking_read/write == false.

if there is an alternative way to get the data into a java array through some kind of Buffer without making a second copy on the host, a pointer would be appreciated! :)

If you need non-blocking reads/writes, then you can't avoid the additional copy. Ideally, you'd refactor the rest of the system to deal with buffers instead of arrays.