Add Windows ARM64 support #117036

Manually merged
Brecht Van Lommel merged 24 commits from Anthony-Roberts/blender:arm64-support into main 2024-03-06 16:17:16 +01:00

A quick summary

This PR adds support for Windows ARM64 devices to blender, including dep building.

I expect there might be a few people with things to say regarding this PR, all feedback is welcome!

This requires VS2022 - it is not possible to use VS2019 due to a number of of internal compiler errors I discovered/reported while making this changeset, that have never been backported.

This only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above - older generation devices are not, and will not be supported, due to some driver issues. This was already dealt with via #113674, but better to clarify than not.

Example machines that will work:

  • Microsoft Project Volterra (Dev Kit 2023) Machines
  • Lenovo Thinkpad X13s
  • Microsoft Surface Pro 9 (ARM version)

Example machines that will not work:

  • HP EliteBook Folio 5G
  • Acer Spin 7

A few things to clarify (ie, things that may raise questions):

  1. Disabled deps
    1. OpenPGL is disabled for now, there are a few of oddities with it (like shipping with it's own copy of embree?) that need a more in-depth look at, and would hold the PR up
    2. OIDN is also disabled, however support is "coming soon" (timeframe unknown): https://github.com/OpenImageDenoise/oidn/pull/183#issuecomment-1883620852
    3. DPCPP is also disabled - there is no Windows ARM64 support in DPCPP at present (this also means no SyCL support at present)
  2. Embree
    1. This is built in a weird way, as it is not possible to build it on Windows ARM64 devices with MSVC, it has to be built with LLVM. Therefore, it is built with the version of LLVM that is also built as a dep (given no DPCPP on WoA).
    2. Given we build it with LLVM, and the dep version of LLVM is not always the latest that matches VS2022, we need to fall back on the VS2019 tools (which are comparatively stable), otherwise issues requiring _ALLOW_COMPILER_AND_STL_VERSION_MISMATCH arise, when the VS2022 build tools are updated to a new version (and older ones marked deprecated).
    3. Ninja doesn't allow specifying a different version of the build tools than the ones in the parent, so we have to fall back to using the VS generator instead.
    4. I did try to comment this as best as I could, feedback welcome.
  3. harvest.cmake
    1. I have no idea what this DEPENDS is supposed to be on L24 - unless it's commented out, CMake gives me an error that it's undefined?
  4. LLVM
    1. As I need to build embree with LLVM (see point 2), I have moved a few things about to allow lld to be built on WoA devices, as it's needed to compile embree.
  5. Python
    1. I had to split the diff file into seperate x64 and arm64 ones, as otherwise we end up with both arches being built on both platforms (x64 and arm64).
  6. MSYS2
    1. I stopped msys2 updating itself when run (which probably should have been the default behaviour anyway when I made the PR last year) - versions as of ~2 months ago started to randomly hang on WoA machines - this keeps a known working version.
  7. Vulkan
    1. This doesn't run on current-gen WoA devices anyway, unless you use Dozen via Mesa, but it seems to work (until it fails on some checks, as support for dualSrcBlend and logicOp is missing right now), so I left it as-is.
  8. TBB
    1. As USD is still forcing us to use 2020.3, I've had to backport ARM64 support to this version. Once an update to a newer version is made, all my TBB stuff can be deleted as it works OOB with newer versions on WoA.
  9. USD
    1. See above - also I will upstream my changes to this in the future, but I am waiting on some issues I opened to be resolved first.
  10. make.bat
    1. ~~I modified this to have an extra arg "own_vcvars" - it made life easier during development when I was using some rather bleeding-edge versions of MSVC at times
    2. I can remove this if required, but it might be useful in the future elsewhere for someone~~
  11. New MSVC preprocessor
    1. This is required for MSVC+sse2neon - I included a few portable fixes should you ever wish to enable this on x64 devices (IIRC newer C++ standards on MSVC enable parts automatically anyway?)
  12. NEON
    1. MSVC is very strict to the C standards, and doesn't allow initialising unions to anything but the first stated type - I had to make a few changes around this
    2. I also changed a few other parts to use the relevant methods such as vsetq_lane_f32 instead of directly indexing, which MSVC doesn't like.
  13. draw_manager.cc
    1. For some reason, which I can't figure out, if the uninitialised data pattern was run (ie release asserts enabled), the viewport just gave up rendering anything
  14. CPUID
    1. No CPUID instruction on ARM64 so I pull the processor details from the registry instead

Any more questions, queries, comments, or concerns - please do ask. I anticipate there may be a few.

Testing

Test suite

Several tests fail:

95% tests passed, 15 tests failed out of 322

Total Test time (real) = 526.87 sec

The following tests FAILED:
         48 - io_wavefront (Failed)
         86 - constraints (Failed)
         88 - bl_animation_armature (Exit code 0xc0000409)
         99 - cycles_bsdf_cpu (Failed)
        102 - cycles_hair_cpu (Failed)
        108 - cycles_light_cpu (Failed)
        111 - cycles_mesh_cpu (Failed)
        115 - cycles_principled_cpu (Failed)
        116 - cycles_render_layer_cpu (Failed)
        117 - cycles_reports_cpu (Failed)
        118 - cycles_shader_cpu (Failed)
        120 - cycles_sss_cpu (Failed)
        121 - cycles_volume_cpu (Failed)
        125 - compositor_filter_cpu (Failed)
        320 - imbuf_save (Exit code 0xc0000409)
Errors while running CTest

At least some of these cycles failures are complaining due to a lack of OIDN. Others (subsurface base color mix for example) do appear to be genuine failures.

There appears to be one precision related, I suspect the tolerances could be adjusted? Might be because I set /fp:fast, or loss of precision via sse2neon.

Testing this PR/Machine setup

I believe Francesco has been sent 2x WoA (Volterra) machines by MS. You will need to install VS2022 with the following options:

Selections:
Desktop Development with C++

Individual:
C++/CLI suport for v142 build tools (v14.29-16.11)
C++/CLI suport for v143 build tools (latest)
MSBuild support for LLVM (clang-cl) toolset
MSVC v142 - VS 2019 C++ ARM64 build tools (v14.29-16.11)
C++ MFC for latest v143 build tools (ARM64/ARM64EC)
C++ v14.29 (16.11) ATL for v142 build tools (ARM64)
C++ v14.29 (16.11) MFC for v142 build tools (ARM64)

You also need to download the latest adreno driver (contains compute shader support): https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-8-series-mobile-compute-platforms/snapdragon-8cx-gen-3-compute-platform#Software

I also have one WoA machine at home I am willing to give access to - probably someone who won't be able to access the above mentioned ones that are likely at Blender HQ. I would need a WireGuard public key for this, and it would be via RDP.

If people want to skip the deps build bit, I can provide a prebuilt lib folder - just ask :)

