Explicitly listing --config=v2 incorrectly implied that building for TF2 was not the default.
PiperOrigin-RevId: 381038392
Change-Id: I6400a8edf40a7941d3b5132388d44f7aae698ea5
With the integration of rocsolver in the XLA cusolver pass, we need to set the ROCBLAS_TENSILE_LIBPATH env var. This seems to be required by rocsolver (which presumably calls rocblas internally). Not doing so leads to the following error in some of the XLA unit tests
```
test : //tensorflow/compiler/tests:dense_layer_test_gpu FAILED in 3 out of 3 in 4.7s
rocBLAS warning: No paths matched /root/.cache/bazel/_bazel_root/efb88f6336d9c4a18216fb94287b8d97/execroot/org_tensorflow/bazel-out/k8-opt/bin/tensorflow/compiler/tests/dense_layer_test_gpu.runfiles/org_tensorflow/tensorflow/python/../../_solib_local/_U@local_Uconfig_Urocm_S_Srocm_Crocblas___Uexternal_Slocal_Uconfig_Urocm_Srocm_Srocm_Slib/library/*gfx900*co. Make sure that ROCBLAS_TENSILE_LIBPATH is set correctly.
rocBLAS error: Cannot read /root/.cache/bazel/_bazel_root/efb88f6336d9c4a18216fb94287b8d97/execroot/org_tensorflow/bazel-out/k8-opt/bin/tensorflow/compiler/tests/dense_layer_test_gpu.runfiles/org_tensorflow/tensorflow/python/../../_solib_local/_U@local_Uconfig_Urocm_S_Srocm_Crocblas___Uexternal_Slocal_Uconfig_Urocm_Srocm_Srocm_Slib/library/TensileLibrary.dat: No such file or directory
```
Previously, XLA was enabled by default with --config=rbe_linux and when running ./configure.
PiperOrigin-RevId: 363433913
Change-Id: I9afa53496a9da2ae29b71a9ef38fc63b90dfba02
Use --config=avx_{linux,windows} instead of --config=opt in release builds. This is an NFC because release build scripts set build:opt to enable AVX.
PiperOrigin-RevId: 363193986
Change-Id: Ifb0788e29485873e35469d0936c1d33488315870
This PR introduces the support of Compute Library for the Arm
Architecture (ACL) as part of Bazel build.
Signed-off-by: Aleksandr Nikolaev <aleksandr.nikolaev@arm.com>
Remove TF_ENABLE_MLIR_GENERATED_GPU_KERNELS env trigger in ./configure for ROCm path. It has already been removed for CUDA, and ROCm currently doesn't yet support kernel gen.
PiperOrigin-RevId: 361635637
Change-Id: Id30c7c45a7fe033410457db9c9b8d51e573482b6
Before, the default PYTHON_LIB_PATH chosen was non-deterministically. This meant if ./configure was rerun and a different PYTHON_LIB_PATH was chosen, bazel would rebuild TF from scratch.
PiperOrigin-RevId: 356731041
Change-Id: Iefdebd0f6bb106a598f77e95cd36df87bb1c5d68
For GPU builds, the host compiler should get these compile flags as well.
PiperOrigin-RevId: 351470659
Change-Id: I8610ac871e370895f9234e3f047e7ee90557db86
Should resolve issue reported in #45744, #45866, #44701 and #45991 as well as multiple other issues from other ecosystem places.
We will patch 2.4 soon and release proper patches.
PiperOrigin-RevId: 350243794
Change-Id: I0aa814dedb44ac3ec992a0a432f117122337023f
Bug fixed: https://github.com/bazelbuild/bazel/issues/3828
We need this because we are working on integrating TF with a different project that should remove the breakages caused by LLVM integration
PiperOrigin-RevId: 348886284
Change-Id: Iad539321f1ba7590e4ee77b93d67eb5401d9fec8
When we switched to ROCm 3.3 (first ROCm release with "relocatable ROCm install" support), some parts of the ROCm toolchain relied upon the value of env var ROCM_ROOT to determine the location of the ROCm install dir. This has been fixed, and all of the ROCM toolchain now only uses the ROCM_PATH value.
This commit updates `configure.py` to no longer set ROCM_ROOT, when building with --config=rocm
Related JIRA ticket - http://ontrack-internal.amd.com/browse/SWDEV-226744
This flag was first made available in Visual Studio 16.4, (as of 2020-11-11,
VS is at version 16.8), and can now be considered generally available.
See also #38254
PiperOrigin-RevId: 342158585
Change-Id: Ice96be9a1392313357b314407262a005a2436a4d
This PR removes now-deprecated direct integration of nGraph in TF. nGraph
integration is still available via the external ngraph-bridge at:
https://github.com/tensorflow/ngraph-bridge/
or via `pip install ngraph-tensorflow-bridge`.
Signed-off-by: Abhishek Kulkarni <abhishek.kulkarni@intel.com>
Adds build option and supporting macros for oneDNN-reference builds on Aarch64.
For now, oneDNN will link to GCC's libgomp.so. See, related issue: https://github.com/tensorflow/tensorflow/issues/42858
Signed-off-by: cfRod <crefeda.rodrigues@arm.com>
MLIR generated gpu kernels will continue to be disabled by default.
This commit provides a way to enable them, if conifugre.py is run with the env `TF_ENABLE_MLIR_GENERATED_GPU_KERNELS=1`
Currently, if the version check fails, the error message is:
```
subprocess.CalledProcessError: Command '['bazel', '--batch', '--bazelrc=/dev/null', 'version']' returned non-zero exit status 1.
```
After this patch, it becomes:
```
Error checking bazel version: ERROR: The project you're trying to build requires Bazel 3.0.0 (specified in /usr/local/google/home/cheshire/code/opensource/docker_tf/tensorflow/.bazelversion), but it wasn't found in /usr/bin.
You can install the required Bazel version via apt:
sudo apt update && sudo apt install bazel-3.0.0
```
PiperOrigin-RevId: 312520687
Change-Id: I41523f7defa3db10aa34b6b313d6b65c792b2020
Avoid using `--enable_platform_specific_config` when cross-compiling for
iOS/Android, as this pulls in host build flags, which may not be
appropriate (e.g., when cross-compiling for Android on a Windows host).
Also fix an issue when building tensorflowlite_c for iOS.
Fixes#38525.
PiperOrigin-RevId: 311767770
Change-Id: I80b817fd89a6889dc78be50f1def8b899f091cb6
Use `bazel --version` instead of `bazel --batch version`.
`bazel --batch` fails on Windows with a "command line too long" error, if user's environment variable is too large.
Example: https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/496#f5fbd8db-7421-43f4-a018-555af9856be4
`bazel --version` can also print the Bazel version without starting Bazel server, it's even faster than `bazel --batch version`.
PiperOrigin-RevId: 310570885
Change-Id: Iafc4c90f0ff57610e5f77bee230e81e78d9f1289
Environment variables are strings, not integers.'0' does not evaluate to false.
PiperOrigin-RevId: 297916971
Change-Id: I9df143690b16a181fa5f0c4a60ac2f944b396672
