| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attr values that are not overridden e.g. transpose_a in the matmul op).
This is required for backward compatibility (a binary built via an older version
of TF should still run on a newer version of TF, where some ops may have added
attrs).
For non-eager graph building, the default attr values of graph ops are added by
tensorflow::AddDefaultsToNodeDef().
We ran into this issue when running the same S4TF test cases via eager APIs --
some tests failed due to "missing attrs", but are fixed by this patch.
PiperOrigin-RevId: 215927271
|
|
|
|
| |
PiperOrigin-RevId: 215288224
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- EncodeArg in C instead of python.
- Also caches parsed device specs, and device spec hashes
- Adds a common way to register python types in C.
- Fastpath canonicalize function inputs when no kwargs are passed
- Set the func name attr directly instead of creating an op to wrap it.
- Rewrite IsAttrsHelper without caching
Before:
entry {
name: "MicroBenchmarks.benchmark_defun_matmul_2_by_2_CPU"
iters: 30000
wall_time: 101.803263028
extras {
key: "examples_per_sec"
value {
double_value: 9822.86785562
}
}
}
After:
entry {
name: "MicroBenchmarks.benchmark_defun_matmul_2_by_2_CPU"
iters: 30000
wall_time: 47.2899993261
extras {
key: "examples_per_sec"
value {
double_value: 21146.1199884
}
}
}
PiperOrigin-RevId: 215272962
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 214232622
|
|
|
|
|
|
|
|
|
|
| |
tensors in Graph mode defun.
This allows inferring the shape of values popped from TensorLists inside defuns.
Remove "Resource" from {Set|Get}ResourceHandleShapeAndType since the same functions are re-usable for variants.
Eager mode fix coming in a future changelist.
PiperOrigin-RevId: 213735462
|
|
|
|
|
|
| |
This is done by making the TapeTensor a template rather than a concrete struct.
PiperOrigin-RevId: 213700425
|
|
|
|
| |
PiperOrigin-RevId: 213377426
|
|
|
|
| |
PiperOrigin-RevId: 213372027
|
|
|
|
|
|
|
| |
Also added some experimental C APIs for facilitate the use of eager C APIs in
S4TF compiler.
PiperOrigin-RevId: 213041780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Change Variant Decode to accept VariantTensorData (non-ref).
This should allow some optimization in the future.
In the meantime it means removing the variant.h include from tensor.h, since
variant_encode_decode.h now relies on tensor.h and variant.h now relies on that.
It also means we found a bunch of places where tensor.proto.h, variant.h, and
mutex.h were being imported through tensor.h (along with a bunch of other crap);
so now we directly import them in order to compile.
2. Move Variant registry to use TypeIndex instead of a TypeName string; this should
speed up registry lookups.
PiperOrigin-RevId: 212478896
|
|
|
|
|
|
| |
based runtime in Swift for Tensorflow.
PiperOrigin-RevId: 211892308
|
|
|
|
| |
PiperOrigin-RevId: 211874311
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is so that gradients with respect to scalars pass (see the test added in
backprop_test.py).
A micro benchmark just calling constant_op.constant slows down a bit - this is
inevitable as we are creating a new python object.
After: walltime: ~2.1
Before: walltime: ~1.47
Linear regression benchmark is pretty much unchanged.
PiperOrigin-RevId: 211753801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
SparseSoftmaxCrossEntropyWithLogits
See https://github.com/tensorflow/tensorflow/blob/065f9b833ffbb3b2f03d63febb186275674ba133/tensorflow/python/ops/nn_grad.py#L482
Should help with #20218
PiperOrigin-RevId: 210933185
|
|
|
|
| |
PiperOrigin-RevId: 210816713
|
|
|
|
| |
PiperOrigin-RevId: 210596417
|
|\ |
|
| |
| |
| |
| | |
PiperOrigin-RevId: 209679086
|
| |
| |
| |
| |
| |
| | |
case, checking for alignment boundaries breaks due to division by zero. But in these cases the check itself is redundant, so replace EIGEN_MAX_ALIGN_BYTES with std::max(1, EIGEN_MAX_ALIGN_BYTES).
PiperOrigin-RevId: 209513729
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TFE_OpSetAttrString was holding on to the 'value' pointer
after it returned. This bug was introduced in commit
2b0805301e4531dd7c2ed677d932f6408675460e
which caused TFE_OpSetAttrString to invoke
AttrBuilder& AttrBuilder::Set(StringPiece attr_name, StringPiece&& value);
instead of:
AttrBuilder& AttrBuilder::Set(StringPiece attr_name, T&& value)
(where the latter copies 'value' when T is a StringPiece or const char*
and the former aliases the memory pointed to by StringPiece).
In this process, I realized that
AttrBuilder::Set(StringPiece attr_name, StringPiece&& value)
was never being invoked (other than in this buggy situation),
so I removed it altogether.
Without the changes to attr_builder.{h,cc}, the newly added test
fails - complaining that "NHWC" is not a valid value for the "padding"
attribute.
PiperOrigin-RevId: 209017110
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
when the if then/else body of If or the While body funcs do not have stateful
ops.
The are lowered to the same XLA ops.
One use case is in the S4TF compiler: https://github.com/apple/swift/pull/18509
PiperOrigin-RevId: 207977126
|
|
|
|
| |
PiperOrigin-RevId: 207971672
|
|
|
|
|
|
|
|
|
|
|
| |
Adopts a minimal sensible policy for step containers: starting a graident tape
creates a step container; inner tapes do nothing; popping out of the outermost
tape will reset that step container. This should allow us to have reasonable
behavior in the presence of step-container-scoped things for a while. Ideally
we'll move away from them in favor of lists but the infrastructure isn't ready
yet.
PiperOrigin-RevId: 207911091
|
|
|
|
|
|
|
|
|
| |
Any time that the server def is updated, the context is effectively "reset" by clearing all the caches.
- Check that the FLR returned is not a nullptr instead of seg faulting.
- Consolidate caches within the context object.
PiperOrigin-RevId: 207308086
|
|
|
|
| |
PiperOrigin-RevId: 207176253
|
|\
| |
| |
| | |
PiperOrigin-RevId: 206779913
|
| |
| |
| |
| | |
PiperOrigin-RevId: 206684358
|
| |
| |
| |
| |
| |
| | |
compiler?runtime to dump run metadata for debugging.
PiperOrigin-RevId: 206663537
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
to take a nullptr.
None of the other TFE_Delete* functions take a status, so this makes things a little more consistent.
PiperOrigin-RevId: 206374382
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
| |
Previously it would return an allocated buffer, even if there was an error and the buffer was not usable. This could cause memory leaks if the caller did not manually delete the buffer.
Because TF_DeleteBuffer has been updated to be safe to call on nullptr, it's still OK if callers attempt to delete this nullptr.
PiperOrigin-RevId: 205858542
|
|
|
|
|
|
| |
The TF_Delete* functions in TensorFlow's C API now safely do nothing when asked to delete a null pointer. This mirrors the behaviour of free in C and delete in C++.
PiperOrigin-RevId: 205844191
|
|
|
|
|
|
| |
This is part of the work to make available kernels possible to query, to support Swift For TensorFlow. There are also a number of github issues asking for the functionality.
PiperOrigin-RevId: 205660862
|
|
|
|
| |
PiperOrigin-RevId: 205273020
|
|
|
|
| |
PiperOrigin-RevId: 205239285
|
|
|
|
| |
PiperOrigin-RevId: 204825266
|
|
|
|
|
|
|
| |
Prior to this change, captured resource variables in TF functions (or
any captured resource tensors) would not have shape information.
PiperOrigin-RevId: 204347306
|
|
|
|
| |
PiperOrigin-RevId: 203786896
|
|
|
|
| |
PiperOrigin-RevId: 203059102
|
|
|
|
| |
PiperOrigin-RevId: 202585094
|
|
|
|
|
|
|
|
| |
Since we respond with the shape, all RPCs will happen sync (note
that we may still hide the python overhead, since the op is still scheduled for
execution via the eager executor).
PiperOrigin-RevId: 202207324
|