If you just want a prebuilt to play with, a nightly is available from our CI here (link at bottom of page): https://linaro.atlassian.net/wiki/spaces/WOAR/pages/28769779775/Blender

Additional Notes

  • Linking seems to take upwards of 25 mins
  • The viewport flickers sometimes when zoomed in (clay view, textured view is fine) - difficult to reproduce, but happens from time to time.
  • "Denoise" needs to be unchecked under "render", otherwise cycles won't render anything (see #115200)
  • There is a shader compiler issue which will have a BSP update out in due course - the effect is noticeable on the 3.3 splash in the viewport, where meshes fail to render in some cases
# A quick summary This PR adds support for Windows ARM64 devices to blender, including dep building. I expect there might be a few people with things to say regarding this PR, all feedback is welcome! This requires VS2022 - it is not possible to use VS2019 due to a number of of internal compiler errors I discovered/reported while making this changeset, that have never been backported. **This only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above - older generation devices _are not_, and _will not_ be supported, due to some driver issues.** This was already dealt with via #113674, but better to clarify than not. Example machines that will work: * Microsoft Project Volterra (Dev Kit 2023) Machines * Lenovo Thinkpad X13s * Microsoft Surface Pro 9 (ARM version) Example machines that will not work: * HP EliteBook Folio 5G * Acer Spin 7 **A few things to clarify (ie, things that may raise questions):** 1. Disabled deps 1. OpenPGL is disabled for now, there are a few of oddities with it (like shipping with it's own copy of embree?) that need a more in-depth look at, and would hold the PR up 2. ~~OIDN is also disabled, however support is "coming soon" (timeframe unknown): https://github.com/OpenImageDenoise/oidn/pull/183#issuecomment-1883620852~~ 3. DPCPP is also disabled - there is no Windows ARM64 support in DPCPP at present (this also means no SyCL support at present) 2. Embree 1. This is built in a weird way, as it is not possible to build it on Windows ARM64 devices with MSVC, it has to be built with LLVM. Therefore, it is built with the version of LLVM that is also built as a dep (given no DPCPP on WoA). 2. Given we build it with LLVM, and the dep version of LLVM is not always the latest that matches VS2022, we need to fall back on the VS2019 tools (which are comparatively stable), otherwise issues requiring `_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH` arise, when the VS2022 build tools are updated to a new version (and older ones marked deprecated). 3. Ninja doesn't allow specifying a different version of the build tools than the ones in the parent, so we have to fall back to using the VS generator instead. 4. I did try to comment this as best as I could, feedback welcome. 3. `harvest.cmake` 1. I have no idea what this `DEPENDS` is supposed to be on L24 - unless it's commented out, CMake gives me an error that it's undefined? 4. LLVM 1. As I need to build embree with LLVM (see point 2), I have moved a few things about to allow `lld` to be built on WoA devices, as it's needed to compile embree. 5. Python 1. I had to split the diff file into seperate x64 and arm64 ones, as otherwise we end up with both arches being built on both platforms (x64 and arm64). 6. MSYS2 1. I stopped msys2 updating itself when run (which probably should have been the default behaviour anyway when I made the PR last year) - versions as of ~2 months ago started to randomly hang on WoA machines - this keeps a known working version. 7. Vulkan 1. This doesn't run on current-gen WoA devices anyway, unless you use Dozen via Mesa, but it seems to work (until it fails on some checks, as support for `dualSrcBlend` and `logicOp` is missing right now), so I left it as-is. 8. TBB 1. As USD is still forcing us to use 2020.3, I've had to backport ARM64 support to this version. Once an update to a newer version is made, all my TBB stuff can be deleted as it works OOB with newer versions on WoA. 9. USD 1. See above - also I will upstream my changes to this in the future, but I am waiting on some issues I opened to be resolved first. 10. `make.bat` 1. ~~I modified this to have an extra arg "own_vcvars" - it made life easier during development when I was using some rather bleeding-edge versions of MSVC at times 2. I can remove this if required, but it might be useful in the future elsewhere for someone~~ 11. New MSVC preprocessor 1. This is required for MSVC+sse2neon - I included a few portable fixes should you ever wish to enable this on x64 devices (IIRC newer C++ standards on MSVC enable parts automatically anyway?) 12. NEON 1. MSVC is very strict to the C standards, and doesn't allow initialising unions to anything but the first stated type - I had to make a few changes around this 2. I also changed a few other parts to use the relevant methods such as `vsetq_lane_f32` instead of directly indexing, which MSVC doesn't like. 13. `draw_manager.cc` 1. For some reason, which I can't figure out, if the uninitialised data pattern was run (ie release asserts enabled), the viewport just gave up rendering anything 14. CPUID 1. No CPUID instruction on ARM64 so I pull the processor details from the registry instead Any more questions, queries, comments, or concerns - please do ask. I anticipate there may be a few. # Testing ## Test suite Several tests fail: ``` 95% tests passed, 15 tests failed out of 322 Total Test time (real) = 526.87 sec The following tests FAILED: 48 - io_wavefront (Failed) 86 - constraints (Failed) 88 - bl_animation_armature (Exit code 0xc0000409) 99 - cycles_bsdf_cpu (Failed) 102 - cycles_hair_cpu (Failed) 108 - cycles_light_cpu (Failed) 111 - cycles_mesh_cpu (Failed) 115 - cycles_principled_cpu (Failed) 116 - cycles_render_layer_cpu (Failed) 117 - cycles_reports_cpu (Failed) 118 - cycles_shader_cpu (Failed) 120 - cycles_sss_cpu (Failed) 121 - cycles_volume_cpu (Failed) 125 - compositor_filter_cpu (Failed) 320 - imbuf_save (Exit code 0xc0000409) Errors while running CTest ``` At least some of these cycles failures are complaining due to a lack of OIDN. Others (`subsurface base color mix` for example) do appear to be genuine failures. There appears to be one precision related, I suspect the tolerances could be adjusted? Might be because I set `/fp:fast`, or loss of precision via sse2neon. ## Testing this PR/Machine setup I believe Francesco has been sent 2x WoA (Volterra) machines by MS. You will need to install **VS2022** with the following options: ``` Selections: Desktop Development with C++ Individual: C++/CLI suport for v142 build tools (v14.29-16.11) C++/CLI suport for v143 build tools (latest) MSBuild support for LLVM (clang-cl) toolset MSVC v142 - VS 2019 C++ ARM64 build tools (v14.29-16.11) C++ MFC for latest v143 build tools (ARM64/ARM64EC) C++ v14.29 (16.11) ATL for v142 build tools (ARM64) C++ v14.29 (16.11) MFC for v142 build tools (ARM64) ``` You also need to download the latest adreno driver (contains compute shader support): https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-8-series-mobile-compute-platforms/snapdragon-8cx-gen-3-compute-platform#Software I also have one WoA machine at home I am willing to give access to - probably someone who won't be able to access the above mentioned ones that are likely at Blender HQ. I would need a WireGuard public key for this, and it would be via RDP. If people want to skip the deps build bit, I can provide a prebuilt `lib` folder - just ask :) If you just want a prebuilt to play with, a nightly is available from our CI here (link at bottom of page): https://linaro.atlassian.net/wiki/spaces/WOAR/pages/28769779775/Blender # Additional Notes * ~~Linking seems to take upwards of 25 mins~~ * The viewport flickers sometimes when zoomed in (clay view, textured view is fine) - difficult to reproduce, but happens from time to time. * ~~"Denoise" needs to be unchecked under "render", otherwise cycles won't render anything (see #115200)~~ * There is a shader compiler issue which will have a BSP update out in due course - the effect is noticeable on the 3.3 splash in the viewport, where meshes fail to render in some cases
Anthony Roberts added 1 commit 2024-01-11 17:41:38 +01:00
Sergey Sharybin requested review from Brecht Van Lommel 2024-01-11 18:01:46 +01:00
Sergey Sharybin requested review from Sergey Sharybin 2024-01-11 18:01:46 +01:00
Sergey Sharybin requested review from Campbell Barton 2024-01-11 18:01:51 +01:00
Author
Member

