Apple silicon homebrew installs to `/opt/homebrew` instead of '/usr/local/opt`

[RussTedrake]

https://apple.stackexchange.com/questions/410825/apple-silicon-port-all-homebrew-packages-under-usr-local-opt-to-opt-homebrew

Unsurprisingly, bazel is not happy. It starts with the rules_python failing to find python3.9. Who knows what else...

I believe Drake is not useable on the new macbooks until this is resolved? @BetsyMcPhail -- do you have the ability to test / own this?

[jwnimmer-tri]

We have #14555 presently underway to investigate Drake vs the new apple hardware.

[RussTedrake]

Ah. I'm sorry I missed it. A few simple changes get me pretty far into the build. I might hammer on it a bit more to see if I can get at least a proof-of-life example.

[RussTedrake]

Ok, I've got most things working on this branch.

The biggest paint point, I think, is the lack of SSE. I decided to not resolve the issues in the FEM dir yet (cc @xuchenhan-tri ). I disabled mosek and gurobi to get up and running, too, but don't have any particular reason yet to fear that they will be hard to get going.

bazel test -- //... -//multibody/fixed_fem/...

With my changes, all included targets build successfully. Almost all tests pass, with exceptions noted below:

• A few tests fail simply because the numerical tolerances will need to be tweaked slightly.
• dReal will take more work; we knew in the recent PRs that it needed filib built with SSE to pass the tests.
• drake_visualizer doesn't work yet (it's looking for /usr/local/opt/vtk@8.2)

Some of the changes in the branch could be added directly or with minor modification. A few require more bazel plumbing, e.g. to branch on the different mac versions.

[BetsyMcPhail]

Thanks for working on this branch. @mwoehlke-kitware has also been looking into this issue. Tagging him here to keep him up-to-date.

[xuchenhan-tri]

@RussTedrake are the FEM issues high priority to fix? If not, I'll investigate a bit later (probably over the break).

[jwnimmer-tri]

@RussTedrake what is your overall objective here? What is the bug or missing feature, in particular and specifically?

My current stance is that building Drake for native ARM is out of scope for our current platform matrix, and is tracked under #13514 already. I don't see any particular need to support drake developers who use that hardware, since almost none of the developer team has it.

I would like Drake's nightly binaries (and monthly releases) to be able to run on the new apple hardware, so that our users can still use those kinds of machines. That work is tracked under #14555 and is actively underway.

[jwnimmer-tri]

A few tests fail simply because the numerical tolerances will need to be tweaked slightly. dReal will take more work; we knew in the recent PRs that it needed filib built with SSE to pass the tests.

@mwoehlke-kitware observed the same, in the #14555 experiments.

drake_visualizer doesn't work yet (it's looking for /usr/local/opt/vtk@8.2)

Per #16215, we do not plan to support drake-visualizer on apple silicon.

Some of the changes in the branch could be added directly or with minor modification. A few require more bazel plumbing, e.g. to branch on the different mac versions.

Setting up CI (#16380) will be the first step toward addressing this.

The (soon to be forthcoming) final step of #14555 is for me to publish onto our website the instructions for running Drake under Rosetta. That should unblock users with apple silicon -- they can run Drake using Rosetta, once they know the magic command.

Thus, I'll closing this issue as a duplicate of that one.

[RussTedrake]

sounds good. just to report, I've continued to rebase the branch I posted above... it's sufficient for me to run pydrake on the arm64; though I had to disable mosek.

A number of the fixes on my patch would be harmless to PR now (basically adding a second "hint" directory for pkg-config). Should I do that? Or would you prefer to wait for CI?

[jwnimmer-tri]

For the pkg-config hints it's important that we have exactly one mac hint, or else the Rosetta 2 users will be disrupted. The repository logic will need to gain a variable or function that establishes the homebrew prefix to be used.

[jwnimmer-tri]

(If you have test tolerance patches, though, I think those are fine to submit now.)

[RussTedrake]

I'll continue to post my patches at #13514.