| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 215757701
|
|
|
|
|
|
| |
can use to accelerate transfers.
PiperOrigin-RevId: 215362667
|
|
|
|
| |
PiperOrigin-RevId: 212313258
|
|
|
|
| |
PiperOrigin-RevId: 210998142
|
|
|
|
|
|
| |
(tensor) buffer not owned by XLA/Literal class directly, without having to memcpy the Literal to a (Host)Tensor.
PiperOrigin-RevId: 207972410
|
|
|
|
|
|
|
| |
This isn't called from anywhere but the CPUTransferManager, just remove it as
it's holding back the implementation on all targets.
PiperOrigin-RevId: 204323463
|
|
|
|
|
|
|
|
|
| |
Infeed and outfeed manager are really similar but not quite the same, I'm open
for ideas on how to factor them better. This has a much cleaner design for
OutfeedManager than we have for InfeedManager, I'll look into cleaning up
InfeedManager in a follow-up.
PiperOrigin-RevId: 204012304
|
|
|
|
|
|
|
|
|
| |
Currently Literal classes sits in literal_util.{h,cc} instead of literal.{h,cc}.
It also contains helper functions that are better fit to be their own separate
class/namespace. This change starts this process by moving most static factory
methods to LiteralUtil namespace.
PiperOrigin-RevId: 203217065
|
|
|
|
| |
PiperOrigin-RevId: 201161803
|
|
|
|
|
|
|
|
|
|
|
|
| |
A TOKEN primitive type was added with cl/199215963 and XLA also has an OPAQUE primitive type. However, in many places in XLA we assume either a tuple or array. This CL fixes many of those instances, but some may remain. Identified instances were discovered by searching for IsTuple or IsArray so the set of fixes is not exhaustive.
Also opportunistically addressed a couple potential points of confusion in the ShapeUtil interface:
(1) Rename ShapeUtil::HasZeroElements to ShapeUtil::IsZeroElementArray. The point of confusion here is that tuples can also have zero elements and HasZeroElements would check fail on tuple shapes. Method no longer check fails if the given shape is not an array.
(2) ShapeUtil::IsNil now returns true only for empty tuples. Previously it also returned true for zero-element array types which was confusing because ShapeUtil::MakeNil creates an empty tuple.
PiperOrigin-RevId: 200452672
|
|
|
|
|
|
| |
Introducing a new LiteralOwningSlice class that is similar to LiteraSlice, but owns the root piece.
PiperOrigin-RevId: 196759785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and prepare for enabling more efficient interfacing from Tensor to Literal to
reduce host to device latency.
More specically:
* Introducing a new LiteralBase abstract base class that contains all immutable
methods of from the old Literal class.
* Introducing a subclass LiteralSlice to replace original LiteralView class.
LiteralSlice class is read-only and does not own Shape nor any buffer through
the Pieces. Change a number of callers to use LiteralSlice directly.
* Change Literal class to explicitly own the underlying Shape as well as owning
the underlying buffer via Piece.
* Conversion from Literal to LiteralSlice is now done via an implicit
conversion constructor instead of inheritance.
* Decouple ShapeTree from Literal classes.
* Use copy-and-swap for assignment constructors.
* Other minor cleanups.
PiperOrigin-RevId: 196016576
|
|
|
|
| |
PiperOrigin-RevId: 193301997
|
|
|
|
| |
PiperOrigin-RevId: 189945839
|
|
|
|
| |
PiperOrigin-RevId: 189258641
|
|
|
|
| |
PiperOrigin-RevId: 189231636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL primarily does two things:
(1) Remove the protobuf-compatibility methods (eg, mutable_f32s()) from Literal. These were added to Literal as part of the migration of Literal from a proto to a c++ class. Now that Literal is a proper class, these protobuf methods make it difficult to enforce invariants and expose too much of the class' implementation details.
(2) Make shape an immutable property of Literals, and make shape and the data members holding the Literal data coherent by construction. Previously, the shape could be set arbitrarily, and the data members such as f32_ could be arbitrarily sized irrespective of the shape of the literal.
The remainder of the CL mostly deals with the fallout. Notable other changes:
- Literal is no longer a recursive data structure. To avoid copies when passing a subliteral of a tuple-shaped Literal, a LiteralView class is added which provides a read-only view of an arbitrary subliteral.
- Tuple-shaped Literals can no longer be built up incrementally so to avoid copying Literal values during construction, the following methods with move semantics are added: Literal::MoveFrom and Literal::MoveIntoTuple. These methods transfer ownership the underlying buffers enabling, for example, a literal to be moved into an element of a tuple-shaped literal with no data copying.
- Replace the internal data structure holding the actual data from a bunch of std::vectors (eg, s32s_, f32s, etc) to a single ShapeTree<char*>. This significantly simplifies accessors and makes improved support of tuple-shaped literals much easier (eg, Literal::Get<>() can now access elements in arbitrary subliterals).
Also, Literal is made movable, but not copyable. Otherwise, it is all too easy to accidentally introduce expensive copies of Literals. Literal::Clone is added to handle the case where a copy is needed (Literal::CloneToUnique already exists).
PiperOrigin-RevId: 181014890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
179277894 by gunan:
Run buildifier on build file.
--
179275101 by meheff:
Replace DeviceMemoryBase with ShapedBuffer in XLA interfaces.
Executable, TransferManager, and AllocationTracker now use ShapedBuffer to hold device memory addresses holding XLA data. Most of the change is straight-forward with the exception of AllocationTracker which was mostly rewritten (and simplified) and some refactoring in the CPU executable.
Also, have ShapedBuffer hold on-host and on-device Shapes which are the shapes of the representation of the data on the host and device, respectively. This is necessary because with cl/178624364 the on-host and on-device shape may no longer be equal.
--
179265385 by A. Unique TensorFlower:
Return error rather than CHECK fail in Executable::ExecuteOnStreamWrapper
--
179264551 by dandelion:
Internal fixes.
--
PiperOrigin-RevId: 179277894
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specified by ShapedBuffer rather than DeviceMemoryBase. This is part of a broader replacement of DeviceMemoryBase->ShapedBuffer in several XLA interfaces. With this change TransferManager no longer has to allocate memory to transfer tuples to the device. The existing methods using DeviceMemoryBase will be removed in a followup cl.
Various related changes:
* Make the transfer_manager_test an xla_test so that it runs on all the platforms.
* Make several of the TransferManager methods protected.
* Change ScopedShapedBuffer::Allocate to only allocate device memory buffers, and not fill in the tuple index table. The index table is filled in by the transfer manager. This is a cleaner separation of concerns.
PiperOrigin-RevId: 176015628
|
|
|
|
| |
PiperOrigin-RevId: 174873299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data of a given shape) to also hold an array of pointers representing the tuple structure in the device memory. Previously ShapedBuffer only held array-shaped data at the leaves of the tuple shape. Construction of these array-of-pointers is handled by TransferManager which has to construct array-of-pointers anyway to transfer literals to the device. This change makes ShapedBuffer match the native representative of tuple-shaped data passed into XLA computations. This is the first step to migrating XLA interfaces away from using naked device memory pointers (DeviceMemoryBase) to using more expressive ShapedBuffers instead.
This change enables tuple-shaped parameters in computations run through the LocalClient interface.
Also, change LocalClient interfaces to return ScopedShapedBuffers as these are generally easier to deal with ownership-wise that ShapedBuffers. They are analogous to std::unique_ptr, while ShapedBuffers are analogous to bare pointers.
This change includes a couple other cleanups found along the way:
* move cpu/gpu/interpreter transfer managers into their respective directories under xla/service.
* Make the generic transfer manager take a pointer size. Previously it would just use sizeof(void*) which might not be exactly what is needed.
PiperOrigin-RevId: 170133015
|
|
|
|
|
|
|
|
| |
- Move plugin/executor to xla/service/interpreter/
- Remove executor's TransferManager, and use GenericTransferManager instead.
- Renamings and minor fixes.
PiperOrigin-RevId: 169160056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This stems from the dark ages when Literal was an unmovable proto. Swap was
supposed to be fast (it moves) but in the conversion to a standalone class Swap
wasn't implemented properly and became a 3-way copy instead of a 3-way move.
All of the users want move anyways, so just remove Swap and use moves on all
call sites.
If actual swapping is needed, std::swap will work just fine for Literal, and
the default implementation is as fast as 3 moves.
PiperOrigin-RevId: 168689138
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the CPU runtime wouldn't know how the data that was being outfed was
laid out by the XLA LayoutAssignment pass, which could result in
transposed-value results.
This also allows us to validate the contract between the host program and the
compiled XLA program with (reified) runtime type checks.
PiperOrigin-RevId: 161895093
|
|
|
|
|
|
| |
Note: does not yet support nested tuples, for symmetry with the current infeed
limitations.
PiperOrigin-RevId: 161502502
|
|
|
|
|
|
| |
This patch removes class xla::LiteralUtil and rewrites every call to use class
xla::Literal instead.
PiperOrigin-RevId: 159446373
|
|
|
|
|
|
|
| |
Mirroring the transfer buffer to device interface, add a transfer buffer to
infeed interface.
PiperOrigin-RevId: 159152897
|
|
|
|
|
|
|
| |
** GPU transfer manager and GPU specific infeed manager/infeed buffer implementation
** Infeed thunk
PiperOrigin-RevId: 157054373
|
|
|
|
|
|
|
|
|
| |
ElementalIrEmitter::MakeElementGenerator
There is nothing GPU specific in GpuElementalIrEmitter::MakeElementGenerator
for kPad. Move it into the base implementation so that all subcalses have it as
an implementation.
Change: 151564674
|
|
|
|
| |
Change: 151046259
|
|
|
|
| |
Change: 148699787
|
|
|
|
|
|
| |
We missed a few places, lets be more explicit and make the pointer_size
parameter necessary for TUPLE shapes.
Change: 146066214
|
|
|
|
| |
Change: 144258290
|
|
XLA is a compiler-based linear algebra execution engine that targets CPUs, GPUs and custom accelerators.
XLA is still experimental; we are releasing it early to get the community involved.
Change: 143990941
|