-
Notifications
You must be signed in to change notification settings - Fork 16
aarch64 support #42
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
Comments
Thanks for the report, this is related to the discussion here:
A first step would be to try to build and test VTK on aarch64. Did you have any success doing so ? |
@jcfr , I have build the VTK wheel on aarch64 architecture but not sure how to test it. Can you please help me here? |
@jcfr is there anything else required from my side. |
@odidev if you built the wheel, you can just run |
I doubt we're going to be able to provide aarch64 wheels as long as we lack hardware for testing and building them regularly. |
@odidev This is exciting and thanks for sharing updates and thanks for your patience 🙏 As @mathstuf mentioned, we do not have the infrastructure to test here but we shouldn't let that stop us from having wheels for aarch64. I am sure we could find community members willing to help support this. Now, would you like to document the steps used to build the VTK wheel ? Also, since the process to build the wheel has been completely revamped (see here), would be great to try these. |
@jcfr, I explored the link Steps to build aarch64 wheel
Installation/import logs
|
@jcfr, can you please let me know if I can help with anything else. |
We don't do aarch64 testing of the codebase, so without that, I'm hesitant to make official releases of builds. Is there some way to mark uploads to PyPI as experimental or the like (not per-version, but per artifact)? |
@mathstuf - thanks for this. I work with @odidev on the AArch64 enablement. I think your asking about marking the aarch64 wheel as experimental in PyPI - something that I don't believe is supported. We may be able to help by adding some automatic testing. As a simple end-to-end case, I guess running something like https://vtk.org/Wiki/VTK/Examples/Python/Cylinder with xvfb and comparing the result to a known good rendering would be a start. Would that provide sufficient confidence to move forward with an AArch64 wheel? |
I'd like a full test suite run on aarch64 (with Python enaled). This would be a normal (non-wheel) build of VTK since our wheel build configuration doesn't work with the test suite (due to the library relocations). You should be able to submit a run to our CDash with |
Hi @mathstuf, I tried running tests but it looks like the tests are not getting picked up. Please find below steps which I followed to run the tests. Also, can you please point it out if I am missing anything here? Steps to build vtk
Running ctest
|
The tests are off by default. Should be |
OK. Let me try that. Thanks for the quick response. |
@mathstuf , I tried configuring VTK by "cmake -GNinja VTK_BUILD_TESTING=WANT -DVTK_WRAP_PYTHON=ON ../vtk/" command but even this is not helping me. Please find below logs-
|
@mathstuf, can you please suggest what needs to be done here? |
For reference, build options for VTK are documented here: Instead of running
Running |
It looks like you missed |
@mathstuf Thanks for your support. I am able to run the test cases on x86 machine but few test cases are failing. |
(I'm working with @odidev). @odidev - I guess the good news is that all the failures look the same: 'numerical' :) Can you work on reproducing a single test with a complete example of how to reproduce the single test failure. Also, please can you output more verbose logging information as this may reveal the source of the problem. |
I have attached the test file TestConeLayoutStrategy.txt which looks to be a minimal program to reproduce the issue. |
I have ran example program to display the cylinder on both aarch64 and x86_64 architecture. Please see blow outputs on both the architectures |
I have no idea how to figure out rendering/OpenGL failures, sorry. @martinken? |
Out of many issues in VTK testing on Linux/ARM64 machines, the most prominent issue seems to be the import error, while importing the module: ‘vtkCommonCore’. Please find the error logs below:
Above logs are the result of following test command:
The above error logs are the same in all the test cases, which shows the import error. According to the logs, ‘vtkCommonCore’ is not getting imported, which results in an undefined symbol error for ‘_Py_NotImplementedStruct’. I have tried following resolutions to fix this error:
But the error remains the same. Can you please provide me with some pointers to this import issue during VTK testing on Linux/ARM64 machines? Once this error gets resolved, I will look into the rendering issue in other test cases. |
That's odd. Can you try with Though it is used in the generated code and is in the Python headers. Is it not in |
@mathstuf I suspected that the python import issue must be hitting because of some varied system configuration. So, I moved to another ARM64 server, and built and tested VTK. The results are much better than before, and there are no python import issues. 95% tests are passing now, only 112 tests out of 2156 tests are failing.
This error comes from this line in the VTK project. I again ran the test suite on a AMD64 server machine(accessed via mobxterm), and found that out of above 92 test cases failing in ARM64, only 50 tests showed the same issue (mentioned above) on AMD64 server machine.
The error logs come from this line in VTK project.
As the test results are varied on different machines, can you please provide some pointers and check if these issues are related to unavailability of GPU or not? Are there any possibilities to pass these tests alternatively? This can help me progress in this activity. Also, may I please know if any of the above test failures can be ignored or not? Please let me know if you need any further information from me. |
@martinken Any thoughts on the OpenGL failures/differences here? |
The texture buffer limit is a mesa issue and we have a MR in to fix it so fee free to ignore those. Haven't had a chance to look at the others. |
I have analysed that some tests are written for the x86 architecture, and out of them, few are not correct for the ARM64 architecture. This is because the C/Cpp compilers treat CHAR differently for AMD64 and ARM64 machines. For example: Let’s run the test CommonCoreCxx-UnitTestMath On ARM64 machines, the C/Cpp compiler reads the CHAR’s range from 0 to 255. On the other hand, AMD64 C/Cpp compilers treat CHAR from -128 to +127.
This is because, VTK_CHAR_MIN and VTK_UNSIGNED_CHAR_MIN are both assigned the value ‘0’, and VTK_CHAR_MAX and VTK_UNSIGNED_CHAR_MAX have been assigned the value 255, for ARM64 machines. This creates data mismatch in the array check defined in the function definition of “vtkMath::GetScalarTypeFittingRange()” function here : https://github.com/Kitware/VTK/blob/master/Common/Core/vtkMath.cxx#L2842. Both CHAR and UNSIGNED CHAR are treated the same way. Thus, for the ‘unsigned char’ test case here: https://github.com/Kitware/VTK/blob/master/Common/Core/Testing/Cxx/UnitTestMath.cxx#L3282, the macro ‘VTK_UNSIGNED_CHAR’ (value hardcoded to 3), is compared to the function returning value 2 (defined for the range of CHAR). This fails the test case for ARM64. This test case would have been failing for AMD64 as well, if there were a case of SIGNED_CHAR used along with CHAR, as AMD64 C/Cpp compilers treat both CHAR and SIGNED CHAR from -128 to +127. Hence, the test would have compared VTK_SIGNED_CHAR (value hardcoded to 15) with function returning 2 (defined for the range of CHAR). Can you please suggest if we can do something for such test cases? |
I have no idea how prevalent the Interestingly, the Python |
I'm (trying) to build vtk python modules on an arm64 system as well. I'm using the instructions you referenced, here: https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/dev/build.md#python-wheels
Everything runs fine, and if I am inside the build directory, and run python followed by a VTK import, it works well. But the python3 setup.py bdist_wheel command doesn't exist. The VTK directory itself is ~4GB, so I'd like to somehow get the vtk python module into a portable format I can distribute to another identical system. My understanding was that building a wheel was the best way to do this, but in the absence of the bdist_wheel command, what would you recommend doing?
|
Do you have the |
I did not, thanks! Everything is working now. Interestingly, even once it is installed, it's not shown in the help files. I guess to more software-oriented people it's obvious, but for me, without wheel installed the command failed like so:
So I then checked the help for setup.py, which showed no such "bdist_wheel" option. The combination of "invalid command" and it not existing in the help sort of leads the user away from concluding that the issue is a missing package rather than an issue in setup.py itself. Replacing invalid command with "wheel module missing" (or mentioning wheel must be installed in the guide) might clear this up?
|
Welcome to my world of "list of problems with distutils / setuptools" :) . I can add a note to the VTK docs, but for |
I added a binary wheel for python3.10 here: https://github.com/finsberg/vtk-aarch64/releases/tag/vtk-9.2.6-cp310, which you can install with
|
Thanks a lot @finsberg for providing a whl file. I was able to build VTK python wheel following the instructions provided in the thread, however I'm getting much bigger .so files (see screenshot, left is my whl and right is yours). I'm curious on how you got something way lighter: did you compile with different instructions? |
That looks like a |
@thewtex I think I just followed the recipe here: https://docs.vtk.org/en/latest/advanced/build_python_wheels.html and I belive I also set |
Ah, the debug info could definitely be a problem here. Do things look better if you run |
Awesome, thanks a lot @mathstuf and @finsberg , indeed it was the debug info ( cmake -GNinja -DVTK_WHEEL_BUILD=ON -DVTK_WRAP_PYTHON=ON -DCMAKE_BUILD_TYPE=Release ../vtk/ Thanks again and happy new year! |
New wheel for python3.12 is available here: https://github.com/finsberg/vtk-aarch64/releases/tag/vtk-9.3.0-cp312 |
Thanks @finsberg! Does anyone have any thoughts as to how we can get this vtk's radar / get a discussion going with the VTK folks? Linux ARM machines are will start growing in market share, so it would be good for VTK to have a plan here. |
I guess they are waiting for: github/roadmap#970 |
I'm not sure that's the blocker here. VTK has moved to Gitlab and it seems like their CI is not tied to GH actions |
This seems like a good place to follow the issue. Maybe I'm wrong about the CI and somehow they use GH machines for Gitlab CI. |
Sure. I guess it will relate to: https://gitlab.com/groups/gitlab-org/-/epics/8442 |
We have the hardware (we "pitched in" when CMake needed new aarch64 hardware to "claim" future space); we don't know if it is enough to support VTK. We also do not have resources to put towards setting it up and maintaining it as no paying customers are asking for linux-aarch64 wheels. |
why this PR? https://gitlab.kitware.com/vtk/vtk/-/merge_requests/11895 Github: https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/ |
VTK installation using pip on aarch64 machine fails with below issue:
The text was updated successfully, but these errors were encountered: