| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
See
https://github.com/apple/swift/pull/19588/files#diff-923cd5ac82727b31d446c23641b3d749
for an example usage.
Also removed an experimental API that's no longer needed.
PiperOrigin-RevId: 214847132
|
| |
|
|
| |
PiperOrigin-RevId: 214681193
|
| |
|
|
|
|
|
| |
Also added some experimental C APIs for facilitate the use of eager C APIs in
S4TF compiler.
PiperOrigin-RevId: 213041780
|
| |
|
|
|
|
| |
based runtime in Swift for Tensorflow.
PiperOrigin-RevId: 211892308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get an owned device mgr from the input session.
One use case is in S4TF, we run a graph session to enqueue a tensor into a fifo
queue, and then call TFE_Execute() on a dequeue op over the same queue, as a way
to transfer a tensor from TF to host (tensor tranfer in the other direction also
works).
To make this work, we need TFE_Context and the the TF_Session to use the same
ResourceMgr object (attached to a Device, which is in turn owned by DeviceMgr),
so that both can access the fifo queue resource op.
PiperOrigin-RevId: 211471075
|
| |
|
|
|
|
| |
compiler?runtime to dump run metadata for debugging.
PiperOrigin-RevId: 206663537
|
| |
|
|
| |
PiperOrigin-RevId: 203059102
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Swift via direct session.
The changes are:
1. Added a TF experimental C API for Swift host to enqueue a tensor for sending
to TF. Again, the C APIs can be removed once the Fifo-queue based design
proves stable later.
2. TFLowerGraph is extended to generate Fifo related nodes for TF to receive
tensors. This is similar to the extension for TF to send tensors.
3. TFPartition is extended to support host send (createHostSend()), which does
the tensor send via a new protocol method TensorSendableReceivable.sendToDevice().
The main complexity is in sending a scalar, where a new protocol method
TensorSendableReceivable.createScalarTensor() is called to first create a tensor
out of it, and then send it over to TF.
Also removed code for protocol conformance on AccelerableByTensorFlow. Instead
have compiler look up that conformance from the SILFunction on sending/receiving
tensors.
AccelerableByTensorFlow could be removed from the compiler-known protocol list
now, but we'll defer that till things can stabilized more (in the past this
protocol has been added to and removed from the list at different times).
PiperOrigin-RevId: 195539436
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Swift via direct session.
The changes are:
1. Added an experimental TF C API TF_DequeueNamedTensor() to consume the queued
tensors from a dequeue op. One use case is for the Swift host program to consume
tensors sent by TF, where the queue is a Fifo queue managed by TF.
Enqueuing tensors are done by running an enqueue op in a graph. The queued
tensors are not persisted, and will be lost if the process/machine dies. The
queue has a bounded capacity, to prevent producer from being unboundedly ahead
of consumer.
while caller of TF_DequeueNamedTensor() could have run the Fifo dequeue op
directly, the extra level of indirection provided by this API allows us to more
easily switch the queuing impl to another mechanism. If and once we stabilize on
the Fifo queue based impl, we can remove this API.
2. Added a new S4TF runtime API _TFCReceiveTensorHandle() that receives a tensor
via TF_DequeueNamedTensor().
3. To support tensor receives in host program, taught PartitionCloner in
TFPartition to insert SIL code to call _TFCReceiveTensorHandle().
4. To support tensor sends in accelerator program, taught TFGraphLowering in
generate QueueEnqueueV2 nodes in the TF graphs, with appropriate control
dependence to make sure these nodes get executed.
a) The enqueue produces no output tensor, and is executed only for its side
effect. To ensure it is executed properly, control dependence is wired up. The
general design is: before a TF_Function (can be a top level function or the body
function of a while op) produces an output tensor OT, make OT control dependent
on the enqueue op, so that enqueue gets run before the function returns.
b) If tensor send occurs in a while loop body, the body logic currently gets
lowered in 3 places: the while op cond function, the while op body function, and
the ops at the same level as the while op itself (for running the last loop
iteration). In this case, the correct TFGraph lowering is to run the enqueue in
the last 2 out of the 3 places above.
After this CL, the dual versions of the above (dequeuing via an op, and
enqueuing via C API) will be added.
PiperOrigin-RevId: 194658511
|
| |
|
|
| |
PiperOrigin-RevId: 194031845
|
| |
|
|
|
|
| |
they are no longer needed. Also remove a duplicate function declaration.
PiperOrigin-RevId: 191918408
|
| |
|
|
| |
PiperOrigin-RevId: 190500020
|
| |
|
|
|
|
| |
reads imagenet TFRecord files.
PiperOrigin-RevId: 190488817
|
| |
|
|
| |
PiperOrigin-RevId: 190170332
|
| |
|
|
|
|
| |
rewrite functionality out of it.
PiperOrigin-RevId: 190016936
|
| |
|
|
|
|
| |
debugging purposes.
PiperOrigin-RevId: 189997099
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This initial design of the C API is different from (and mostly higher level
than) the python API counterparts for infeed, in that the python API has
explicit graph construction APIs for generating infeed enqueue/dequeue
ops (e.g. split_inputs_and_generate_enqueue_ops() and generate_dequeue_op()),
while the C API takes an input graph and redirects all input nodes to feed the
infeed enqueue.
One requirement/restriction is that the input nodes in the TF
graph (e.g. Placeholder) must specify their tensor shapes, for infeed enqueue
and dequeue nodes to properly compile with XLA. The API for more general shape
support will be designed and implemented later.
PiperOrigin-RevId: 189693028
|
| |
|
|
| |
PiperOrigin-RevId: 189131526
|
|
|
Also ran "buildozer warn //third_party/tensorflow/c/BUILD" and removed an unused symbol.
PiperOrigin-RevId: 186081948
|
Mingsheng Hong
A. Unique TensorFlower
Richard Wei
Yifei Feng