Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Apr 18, 2017
  3. Mar 03, 2017
    • Yang Ni's avatar
      Removed close guards for Element and Type objects · 45438c94
      Yang Ni authored 
      Bug: 28053769

These objects are tiny and unlikely to cause memory issues.

In addition, llvm-rs-cc auto-generated code contains such objects, which are
not visibible to developers and impossible to manually destroy, leaving
distracting warnings in Strict Mode.

Test: RsTest with StrictMode on and CTS tests

Change-Id: Iec68cca4f1259124b9f503a230c1a28b97ede1f3
      45438c94
  5. Jan 26, 2017
  7. Jun 14, 2016
  9. Jun 02, 2016
  11. May 25, 2016
  13. May 18, 2016
  15. May 10, 2016
  17. Apr 22, 2016
    • Yang Ni's avatar
      Fixed BaseObj finalizer and destroy() · 1b4df169
      Yang Ni authored 
      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
      1b4df169
  19. Apr 20, 2016
  21. Apr 19, 2016
    • Yang Ni's avatar
      Fixed ScriptGroup finalizer for old API · e04e5d7c
      Yang Ni authored 
      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
(cherry picked from commit 07837d6d)
      e04e5d7c
    • Yang Ni's avatar
      Made Element accessors thread-safe · 33703f0c
      Yang Ni authored 
      Bug: 28177082
Change-Id: I8f3f2d8ce559e93cba29f8eedd5b95d1389deb23
      33703f0c
  23. Apr 18, 2016
    • Yang Ni's avatar
      Fixed ScriptGroup finalizer for old API · 07837d6d
      Yang Ni authored 
      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
      07837d6d
  25. Apr 12, 2016
  27. Apr 11, 2016
  29. Apr 07, 2016
    • Yang Ni's avatar
      Destroy Closures in ScriptGroup · 44e2f45f
      Yang Ni authored 
      Bug: 27973681

Implemented correct destruction in ScriptGroup.destroy() and
Clsoure.destroy(), which properly destroys child BaseObj's.

Change-Id: I946f62c2979d6a338b8883514cacad472a213c5c
      44e2f45f
  31. Apr 05, 2016
    • Yang Ni's avatar
      Avoid destroying Device separately · cb939dc4
      Yang Ni authored 
      Bug: 27983025

Device should be destroyed inside the destructor of the associated
Context.

Change-Id: I921a89974e1174f837349a89aef9b03efa4882f5
(cherry picked from commit 4a70df58)
      cb939dc4
  33. Apr 04, 2016
    • Yang Ni's avatar
      Avoid destroying Device separately · 4a70df58
      Yang Ni authored 
      Bug: 27983025

Device should be destroyed inside the destructor of the associated
Context.

Change-Id: I921a89974e1174f837349a89aef9b03efa4882f5
      4a70df58
  35. Mar 31, 2016
    • Yang Ni's avatar
      Added CloseGuard for BaseObj · 6484b6be
      Yang Ni authored 
      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 eb4dd08e)
      6484b6be
    • Yang Ni's avatar
      Added CloseGuard for BaseObj · eb4dd08e
      Yang Ni authored 
      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
      eb4dd08e
  37. Mar 30, 2016
  39. Mar 29, 2016
  41. Mar 28, 2016
  43. Mar 21, 2016
    • Yang Ni's avatar
      Correctly init code cache path for RS · 15fcf61d
      Yang Ni authored 
      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 689f6377)
      15fcf61d
  45. Mar 18, 2016
    • Yang Ni's avatar
      Correctly init code cache path for RS · 689f6377
      Yang Ni authored 
      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
      689f6377
  47. Mar 04, 2016
  49. Mar 02, 2016
  51. Jan 27, 2016
    • Miao Wang's avatar
      [RenderScript] Unhide new Allocation APIs · c29bcd0d
      Miao Wang authored 
      Bug: 23535524

  - ByteBuffer getByteBuffer()
  - long getStride()
  - Allocation[] createAllocations(rs, type, usage, num)
  - long getTimeStamp()

Change-Id: I0cad88c81f9f48c7aca59af159c49f506b234aee
      c29bcd0d
  53. Jan 26, 2016
    • Miao Wang's avatar
      [RenderScript] Implement APIs for better multi-frame process support. · 8c150924
      Miao Wang authored 
      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
      8c150924
    • Miao Wang's avatar
      [RenderScript] Add API to map Allocation mallocptr to Java ByteBuffer · 0facf021
      Miao Wang authored 
      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
      0facf021
  55. Jan 25, 2016