-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add IoU3D as a custom c++ op (CPU) #890
Conversation
/gcbrun |
/gcbrun |
/gcbrun |
/gcbrun |
This is now working with CI across all of our platforms, and I've also manually tested this on MacOS. Some todos are:
|
Are we sure that we want to go in a direction of limited HW compatibility for keras libraries considering also all the overhead of maintaining custom ops? I supposed that the scope of keras-* was to have a better interaction with the compiler team and stress test the technology but to still express our needs through the TF/*HLO composability. But I must also admit that recently, also on the "modern" and (M)HLO native JAX, something like custom ops is emerging again with jax-ml/jax#12632 (XLA's CustomCall) |
keras_cv/losses/iou_3d_loss.py
Outdated
@@ -0,0 +1,23 @@ | |||
# Copyright 2022 The KerasCV Authors. All Rights Reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the Google TF3d non custom-op performances of their 3d losses?
https://github.com/google-research/google-research/blob/master/tf3d/losses/box_prediction_losses.py
So are we already here with Keras-* as we was at the same point for many years with TFAddons with the Custom ops proliferation (often with 1K lines of code x PR for components that required custom ops with CPU or CUDA only support)? /cc @seanpmorgan |
Hey @bhack -- thanks for the comments This is for an existing internal use case which will require this custom op (the TF3D losses are insufficient) as well as a few other custom ops for 3D spatial data. I also worry about package accessibility and I want to make sure that we package this in a way which does not add user friction for Please let me know if you have any suggestions. |
I could understand that there was no time to address this subject and now, also on your side, you need just to "deliver" but I have tried to discuss this topic since June 2021 and earlier. What will we do, once you have introduced the c++ infrastructure in the project, when contributors will start to push for their own custom kernels for performance, uncovered vectorized maps and the underline API design of native TF ops or for XLA bridges uncovered ops in TF openxla/stablehlo#216 (comment))? Are you going to maintain a proliferation of user kernels excluding probably some HW vendor like e.g. AMD or Google CLOUD TPU? So you could also solve something urgent, for your internal delivery with this, but after 1 year and half I still not understand what the strategy is. |
@bhack I've updated the README and contributing guide to reflect a posture that we do not intend to invite user-contributed custom ops at this time, and that we only intend to include training-time CPU ops. |
/gcbrun |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! Thanks for pushing it forward.
set -x | ||
|
||
PLATFORM="$(uname -s | tr 'A-Z' 'a-z')" | ||
function is_windows() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some high level question on this:
- does this build script follow some other scripts? It would be nice to point out the reference so users can follow a pattern
- do we really want to support windows and mac builds? This will put more burden on maintainence and doesn't give immediate benefit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
This is adapted from TFA. I'm adding a link to the original script and a brief blurb about what this does.
-
We don't necessarily need to ship binaries for Windows and Mac OS, but including this makes it a lot easier for people to install from source it they want. I'm not sure if it makes sense to offer pre-built wheels for these environments, as I agree that it does add maintenance cost for not a ton of benefit. But it doesn't cost much to support it in the setup script IMO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose that these things are ported from Addons:
https://github.com/tensorflow/addons/blob/master/build_deps/build_pip_pkg.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pain is to support those if TF drops pre-built wheels for them
|
||
|
||
# Writes variables to bazelrc file | ||
def write(line): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question with build_pip_pkg.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a little doc blurb at the top -- is there anything else specifically you're looking for here?
|
||
cc_library( | ||
name = "tf_header_lib", | ||
hdrs = [":tf_header_include"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the header file inclusion and libtensorflow_framework inclusion seems correct to me.
Though it'd be better to point out where we're relying this from. The main reason for this ask is that "tensorflow_framework" might not be a guaranteed binary in the long run, and we should know how to fix this once that becomes true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow -- do you mean comments specifying that this is enabling linking to the installed TF version, or something else?
# distributed under the License is distributed on an "AS IS" BASIS, | ||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
# See the License for the specific language governing permissions and | ||
# limitations under the License. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see a _pariwise_iou_op.so
being included,
- should we just have a single
custom_op.so
that includes all the targets? - if a user wants to change some ops implementation, maybe we should have a documentation on how to do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I'm not sure what the right answer is. I figured that for now we can have a specific
.so
object for this op, and when we add further ops we can decide whether to merge them into a single binary or keep them split. I've seen packages take both approaches, and they both seem reasonable to me (e.g. TFA uses separate binaries but lingvo uses one) - This PR includes docs for installing from source, which should cover the biggest difficulty of developing custom ops. I think we probably want to generally discourage contribution of custom ops, but if you think this is valuable I can write a blurb in
CONTRIBUTING.md
about the workflow of working on these ops.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah please do so, my main ask here is how users can build and update the *.so file once they change the implementation.
having a single .so object seems better to me, even tensorflow itself only contains very few .so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha -- that is already covered in Tests that require custom ops
in CONTRIBUTING.md
. I've updated that file to refer to the instructions for building the binaries in the Contributing Custom Ops
section
I've also renamed the .so to _keras_cv_custom_ops.so
to indicate that later ops should be included in this same binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
keras_cv/losses/iou_3d_loss.py
Outdated
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
# ============================================================================ | ||
"""IoU3D loss using a custom TF op.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm...this is indeed very interesting...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be nice if you could adapt our .devcontainer
for C++
You could port copy the c++ entries from:
https://github.com/tensorflow/addons/blob/master/.devcontainer/devcontainer.json
…ute only major axis of pairwise IoU matrix
/gcbrun |
/gcbrun |
keras_cv/metrics/iou_3d.py
Outdated
Note that this is implemented using a custom TensorFlow op. Initializing an | ||
IoU3D object will attempt to load the binary for that op. | ||
|
||
Boxes should have the format [center_x, center_y, center_z, dimension_x, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we document a little bit the rational of this format choice in our python API?
I don't have stats on the popularity in the datasets, but If it is not the most popular native format we need to extend our current 2d bbox converters to 3d.
E.g. pytorch3d # Assume inputs: boxes1 (M, 8, 3) and boxes2 (N, 8, 3)
Please, check also the unified format in one of the largest 3d bbox dataset:
https://github.com/facebookresearch/omni3d/blob/main/DATA.md#data-usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's likely that we'll want to add converters in the future. I've opened #947 for this and we can address it once we have a minimal 3D bbox pipeline working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, one minor comment
Also I'm leaning towards only supporting Linux for now until we know better |
sgtm. I will leave the config code in for now for all platforms, but when we go to build our wheels we can build linux only for now (and other platforms can have a Python-only wheel) |
/gcbrun |
/gcbrun |
/gcbrun |
* Initial custom ops testing * Switch to cpp14 * Add include_package_data flag * cpp17 * Configure CI tests * Formatting * Call configure before running bazel build for CI * Verbose failures for CI/Bazel * Switch to tf-cpu for test flow * Use build dep impls from TFA * Update cloudbuild workflow to build binaries from source * Update cloudbuild docks (updated docker image) * Update GPU tests to TF 2.10 * Update copyright and docstrings * Move loss to internal, update README and CONTRIBUTING.md * Update to IoU op ported from Lingvo * Remove cuda config * Make iou3d a real keras loss * Skip custom-ops tests in devcontainer * Review comments * Remove skipping of IoU test from devcontainer (it is now opt-in) * Fix environment variable for windows * Update environment variable setting * Use env in yaml for environment variable * Review comments * Make IoU a metric, not a loss. Also update Cpp implementation to compute only major axis of pairwise IoU matrix * typo * Make test case more demonstrative * Switch to a single binary, remove binary from git * Move IoU3D from metrics to ops * Switch to full matrix computation of iou * Formatting
No description provided.