test\cycles\cpu\reports folder attached, alongside log_Release.txt

`test\cycles\cpu\reports` folder attached, alongside `log_Release.txt`
Campbell Barton reviewed 2024-01-12 04:49:29 +01:00
Campbell Barton left a comment
Owner

Checked over the patch and don't see any issues, also tested the patch doesn't impact Linux. Only noted a minor issue (inline).

Checked over the patch and don't see any issues, also tested the patch doesn't impact Linux. Only noted a minor issue (inline).
@ -87,3 +87,3 @@
/* Alignment directive */
#ifdef _WIN64
# define ALIGN_STRUCT __declspec(align(64))
# define BLN_ALIGN_STRUCT __declspec(align(64))

Should be: BLI_ALIGN_STRUCT

Should be: `BLI_ALIGN_STRUCT`
Anthony-Roberts marked this conversation as resolved
Brecht Van Lommel requested changes 2024-01-12 12:08:25 +01:00
Dismissed
Brecht Van Lommel left a comment
Owner

I only reviewed the changes outside build_files/build_environment so far.

I only reviewed the changes outside `build_files/build_environment` so far.
CMakeLists.txt Outdated
@ -606,3 +606,3 @@
# NVIDIA CUDA & OptiX
if(NOT APPLE)
if(NOT APPLE AND NOT (WIN32 AND "${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "ARM64"))

"${CMAKE_SYSTEM_PROCESSOR}" can just be CMAKE_SYSTEM_PROCESSOR, here and in other places.

``"${CMAKE_SYSTEM_PROCESSOR}"`` can just be `CMAKE_SYSTEM_PROCESSOR`, here and in other places.
Anthony-Roberts marked this conversation as resolved
CMakeLists.txt Outdated
@ -641,3 +641,3 @@
# AMD HIP
if(NOT APPLE)
if(NOT APPLE AND NOT (WIN32 AND "${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "ARM64"))

The same check needs to be done for oneAPI a bit lower in this file.

The same check needs to be done for oneAPI a bit lower in this file.
Anthony-Roberts marked this conversation as resolved
CMakeLists.txt Outdated
@ -2126,6 +2126,11 @@ set(CMAKE_CXX_EXTENSIONS OFF)
# of the C++ standard chosen above.
if(MSVC)
string(APPEND CMAKE_CXX_FLAGS " /Zc:__cplusplus")
string(APPEND CMAKE_C_FLAGS " /Zc:__cplusplus")

I don't think __cplusplus for C code makes sense?

I don't think `__cplusplus` for C code makes sense?
Author
Member

ACK, not sure how that one slipped through

ACK, not sure how that one slipped through
Anthony-Roberts marked this conversation as resolved
CMakeLists.txt Outdated
@ -2127,2 +2127,4 @@
if(MSVC)
string(APPEND CMAKE_CXX_FLAGS " /Zc:__cplusplus")
string(APPEND CMAKE_C_FLAGS " /Zc:__cplusplus")
if("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "ARM64")

Add comment explaining why this is needed.

Add comment explaining why this is needed.
Anthony-Roberts marked this conversation as resolved
@ -15,1 +15,4 @@
goto par2
)
if "%1" == "2022" (
echo "Building for VS2022"

Various indentation in this file looks off.

Various indentation in this file looks off.
Author
Member

The indentation here was made to exactly match the indentation of similar if statements in the rest of the file.

IMO, would be better to have a seperate task/issue to clean up the indentation in this file

The indentation here was made to exactly match the indentation of similar if statements in the rest of the file. IMO, would be better to have a seperate task/issue to clean up the indentation in this file

I think it's mixed use of tabs and spaces, maybe you just need to change your code from one to the other?

I think it's mixed use of tabs and spaces, maybe you just need to change your code from one to the other?
Author
Member

Mixed use is already in this file on the main branch, I matched the mix (tabs in orange): https://i.imgur.com/ke3pmpf.png

Would you rather I be consistent with the rest of the file, or consistent within my own addition?

Mixed use is already in this file on the main branch, I matched the mix (tabs in orange): [https://i.imgur.com/ke3pmpf.png](https://i.imgur.com/ke3pmpf.png) Would you rather I be consistent with the rest of the file, or consistent within my own addition?

Let's ignore it for now then and leave this as is.

Let's ignore it for now then and leave this as is.
Anthony-Roberts marked this conversation as resolved
@ -771,3 +771,3 @@
# define LZO_ARCH_I086 1
# define LZO_INFO_ARCH "i086"
#elif defined(__aarch64__)
#elif defined(__aarch64__) || defined(_M_ARM64)

Update extern/lzo/README.blender mentioning these modifications.

Update `extern/lzo/README.blender` mentioning these modifications.
Anthony-Roberts marked this conversation as resolved
@ -68,6 +68,13 @@ elseif(NOT WITH_CPU_SIMD OR (SUPPORT_NEON_BUILD AND SSE2NEON_FOUND))
set(CXX_HAS_SSE FALSE)
set(CXX_HAS_AVX FALSE)
set(CXX_HAS_AVX2 FALSE)
if((SUPPORT_NEON_BUILD AND SSE2NEON_FOUND) AND WIN32 AND MSVC)

Can you add this as its own case one level higher?

elseif(WIN32 AND MSVC AND SUPPORT_NEON_BUILD AND SSE2NEON_FOUND)
  ...
elseif(NOT WITH_CPU_SIMD OR (SUPPORT_NEON_BUILD AND SSE2NEON_FOUND))
  ...
elseif(...)

For me it's more clear that way, even if it duplicates set(CXX_HAS_SSE FALSE) etc.

Can you add this as its own case one level higher? ``` elseif(WIN32 AND MSVC AND SUPPORT_NEON_BUILD AND SSE2NEON_FOUND) ... elseif(NOT WITH_CPU_SIMD OR (SUPPORT_NEON_BUILD AND SSE2NEON_FOUND)) ... elseif(...) ``` For me it's more clear that way, even if it duplicates `set(CXX_HAS_SSE FALSE)` etc.
Anthony-Roberts marked this conversation as resolved
@ -1221,0 +1220,4 @@
#if defined(_M_ARM64)
# define KERNEL_STRUCT_BEGIN(name, parent) __declspec(align(16)) struct name {
#else
# define KERNEL_STRUCT_BEGIN(name, parent) struct name {

Can you add ccl_align(16) for all platforms, instead of making this specific to windows arm64? We are already aiming to do this.

Can you add `ccl_align(16)` for all platforms, instead of making this specific to windows arm64? We are already aiming to do this.
Anthony-Roberts marked this conversation as resolved
@ -211,0 +217,4 @@
uint8x16_t idx = *(uint8x16_t *)tbl;
return type(vqtbl2q_s8(t, idx));
# else
return type(vqtbl2q_s8(int8x16x2_t{int8x16_t(a), int8x16_t(b)}, *(uint8x16_t *)tbl));

Isn't this the same code, just written out over more lines? If this is needed to work around some compiler issue, you can just replace the existing code.

Isn't this the same code, just written out over more lines? If this is needed to work around some compiler issue, you can just replace the existing code.
Author
Member

It is working around a compiler issue here - MSVC's arm64_neon.h is built up of layers upon layers of macros, and doing it inline gets lost in translation somewhere.

Was trying to not pull other compilers into MSVC's mess, but can remove the ifdef, no problem

It is working around a compiler issue here - MSVC's `arm64_neon.h` is built up of layers upon layers of macros, and doing it inline gets lost in translation somewhere. Was trying to not pull other compilers into MSVC's mess, but can remove the ifdef, no problem
Anthony-Roberts marked this conversation as resolved
@ -99,0 +107,4 @@
&vendorIdentifier,
&vendorIdentifierLength) != ERROR_SUCCESS)
{
return NULL;

Don't return NULL, it should fall back to return "Unknown CPU" below.

So:

if(RegGetValueA(..) == ERROR_SUCCESS) {
  retrun vendorIdentifier;
}
#else
Don't return NULL, it should fall back to `return "Unknown CPU"` below. So: ``` if(RegGetValueA(..) == ERROR_SUCCESS) { retrun vendorIdentifier; } #else ```
Anthony-Roberts marked this conversation as resolved
make.bat Outdated
@ -44,3 +44,2 @@
if "%BUILD_VS_YEAR%" == "" (
call "%BLENDER_DIR%\build_files\windows\autodetect_msvc.cmd"
if "%USE_OWN_VCVARS%" == "1" (

This feature should be its own pull request I think, and left out from this one.

This feature should be its own pull request I think, and left out from this one.
Author
Member

I'll remove this at the last minute once all other reviews are done - need to do some adjustments on our temporary internal CI before I just straight up remove it

I'll remove this at the last minute once all other reviews are done - need to do some adjustments on our temporary internal CI before I just straight up remove it
Anthony-Roberts marked this conversation as resolved
@ -142,2 +143,4 @@
return brand;
}
#else
return BLI_windows_get_processor_manufacturer();

The regular case uses BLI_strdup which is to be freed by the caller. This case does not currently, and should be made to work the same.

The regular case uses `BLI_strdup` which is to be freed by the caller. This case does not currently, and should be made to work the same.
Anthony-Roberts marked this conversation as resolved
@ -412,2 +412,4 @@
BLI_mutex_lock(spin);
#elif defined(_MSC_VER)
# if defined(_M_ARM64)
while (InterlockedExchangeAcquire((volatile long *)spin, 1)) {

Maybe add static_assertt(sizeof(long) == sizeof(SpinLock));to be sure.

Maybe add `static_assertt(sizeof(long) == sizeof(SpinLock));`to be sure.
Anthony-Roberts marked this conversation as resolved
@ -490,0 +502,4 @@
return NULL;
}
return vendorIdentifier;

You can't return the address of a stack variable like this.

I suggest to move this code into BLI_cpu_brand_string instead of adding a new function.

You can't return the address of a stack variable like this. I suggest to move this code into `BLI_cpu_brand_string` instead of adding a new function.
Anthony-Roberts marked this conversation as resolved
@ -48,3 +48,3 @@
layer_attributes.clear();
#ifndef NDEBUG
#if !defined(NDEBUG) && !defined(_M_ARM64)

Add a comment explaining why this is here.

Add a comment explaining why this is here.
Anthony-Roberts marked this conversation as resolved

test\cycles\cpu\reports folder attached, alongside log_Release.txt

I expect some failures will be resolved by upgrading to latest sse2neon with this:
https://github.com/DLTcollab/sse2neon/pull/626

> `test\cycles\cpu\reports` folder attached, alongside `log_Release.txt` I expect some failures will be resolved by upgrading to latest sse2neon with this: https://github.com/DLTcollab/sse2neon/pull/626

I looked at the build_files/build_environment part too, and didn't really see anything wrong with it. Obviously the extra code and especially patches is going to cause some extra maintenance cost, and may break the build. As long as we are not making official builds I guess it's fine and we can treat it the same as the Linux Arm support, in that we don't actively test it but keep the code in place.

@LazyDodo would certainly need to take a lot at that all the build stuff before this lands.

The changes to source, intern and extern I could land without much trouble before the full thing is reviewed, to get that out of the way if the other parts take longer.

I looked at the `build_files/build_environment` part too, and didn't really see anything wrong with it. Obviously the extra code and especially patches is going to cause some extra maintenance cost, and may break the build. As long as we are not making official builds I guess it's fine and we can treat it the same as the Linux Arm support, in that we don't actively test it but keep the code in place. @LazyDodo would certainly need to take a lot at that all the build stuff before this lands. The changes to `source`, `intern` and `extern` I could land without much trouble before the full thing is reviewed, to get that out of the way if the other parts take longer.
Member

Think it'll be good to know what the plans are at the foundation? are we expected to take over maintenance as this lands, or is this more akin to the linux arm support, couple of patches we don't really keep an eye on, and if there's issues with them, we'll happily take a patch?

if there is a chance we'll have to maintain it, it'll be quite a different review compared to "well, this doesn't seem break any of my stuff, so lgtm"

Think it'll be good to know what the plans are at the foundation? are we expected to take over maintenance as this lands, or is this more akin to the linux arm support, couple of patches we don't really keep an eye on, and if there's issues with them, we'll happily take a patch? if there is a chance we'll have to maintain it, it'll be quite a different review compared to "well, this doesn't seem break any of _my_ stuff, so lgtm"
Anthony Roberts added 3 commits 2024-01-16 11:38:46 +01:00
Anthony Roberts requested review from Brecht Van Lommel 2024-01-16 12:01:34 +01:00

Think it'll be good to know what the plans are at the foundation? are we expected to take over maintenance as this lands, or is this more akin to the linux arm support, couple of patches we don't really keep an eye on, and if there's issues with them, we'll happily take a patch?

It's like the Linux ARM support at this point.

There has been increasing demand from users and companies to get it officially supported. But if and when we get there it's a separate decision to make and things to be figured out if we agree to go ahead with it.

> Think it'll be good to know what the plans are at the foundation? are we expected to take over maintenance as this lands, or is this more akin to the linux arm support, couple of patches we don't really keep an eye on, and if there's issues with them, we'll happily take a patch? It's like the Linux ARM support at this point. There has been increasing demand from users and companies to get it officially supported. But if and when we get there it's a separate decision to make and things to be figured out if we agree to go ahead with it.
Anthony Roberts added 1 commit 2024-01-19 15:49:02 +01:00
Merge remote-tracking branch 'origin/main' into woa-upstream
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
cb6bb00979
Author
Member

Looks like updating sse2neon didn't do much - I suspect because I have disabled it in blenlib for now, as MSVC/sse2neon requires full C++, whereas bits of blenlib are still C.

Test failures the same bar bl_animation_armature, which now appears to be fixed.

Looks like updating sse2neon didn't do much - I suspect because I have disabled it in blenlib for now, as MSVC/sse2neon requires full C++, whereas bits of blenlib are still C. Test failures the same bar bl_animation_armature, which now appears to be fixed.

@blender-bot build

@blender-bot build
Ray molenkamp requested changes 2024-01-20 02:57:10 +01:00
Dismissed
Ray molenkamp left a comment
Member

not a full review, got only half way (give or take) also a local build is still running, something will likely shake out of that as well, what i'm saying is, i'll likely ask for more changes in the future.

not a full review, got only half way (give or take) also a local build is still running, something will likely shake out of that as well, what i'm saying is, i'll likely ask for more changes in the future.
CMakeLists.txt Outdated
@ -606,3 +606,3 @@
# NVIDIA CUDA & OptiX
if(NOT APPLE)
if(NOT APPLE AND NOT (WIN32 AND CMAKE_SYSTEM_PROCESSOR MATCHES ARM64))
Member

There's a bit of a mix and match of BLENDER_PLATFORM_ARM and CMAKE_SYSTEM_PROCESSOR MATCHES ARM64 is there a reason for that?

There's a bit of a mix and match of `BLENDER_PLATFORM_ARM` and `CMAKE_SYSTEM_PROCESSOR MATCHES ARM64` is there a reason for that?
Author
Member

Yes - BLENDER_PLATFORM_ARM is part of the deps build only, but this file is the root-level CMakeLists.txt - MacOS ARM64 does the same thing

Basically:

  • Deps build - BLENDER_PLATFORM_ARM
  • Blender build - CMAKE_SYSTEM_PROCESSOR
Yes - `BLENDER_PLATFORM_ARM` is part of the deps build only, but this file is the root-level `CMakeLists.txt` - MacOS ARM64 does the same thing Basically: * Deps build - `BLENDER_PLATFORM_ARM` * Blender build - `CMAKE_SYSTEM_PROCESSOR`
Anthony-Roberts marked this conversation as resolved
@ -98,3 +98,2 @@
include(cmake/xr_openxr.cmake)
include(cmake/dpcpp.cmake)
include(cmake/dpcpp_deps.cmake)
if(NOT (WIN32 AND BLENDER_PLATFORM_ARM))
Member

i'd be ok with BLENDER_PLATFORM_WINDOWS_ARM existing,

if(NOT BLENDER_PLATFORM_WINDOWS_ARM) is a bit easier on the eyeballs than

if(NOT (WIN32 AND BLENDER_PLATFORM_ARM))

i'd be ok with `BLENDER_PLATFORM_WINDOWS_ARM` existing, `if(NOT BLENDER_PLATFORM_WINDOWS_ARM)` is a bit easier on the eyeballs than `if(NOT (WIN32 AND BLENDER_PLATFORM_ARM))`
Anthony-Roberts marked this conversation as resolved
@ -63,2 +45,2 @@
${EMBREE_EXTRA_ARGS}
)
if(BLENDER_PLATFORM_ARM)
set(EMBREE_LLVM_INSTALL_PATH ${LIBDIR}/llvm)
Member

This bit gives me the Heebie Jeebies, it's so noisy, i'd almost prefer a embree_windows_arm.cmake here, @brecht do you have any strong feelings here?

This bit gives me the Heebie Jeebies, it's _so_ noisy, i'd almost prefer a `embree_windows_arm.cmake` here, @brecht do you have any strong feelings here?

No strong opinion, I'm fine if this is moved to its own file.

No strong opinion, I'm fine if this is moved to its own file.
Anthony-Roberts marked this conversation as resolved
@ -22,3 +22,2 @@
${CMAKE_COMMAND} -E copy ${LIBDIR}/png/lib/libpng16_static.lib ${HARVEST_TARGET}/png/lib/libpng.lib &&
${CMAKE_COMMAND} -E copy_directory ${LIBDIR}/png/include/ ${HARVEST_TARGET}/png/include/ &&
DEPENDS
${CMAKE_COMMAND} -E copy_directory ${LIBDIR}/png/include/ ${HARVEST_TARGET}/png/include/ #&&
Member

just clean this up rather than comment it

just clean this up rather than comment it
Author
Member

I was unsure if this was needed for other platforms (which I lack), hence my hesitation to straight-up remove it - is it required for them?

I was unsure if this was needed for other platforms (which I lack), hence my hesitation to straight-up remove it - is it required for them?
Anthony-Roberts marked this conversation as resolved
@ -152,3 +152,3 @@
harvest(level-zero/lib level-zero/lib "*${SHAREDLIBEXT}*")
endif()
harvest(llvm/bin llvm/bin "clang-format")
harvest(llvm/bin llvm/bin "clang-format")
Member

unintended white space change?

unintended white space change?
Anthony-Roberts marked this conversation as resolved
@ -294,3 +294,1 @@
# We do not need anything from the resources folder, but the MaterialX config
# file will complain if the folder does not exist, so just copy the readme.md
# files to ensure the folder will exist.
# We do not need anything from the resources folder, but the MaterialX config
Member

unintended white space change?

unintended white space change?
Anthony-Roberts marked this conversation as resolved
Ray molenkamp reviewed 2024-01-20 19:15:42 +01:00
@ -38,1 +38,4 @@
set(EMBREE_GENERATOR ${PLATFORM_ALT_GENERATOR})
set(EMBREE_PATCH_COMMAND ${PATCH_CMD} -p 1 -d ${BUILD_DIR}/embree/src/external_embree < ${PATCH_DIR}/embree.diff)
set(EMBREE_GENERATOR_TOOLSET ${CMAKE_GENERATOR_TOOLSET})
Member

This needs to move inside the

  if(WIN32)
    # Levels below -O2 don't work well for Embree+SYCL.
    if(BLENDER_PLATFORM_ARM)

section below, specifying a toolset for the ninja generator isn't allowed this breaking the x64 build.

This needs to move inside the ``` if(WIN32) # Levels below -O2 don't work well for Embree+SYCL. if(BLENDER_PLATFORM_ARM) ``` section below, specifying a toolset for the ninja generator isn't allowed this breaking the x64 build.
Anthony-Roberts marked this conversation as resolved
Ray molenkamp reviewed 2024-01-20 21:23:37 +01:00
@ -122,1 +179,4 @@
)
if(NOT BLENDER_PLATFORM_ARM)
ExternalProjext_Add_Step(external_embree after_install
Member

typo ExternalProject_Add_Step

typo `ExternalProject_Add_Step`
Anthony-Roberts marked this conversation as resolved
Jesse Yurkovich reviewed 2024-01-24 06:32:25 +01:00
CMakeLists.txt Outdated
@ -2129,1 +2132,4 @@
string(APPEND CMAKE_CXX_FLAGS " /Zc:preprocessor")
string(APPEND CMAKE_C_FLAGS " /Zc:preprocessor")
endif()
endif()

Two questions:
I've always wondered why this MSVC-ism is here in the main CMakeLists.txt rather than inside platform_win32.cmake with its 2 friends: /permissive- and /Zc:inline? Would it make sense to have a common section there that is for all these standards-related switches?

And secondly, it's really odd that USD and co. does not support the standards compliant preprocessor. Especially considering that it builds fine with gcc/clang and their preprocessors. Will there be an upstream bug on this, and more generally, where will we keep the list of upstream bugs in general?

Two questions: I've always wondered why this MSVC-ism is here in the main CMakeLists.txt rather than inside platform_win32.cmake with its 2 friends: `/permissive-` and `/Zc:inline`? Would it make sense to have a common section there that is for all these standards-related switches? And secondly, it's really odd that USD and co. does not support the standards compliant preprocessor. Especially considering that it builds fine with gcc/clang and their preprocessors. Will there be an upstream bug on this, and more generally, where will we keep the list of upstream bugs in general?
Author
Member

I actually have no idea - I just added this bit to go alongside the other /Zc: flag - it appears to have been the case that this was here in the codebase for at least 3 years.

Internally I have a ticket to upstream the ARM64 changes once USD has resolved a few issues I have reported (deps updates). For you guys, I have no idea what the best practise is. I have tried to leave comments there issues can be resolved in the future (ie, when blenlib becomes C++, sse2neon can be enabled).

For USD preproc failure - this is mostly down to a number of preprocessor statements that are basically #if MSVC then do a bunch of windows stuff else do a bunch of linux stuff from memory, and it was a little complicated to untangle - it was easier to just use remove_cc_flag as is done in other parts of blender's codebase.

I actually have no idea - I just added this bit to go alongside the other `/Zc:` flag - it appears to have been the case that this was here in the codebase for at least 3 years. Internally I have a ticket to upstream the ARM64 changes once USD has resolved a few issues I have reported (deps updates). For you guys, I have no idea what the best practise is. I have tried to leave comments there issues can be resolved in the future (ie, when blenlib becomes C++, sse2neon can be enabled). For USD preproc failure - this is mostly down to a number of preprocessor statements that are basically `#if MSVC` then `do a bunch of windows stuff` else `do a bunch of linux stuff` from memory, and it was a little complicated to untangle - it was easier to just use `remove_cc_flag` as is done in other parts of blender's codebase.
Anthony Roberts added 6 commits 2024-01-26 10:51:16 +01:00
Versions of Mesa < 24.0.0 had broken shader parameters on WoA devices
This essentially merges `WIN32 AND BLENDER_PLATFORM_ARM` to make things a little nicer to read in places.

Replaced above checks where it made sense in terms of reducing indentation and making things easier to read
Anthony Roberts requested review from Ray molenkamp 2024-01-26 14:28:01 +01:00
Ray molenkamp reviewed 2024-02-01 21:07:32 +01:00
@ -628,3 +642,2 @@
set(BOOST_34_TRIGGER_FILE ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_python${_PYTHON_VERSION_NO_DOTS}-${BOOST_DEBUG_POSTFIX}.lib)
if(NOT EXISTS ${BOOST_34_TRIGGER_FILE})
set(BOOST_DEBUG_POSTFIX "vc142-mt-gd-x64-${BOOST_VERSION}")
if (NOT EXISTS ${BOOST_34_TRIGGER_FILE})
Member

Is this working as expected? This if is handling the existence of the 3.3 library folder?

Is this working as expected? This if is handling the existence of the 3.3 library folder?
Author
Member

Yes, we have been building libs for a while now, and the transition hit us at the time too internally.

IIRC it is set in the if block above, so I can remove this if required - I don't think there is the risk of a conflict at this point, due to no prebuilts being available for ARM64, so any new builds as of now would not need this.

Yes, we have been building libs for a while now, and the transition hit us at the time too internally. IIRC it is set in the if block above, so I can remove this if required - I don't think there is the risk of a conflict at this point, due to no prebuilts being available for ARM64, so any new builds as of now would not need this.
Anthony-Roberts marked this conversation as resolved
Anthony Roberts added 5 commits 2024-02-20 13:51:48 +01:00

All my comments have been addressed, and I didn't sport further issues. So this looks good to me.

But this will need to be merged with main for the Git LFS changes. That's also required to be able to check this PR on the buildbot.

It should be relatively straightforward now to create a blender/lib-windows_arm64 repository for libraries too, but probably the changes for that are best left to another PR.

All my comments have been addressed, and I didn't sport further issues. So this looks good to me. But this will need to be merged with main for the Git LFS changes. That's also required to be able to check this PR on the buildbot. It should be relatively straightforward now to create a `blender/lib-windows_arm64` repository for libraries too, but probably the changes for that are best left to another PR.
Member

It's been a while since i validated this doesn't break anything for x64, so once main gets merged i'll do one final pass, and then this should be ready to go from my end as well.

It's been a while since i validated this doesn't break anything for x64, so once main gets merged i'll do one final pass, and then this should be ready to go from my end as well.
Author
Member

I have a job running on our internal CI here for the LFS changes: https://gitlab.com/Linaro/windowsonarm/packages/blender/-/jobs/6280161159

Fingers crossed it builds fine, if it does I should have the merge etc upstreamed to here tomorrow or the day after

I have a job running on our internal CI here for the LFS changes: https://gitlab.com/Linaro/windowsonarm/packages/blender/-/jobs/6280161159 Fingers crossed it builds fine, if it does I should have the merge etc upstreamed to here tomorrow or the day after
Anthony Roberts added 2 commits 2024-03-01 11:24:27 +01:00
Anthony Roberts added 1 commit 2024-03-01 18:08:58 +01:00
Merge remote-tracking branch 'origin/main' into woa-upstream
Some checks failed
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
ce696b435a
Author
Member

This should now all be ready for testing - I did leave a few things unresolved in review comments, where responses would be appreciated

This should now all be ready for testing - I did leave a few things unresolved in review comments, where responses would be appreciated

@blender-bot build

@blender-bot build
Author
Member

@brecht Other than the linter, are those failures due to my patch? I can't see a reason for failure, for example, on the linux build due to my changes (I could be wrong)

@brecht Other than the linter, are those failures due to my patch? I can't see a reason for failure, for example, on the linux build due to my changes (I could be wrong)

@Anthony-Roberts The Linux failure seems to be something that was introduced a few days ago, and got fixed later. Merging the current state of the main branch should fix that. The render tests failure i am not sure yet, but maybe check on them if they still fail after the main merge.

@Anthony-Roberts The Linux failure seems to be something that was introduced a few days ago, and got fixed later. Merging the current state of the `main` branch should fix that. The render tests failure i am not sure yet, but maybe check on them if they still fail after the main merge.
Brecht Van Lommel requested changes 2024-03-05 11:37:00 +01:00
Dismissed
Brecht Van Lommel left a comment
Owner

Since the tests are only failing on arm64, I think it's quite likely due to one of the changes in Cycles. Pointed out a possible cause.

Since the tests are only failing on arm64, I think it's quite likely due to one of the changes in Cycles. Pointed out a possible cause.
@ -33,2 +32,3 @@
${HARVEST_TARGET}/png/include/ #&&
DEPENDS
#DEPENDS

This wrong code can just be removed instead of commented out?

This wrong code can just be removed instead of commented out?
Author
Member

I think my hesitation here was if it was needed on other platforms, but it seems not - has this issue not been run into by anyone else?

I think my hesitation here was if it was needed on other platforms, but it seems not - has this issue not been run into by anyone else?

This code is for Windows only, I think it should be fine to just remove it..

This code is for Windows only, I think it should be fine to just remove it..
Author
Member

Done

Done
Anthony-Roberts marked this conversation as resolved
@ -456,3 +456,3 @@
#if defined(__KERNEL_SSE__) && defined(__KERNEL_NEON__)
__m128 t = a.m128;
t[3] = 0.0f;
vsetq_lane_f32(0.0f, t, 3);

Should be t = vsetq_lane_f32(0.0f, t, 3);

Should be `t = vsetq_lane_f32(0.0f, t, 3);`
Author
Member

ACK, will fix on next push

ACK, will fix on next push
Anthony-Roberts marked this conversation as resolved
@ -117,2 +117,2 @@
__m128 a;
a[0] = x;
__m128 a = {0};
vsetq_lane_f32(x, a, 0);

Should be a = vsetq_lane_f32(x, a, 0);

Should be `a = vsetq_lane_f32(x, a, 0);`
Author
Member

ACK, will fix on next push

ACK, will fix on next push
Anthony-Roberts marked this conversation as resolved
Anthony Roberts added 4 commits 2024-03-05 13:06:52 +01:00
Fix another review issue
All checks were successful
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
b9f4288649
Author
Member

Review comments addressed, make-format run - thanks for the spot on the intrinsic error, it's reduced the failures on WoA down to the following too:

98% tests passed, 3 tests failed out of 120

Total Test time (real) = 214.26 sec

The following tests FAILED:
         50 - io_wavefront (Failed)
         52 - io_stl (Failed)
         89 - constraints (Failed)
Errors while running CTest
Review comments addressed, make-format run - thanks for the spot on the intrinsic error, it's reduced the failures on WoA down to the following too: ``` 98% tests passed, 3 tests failed out of 120 Total Test time (real) = 214.26 sec The following tests FAILED: 50 - io_wavefront (Failed) 52 - io_stl (Failed) 89 - constraints (Failed) Errors while running CTest ```
Anthony Roberts requested review from Brecht Van Lommel 2024-03-05 13:16:43 +01:00

@blender-bot build

@blender-bot build
Brecht Van Lommel approved these changes 2024-03-05 14:55:36 +01:00
Ray molenkamp approved these changes 2024-03-06 06:06:08 +01:00
Campbell Barton approved these changes 2024-03-06 07:29:11 +01:00
Campbell Barton reviewed 2024-03-06 07:32:31 +01:00
@ -115,1 +119,3 @@
set(PLATFORM_CMAKE_FLAGS)
if(BLENDER_PLATFORM_ARM)
# In some cases on ARM64 (unsure why), dep builds using the "Ninja" generator appear to use the x86 host tools

Lines shouldn't exceed 99 column width.

Lines shouldn't exceed 99 column width.
Author
Member

Fixed

Fixed
Anthony-Roberts marked this conversation as resolved
Anthony Roberts added 1 commit 2024-03-06 10:31:49 +01:00
Author
Member

All comments addressed, build bots passed, approvals done - is this ready to go in?

All comments addressed, build bots passed, approvals done - is this ready to go in?

I'll land this.

I've created #119126 to track remaining work, feel free to edit it as needed.

@Anthony-Roberts, I assume you want commit rights to continue maintaining this functionality and commit precompiled libraries? If so, @ThomasDinges, can you set this up?

I'll land this. I've created #119126 to track remaining work, feel free to edit it as needed. @Anthony-Roberts, I assume you want commit rights to continue maintaining this functionality and commit precompiled libraries? If so, @ThomasDinges, can you set this up?
Brecht Van Lommel manually merged commit 445fd42c61 into main 2024-03-06 16:17:16 +01:00
Author
Member

@brecht Yes, I'll continue maintaining this - I believe questions of CI, etc are ongoing discussions with @fsiddi

In ~3 weeks time I will be away with little-to-no connectivity on my honeymoon for a 5 week period, so will be unable to look after things during that time, but outside of that, all fine, and happy to keep on top of things

@brecht Yes, I'll continue maintaining this - I believe questions of CI, etc are ongoing discussions with @fsiddi In ~3 weeks time I will be away with little-to-no connectivity on my honeymoon for a 5 week period, so will be unable to look after things during that time, but outside of that, all fine, and happy to keep on top of things

Great.

@ThomasDinges, can you set up the commit rights then?

I've created a lib-windows_arm64 repository for the precompiled libraries, and you should be able to push there. I don't know when CI will happen, but regardless having some libraries there is a good next step towards that.

Great. @ThomasDinges, can you set up the commit rights then? I've created a [lib-windows_arm64](https://projects.blender.org/blender/lib-windows_arm64) repository for the precompiled libraries, and you should be able to push there. I don't know when CI will happen, but regardless having some libraries there is a good next step towards that.

@Anthony-Roberts I added you as member of the "Developers" team with git write access. You should be able to commit to blender/blender as well as blender/lib*.

@Anthony-Roberts I added you as member of the "Developers" team with git write access. You should be able to commit to blender/blender as well as blender/lib*.
Author
Member

Thanks both - I will look at landing the libs (and follow-up changes to the scripts to use the prebuilts) in the next few days!

Thanks both - I will look at landing the libs (and follow-up changes to the scripts to use the prebuilts) in the next few days!
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117036
No description provided.