Bug: 31992305
Test: Build and CTS RsBlas test pass on Angler.
Change-Id: If49c0be003d9c2a2175924dc3303703b9ab49357
(cherry picked from commit b742fcc808165fbeeb1a48761e7d629f60207de2)
Bug: 23159764
Bug: 26862970
- Add detailed description of AutoPadding
- Add comments to all the copy related APIs.
- Fix typos in the comments.
Change-Id: I2d045e0d90efd94f1407f88d3e35bcd42ea93fb9
Bug: 28242626
Bug: 27972184
Bug: 27973681
This is resolving issues in ScriptGroup (V1) again.
In ScriptGroup.destroy(), we also need to consider the old API where
mClosures is not initialized.
Also cleaned up the finalizer for ScriptGroup and Allocation:
Since BaseObj.finalize() calls BaseObj.helpDestroy(), instead of
BaseObj.destroy(), there is no possibility that the finalizers of
child objects may race their parents finalizers. Note that
helpDestroy() does not try to recurse on child objects.
Change-Id: I9dbb2b60f8478f656f8a418c2b5fc8d6848aeef0
Bug: 28242626
ScriptGroup finalizer clears out the list of closures, which is
uninitialized for the old API.
Need to check null first, before accessing the list.
Change-Id: Ibf914e17a0878c8c561f823c5f6f6f6619594de1
Bug: 27719830
To turn on warnings, apps have to add to their Activity.onCreate() method
the following code.
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedClosableObjects()
.penaltyLog()
.build());
For Slang generated ScriptC derived classes, we assume their
constructors won't throw exceptions after calling the ScriptC
constructor. In addition, ScriptIntrinsic derived classes do not seem
to throw exceptions in their constructors either. Therefore, we can
leave the guard.open() call in the Script constructor. This may be
only an approximation, but allows us to add CloseGuard for script
objects without making changes to slang.
Change-Id: I77ed45239a60b85af5c811dee6c124fb53da9060
(cherry picked from commit eb4dd08ec132f83745b8b28fa7da58eb4478b5b9)
Bug: 26916665
- Add description of the endArg.
- Update the example.
- Update the incorrect description.
Change-Id: Idd07db5d790e2d6462fff9cb580115ec45cfd4f0
Bug: http://b/25982676
Instead of returning null from validateObjectIsPrimitiveArray, fail with
an exception. The callers of this function do not check for null.
Change-Id: Idd2b50a7b137e8d2db7a334bb9a48c1b19ee2403
Bug: 27439261
Script Group needs to know the code cache path before it can call bcc to
merge kernels. However, before this change, the code cache path has been
initialized by the ScriptC class.
In the case where a script group (or even the entire app) does not contain any
regular script but only intrinsics, the code cache would remain uninitialized.
Fixed this by initializing the code cache path in the RenderScript class
the first time when the accessor method is called.
Change-Id: I87f9e62e0f3b479f94e43daa3e9695a5b38710db
(cherry picked from commit 689f63770048589e1001ce99faf1d2eaf9780a80)
Bug: 26498479
Although the size of struct ScriptCall is not used underneath in the
runtime or drivers, assign the correct value here to avoid confusion.
Change-Id: I8db19538b9f70f3bf9ee849a8724da3d9ee04785
(cherry picked from commit e8f2e445fdb138416043a16659bbf86fbbd3fff8)
Bug: 25570907
Added a flag to all RS runtime API for rsObj creation to indicate a
call is from Java. This flag will help us avoid incrementing the user
ref count for rsObj's created from Single-Source RS, and therefore
avoid memory leaks for such objects.
Change-Id: Id3604f93b166089e3aca896d1c6c509b3ea19bcf
(cherry picked from commit ad88055821a7aba3318f066c4e5f87bd0315462c)
http://b/27251511
Handle FLOAT_16 case to PER_ARRAY_TYPE macro to enable untyped variants
of Allocation-copy functions.
Untyped variants of Allocation-copy functions call
validateObjectIsPrimitiveArray(), with checkType parameter set to true,
to validate and obtain the Element type of the Allocation. When
checkType is true, validateObjectIsPrimitiveArray() returns the actual
Element type of the Allocation (instead of the canonical SIGNED type).
Because of this, FLOAT_16 element type can reach the JNI layer,
necessitating this change to PER_ARRAY_TYPE macro.
Change-Id: I3651e5ae0ab0cd6bb4ad3157841e2910ac8699dc
http://b/27251511
Allow copyTo(short[]), copyFrom(short[]), and their 1D range and 2D
range variants to copy data between short[] arrays and Float16
Allocations.
Change-Id: I370584685c3b773c165bd718974ca736ed548339
Bug: 23535524
Two APIs added for multiframe processing:
- createAllocations(...): To create an array of Allocations sharing the
same Type and Usage. For USAGE_IO_INPUT Allocations, they also share
the same BufferQueue.
- getTimeStamp(): API to retrieve the time stamp associated with the
most recent buffer.
Change-Id: I6b7b35d7dca5e87ee2f3db2ee17cb9cf824bcfe1
Bug: 25926361
Bug: 23535524
- Construct the ByteBuffer using the AllocationGetPointer.
- Add an API to query the stride of the allocation.
- Both ByteBuffer and Stride will be cached for normal Allocations.
if using USAGE_IO, since after each ioReceive, the mallocPtr will
change, getByteBuffer will always create a new one using the most
up-to-date mallocPtr.
Change-Id: I5e84b6690e83bb062c383043275524d0e51e46eb
Bug: 25602504
1) Passing floating point values into a script group was broken,
since they were casted to long values. Fixed that in the frameworks
implementation by taking the raw bits instead.
2) Passing 64-bit values into a script group was broken on 32-bit
platforms, since they were casted to pointer-sized integers
(uintptr_t) in the JNI code. Fixed that by casting to int64_t
instead.
3) Setting global variables of Allocation type in a script group was
broken. The special size value -1 was used to indicate the value is an
Allocation. However, size was casted to size_t in the JNI code.
Fixed that by using signed integers.
Change-Id: Ifff099a76be7707df7b67c388395f5a00f9cae66
Interrupt current thread if InterruptedException is received during
Thread.join(). Also, log the interruption.
Change-Id: I452124915ea3f19610e6d4a3411d741f2f604af2
Bug: 24342101
If interrupted during mMessageThread.join(), retry the join instead of
assuming the thread has joined and continuing. Continuing to destroy
the context will cause a segfault when the message thread attempts to
use the destroyed context.
Change-Id: I3213091a0e996449bceb403dffca3063786d5a65
