griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
6a7fa2fc0fb2df7e996ccfd39ddf8045dbc96d4e
test2/intern/cycles/cmake/external_libs.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

131 lines
4.3 KiB
CMake
Raw Normal View History

License headers: use SPDX-FileCopyrightText in intern/cycles
2023-06-14 16:52:36 +10:00
# SPDX-FileCopyrightText: 2011-2022 Blender Foundation
#
File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-11 09:07:11 +11:00
# SPDX-License-Identifier: Apache-2.0
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
###########################################################################
Cycles: restore basic standalone GUI, now using SDL GLUT does not support offscreen contexts, which is required for the new display driver. So we use SDL instead. Note that this requires using a system SDL package, the Blender precompiled SDL does not include the video subsystem. There is currently no text display support, instead info is printed to the terminal. This would require adding an embedded font and GLSL shaders, or using GUI library. Another improvement to be made is supporting OpenColorIO display transforms, right now we assume Rec.709 scene linear and display. All OpenGL, GLEW and SDL code was move out of core cycles and into app/opengl. This serves as a template for apps that want to integrate Cycles interactive rendering, with a simple OpenGLDisplayDriver example. In general this would be adapted to the graphics API and color management used by the app. Ref T91846
2021-09-17 15:15:14 +02:00
# SDL
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
###########################################################################
if(WITH_CYCLES_STANDALONE AND WITH_CYCLES_STANDALONE_GUI)
Cycles: restore basic standalone GUI, now using SDL GLUT does not support offscreen contexts, which is required for the new display driver. So we use SDL instead. Note that this requires using a system SDL package, the Blender precompiled SDL does not include the video subsystem. There is currently no text display support, instead info is printed to the terminal. This would require adding an embedded font and GLSL shaders, or using GUI library. Another improvement to be made is supporting OpenColorIO display transforms, right now we assume Rec.709 scene linear and display. All OpenGL, GLEW and SDL code was move out of core cycles and into app/opengl. This serves as a template for apps that want to integrate Cycles interactive rendering, with a simple OpenGLDisplayDriver example. In general this would be adapted to the graphics API and color management used by the app. Ref T91846
2021-09-17 15:15:14 +02:00
# We can't use the version from the Blender precompiled libraries because
# it does not include the video subsystem.
Cycles: various Linux build fixes related to Hydra render delegate * Add missing GLEW and hgiGL libraries for Hydra * Fix wrong case sensitive include * Fix link errors by adding external libs to static Hydra lib * Work around weird Hydra link error with MAX_SAMPLES * Use Embree by default for Hydra * Sync external libs code with standalone * Update version number to match Blender * Remove unneeded CLEW/GLEW from test executable None of this should affect Cycles in Blender. Ref T96731
2022-04-06 22:25:40 +02:00
find_package(SDL2 REQUIRED)
Build: add option to error when features can't be enabled This is to help ensure buildbot builds are correct, while still gracefully disabling features in user/developer builds. * Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be enabled due to missing libraries or other reasons. Add new macro set_and_warn_library_found used everywhere features were being automatically disabled. * Remove code from Windows and macOS for various libraries that would automatically disable features. set_and_warn_library_found could be used here also, but we are generally assuming the precompiled libraries are complete and only test for availability when libraries are just added. Differential Revision: https://developer.blender.org/D16104
2022-09-29 19:01:35 +02:00
set_and_warn_library_found("SDL" SDL2_FOUND WITH_CYCLES_STANDALONE_GUI)
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
Build: add option to error when features can't be enabled This is to help ensure buildbot builds are correct, while still gracefully disabling features in user/developer builds. * Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be enabled due to missing libraries or other reasons. Add new macro set_and_warn_library_found used everywhere features were being automatically disabled. * Remove code from Windows and macOS for various libraries that would automatically disable features. set_and_warn_library_found could be used here also, but we are generally assuming the precompiled libraries are complete and only test for availability when libraries are just added. Differential Revision: https://developer.blender.org/D16104
2022-09-29 19:01:35 +02:00
if(SDL2_FOUND)
include_directories(
SYSTEM
${SDL2_INCLUDE_DIRS}
)
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
endif()
endif()
###########################################################################
# CUDA
###########################################################################
Cycles: refactor Hydra render delegate building * Leave code for building the render delegate against other applications and their USD libraries to the Cycles repository, since this is not a great fit. In the Blender repository, always use Blender's USD libraries now that they include Hydra support. * Hide non-USD symbols from the hdCycles shared library, to avoid library version conflicts. * Share Apple framework linking between the standalone app and plugin. * Add cycles_hydra module, to be shared between the standalone app and plugin. * Bring external libs code in sync with standalone repo, adding various missing libraries. * Move some cmake include directories to the top level cycles source folder because we need to control their global order, to ensure we link against the correct headers with mixed Blender libraries and external USD libraries.
2022-04-07 20:27:23 +02:00
if(WITH_CYCLES_DEVICE_CUDA AND (WITH_CYCLES_CUDA_BINARIES OR NOT WITH_CUDA_DYNLOAD))
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
find_package(CUDA) # Try to auto locate CUDA toolkit
Build: add option to error when features can't be enabled This is to help ensure buildbot builds are correct, while still gracefully disabling features in user/developer builds. * Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be enabled due to missing libraries or other reasons. Add new macro set_and_warn_library_found used everywhere features were being automatically disabled. * Remove code from Windows and macOS for various libraries that would automatically disable features. set_and_warn_library_found could be used here also, but we are generally assuming the precompiled libraries are complete and only test for availability when libraries are just added. Differential Revision: https://developer.blender.org/D16104
2022-09-29 19:01:35 +02:00
set_and_warn_library_found("CUDA compiler" CUDA_FOUND WITH_CYCLES_CUDA_BINARIES)
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
if(CUDA_FOUND)
Cycles: improve detection of HIP compiler for buildbot And fix various broken things in the HIP kernel compilation.
2021-10-05 13:08:44 +02:00
message(STATUS "Found CUDA ${CUDA_NVCC_EXECUTABLE} (${CUDA_VERSION})")
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
else()
if(NOT WITH_CUDA_DYNLOAD)
message(STATUS "Additionally falling back to dynamic CUDA load")
set(WITH_CUDA_DYNLOAD ON)
endif()
endif()
Cycles: Synchronize changes with standalone repository This changes were done in original commit of the standalone Cycles repository and needed here for easier patch synchronization.
2014-12-29 14:48:21 +05:00
endif()
Fix build without Cycles HIP device
2021-09-28 19:55:25 +02:00
###########################################################################
# HIP
###########################################################################
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 19:05:30 +02:00
if(WITH_CYCLES_DEVICE_HIP)
Cycles: HIP-RT 2.5 integration and gfx12 support This change brings the following improvements on the user level - Support of GPUs with gfx12 architecture - New HIP-RT library which in addition to the gfx12 support brings various bug-fixes. The known limitation of gfx12 is that OpenImageDenoiser does not yet support this GPU architecture. This means that while Cycles will use the full advantage of the gfx12 (including hardware accelerated ray-tracing), denoising will only be possible on CPU, or secondary gfx11 or below GPU. This is something that requires a change in OIDN and it is to late to do it for Blender 4.4, but it is something to look forward for Blender 4.5. The gfx12 changes for the pre-compiled kernels is rather trivial, so it comes together (in the same PR) as the bigger HIP-RT change. On the development side this change brings the following improvements: - One step compile and link (much simpler CMake rules) - Embedding BVH binaries in hiprt dll (which makes it easier to package and load, without relying on special path configuration) Co-authored-by: Sahar Kashi <sahar.kashi@amd.com> Co-authored-by: Sergey Sharybin <sergey@blender.org> Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/133129
2025-02-20 17:34:14 +01:00
if(WITH_CYCLES_HIP_BINARIES)
Cycles: re-enable HIP on Linux Using the new ROCm 5.5 compiler. Ref #104786 Pull Request: https://projects.blender.org/blender/blender/pulls/107662
2023-05-05 19:36:55 +02:00
# Need at least HIP 5.5 to solve compiler bug affecting the kernel.
find_package(HIP 5.5.0)
set_and_warn_library_found("HIP compiler" HIP_FOUND WITH_CYCLES_HIP_BINARIES)
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
Cycles: re-enable HIP on Linux Using the new ROCm 5.5 compiler. Ref #104786 Pull Request: https://projects.blender.org/blender/blender/pulls/107662
2023-05-05 19:36:55 +02:00
if(HIP_FOUND)
message(STATUS "Found HIP ${HIP_HIPCC_EXECUTABLE} (${HIP_VERSION})")
Cycles: re-enable AMD GPU binaries on Windows Using the new HIP SDK 5.5 that includes a fix for the compiler bug. This also enables the light tree. For Linux the binaries are still disabled. ROCm 5.5 is planned to include the same fix but not released yet. When that happens we should be able to enable Linux as well. Ref #104786 Fix #104085 Pull Request: https://projects.blender.org/blender/blender/pulls/107098
2023-04-19 18:18:05 +02:00
endif()
endif()
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 19:05:30 +02:00
# HIP RT
if(WITH_CYCLES_DEVICE_HIP AND WITH_CYCLES_DEVICE_HIPRT)
Cycles: Linux Support for HIP-RT This change switches Cycles to an opensource HIP-RT library which implements hardware ray-tracing. This library is now used on both Windows and Linux. While there should be no noticeable changes on Windows, on Linux this adds support for hardware ray-tracing on AMD GPUs. The majority of the change is typical platform code to add new library to the dependency builder, and a change in the way how ahead-of-time (AoT) kernels are compiled. There are changes in Cycles itself, but they are rather straightforward: some APIs changed in the opensource version of the library. There are a couple of extra files which are needed for this to work: hiprt02003_6.1_amd.hipfb and oro_compiled_kernels.hipfb. There are some assumptions in the HIP-RT library about how they are available. Currently they follow the same rule as AoT kernels for oneAPI: - On Windows they are next to blender.exe - On Linux they are in the lib/ folder Performance comparison on Ubuntu 22.04.5: ``` GPU: AMD Radeon PRO W7800 Driver: amdgpu-install_6.1.60103-1_all.deb main hip-rt attic 0.1414s 0.0932s barbershop_interior 0.1563s 0.1258s bistro 0.2134s 0.1597s bmw27 0.0119s 0.0099s classroom 0.1006s 0.0803s fishy_cat 0.0248s 0.0178s junkshop 0.0916s 0.0713s koro 0.0589s 0.0720s monster 0.0435s 0.0385s pabellon 0.0543s 0.0391s sponza 0.0223s 0.0180s spring 0.1026s 1.5145s victor 0.1901s 0.1239s wdas_cloud 0.1153s 0.1125s ``` Co-authored-by: Brecht Van Lommel <brecht@blender.org> Co-authored-by: Ray Molenkamp <github@lazydodo.com> Co-authored-by: Sergey Sharybin <sergey@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/121050
2024-09-24 14:35:24 +02:00
if(DEFINED LIBDIR)
set(HIPRT_ROOT_DIR ${LIBDIR}/hiprt)
endif()
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 19:05:30 +02:00
find_package(HIPRT)
set_and_warn_library_found("HIP RT" HIPRT_FOUND WITH_CYCLES_DEVICE_HIPRT)
endif()
endif()
if(NOT WITH_CYCLES_DEVICE_HIP)
set(WITH_CYCLES_DEVICE_HIPRT OFF)
Cycles: improve detection of HIP compiler for buildbot And fix various broken things in the HIP kernel compilation.
2021-10-05 13:08:44 +02:00
endif()
Cycles: add HIP device support for AMD GPUs NOTE: this feature is not ready for user testing, and not yet enabled in daily builds. It is being merged now for easier collaboration on development. HIP is a heterogenous compute interface allowing C++ code to be executed on GPUs similar to CUDA. It is intended to bring back AMD GPU rendering support on Windows and Linux. https://github.com/ROCm-Developer-Tools/HIP. As of the time of writing, it should compile and run on Linux with existing HIP compilers and driver runtimes. Publicly available compilers and drivers for Windows will come later. See task T91571 for more details on the current status and work remaining to be done. Credits: Sayak Biswas (AMD) Arya Rafii (AMD) Brian Savery (AMD) Differential Revision: https://developer.blender.org/D12578
2021-09-28 16:51:14 +02:00
if(NOT WITH_HIP_DYNLOAD)
set(WITH_HIP_DYNLOAD ON)
endif()
CMake: refresh building and external library handling of Cycles standalone * Support precompiled libraries on Linux * Add license headers * Refactoring to deduplicate code Includes work by Ray Molenkamp and Grische for precompiled libraries. Ref D8769
2020-09-04 18:41:10 +02:00
Cycles: Metal host-side code This patch adds the Metal host-side code: - Add all core host-side Metal backend files (device_impl, queue, etc) - Add MetalRT BVH setup files - Integrate with Cycles device enumeration code - Revive `path_source_replace_includes` in util/path (required for MSL compilation) This patch also includes a couple of small kernel-side fixes: - Add an implementation of `lgammaf` for Metal [Nemes, Gergő (2010), "New asymptotic expansion for the Gamma function", Archiv der Mathematik](https://users.renyi.hu/~gergonemes/) - include "work_stealing.h" inside the Metal context class because it accesses state now Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13423
2021-12-07 15:11:35 +00:00
###########################################################################
# Metal
###########################################################################
if(WITH_CYCLES_DEVICE_METAL)
Cycles: enable Metal GPU rendering This adds the remaining bits to enable Metal on macOS. There are still performance optimizations and other improvements planned, but it should now be ready for early testing. This is currently only enabled on in Arm builds for M1 GPUs. It is not yet working on AMD or Intel GPUs. Ref T92212 Differential Revision: https://developer.blender.org/D13503
2021-12-13 13:48:36 +01:00
find_library(METAL_LIBRARY Metal)
# This file was added in the 12.0 SDK, use it as a way to detect the version.
Build: add option to error when features can't be enabled This is to help ensure buildbot builds are correct, while still gracefully disabling features in user/developer builds. * Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be enabled due to missing libraries or other reasons. Add new macro set_and_warn_library_found used everywhere features were being automatically disabled. * Remove code from Windows and macOS for various libraries that would automatically disable features. set_and_warn_library_found could be used here also, but we are generally assuming the precompiled libraries are complete and only test for availability when libraries are just added. Differential Revision: https://developer.blender.org/D16104
2022-09-29 19:01:35 +02:00
if(METAL_LIBRARY)
if(EXISTS "${METAL_LIBRARY}/Headers/MTLFunctionStitching.h")
set(METAL_FOUND ON)
else()
message(STATUS "Metal version too old, must be SDK 12.0 or newer")
set(METAL_FOUND OFF)
endif()
endif()
set_and_warn_library_found("Metal" METAL_FOUND WITH_CYCLES_DEVICE_METAL)
if(METAL_FOUND)
Cycles: enable Metal GPU rendering This adds the remaining bits to enable Metal on macOS. There are still performance optimizations and other improvements planned, but it should now be ready for early testing. This is currently only enabled on in Arm builds for M1 GPUs. It is not yet working on AMD or Intel GPUs. Ref T92212 Differential Revision: https://developer.blender.org/D13503
2021-12-13 13:48:36 +01:00
message(STATUS "Found Metal: ${METAL_LIBRARY}")
Cycles: Metal host-side code This patch adds the Metal host-side code: - Add all core host-side Metal backend files (device_impl, queue, etc) - Add MetalRT BVH setup files - Integrate with Cycles device enumeration code - Revive `path_source_replace_includes` in util/path (required for MSL compilation) This patch also includes a couple of small kernel-side fixes: - Add an implementation of `lgammaf` for Metal [Nemes, Gergő (2010), "New asymptotic expansion for the Gamma function", Archiv der Mathematik](https://users.renyi.hu/~gergonemes/) - include "work_stealing.h" inside the Metal context class because it accesses state now Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13423
2021-12-07 15:11:35 +00:00
endif()
endif()
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
###########################################################################
# oneAPI
###########################################################################
Fix compilation error with oneAPI disabled and GPU Embree enabled Happens with systems which do not provide GOLD linker: the linking state would failing with some missing symbols and print about missing libsycl.so.6. Seems that BFD linker expects to resolve all symbols, even the indirectly used ones. This is somewhat counter-intuitive and is not how LLD, GOLD, or MOLD worls. The current state of the CMakeLists.txt does request the cycles_bvh to be linked against SYCL_LIBRARIES. However, the SYCL was only requested to be found if WITH_CYCLES_DEVICE_ONEAP is true. Arguably the SYCL_LIBRARIES should only be linked-in into cycles_bvh if EMBREE_STATIC_LIB, but that does not solve the issue with BFD. This change makes it so the SYCL is requested to be found if the oneAPI device is enabled, or if the Embree is detected to require/use SYCL support. Pull Request: https://projects.blender.org/blender/blender/pulls/108965
2023-06-14 18:20:45 +02:00
if(WITH_CYCLES_DEVICE_ONEAPI OR EMBREE_SYCL_SUPPORT)
Build: Clean up oneAPI cmake messages * Always define root directories in LIBDIR even when not needed, to silence some warnings. * Only show warnings about not finding libs when oneAPI is enabled. * Prefix message for context.
2024-06-12 19:19:12 +02:00
# Find packages for even when WITH_CYCLES_DEVICE_ONEAPI is OFF, as it's
# needed for linking to Embree with SYCL support.
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
find_package(SYCL)
find_package(LevelZero)
Build: Clean up oneAPI cmake messages * Always define root directories in LIBDIR even when not needed, to silence some warnings. * Only show warnings about not finding libs when oneAPI is enabled. * Prefix message for context.
2024-06-12 19:19:12 +02:00
if(WITH_CYCLES_DEVICE_ONEAPI)
set_and_warn_library_found("oneAPI" SYCL_FOUND WITH_CYCLES_DEVICE_ONEAPI)
set_and_warn_library_found("Level Zero" LEVEL_ZERO_FOUND WITH_CYCLES_DEVICE_ONEAPI)
if(NOT (SYCL_FOUND AND SYCL_VERSION VERSION_GREATER_EQUAL 6.0 AND LEVEL_ZERO_FOUND))
message(STATUS "SYCL 6.0+ or Level Zero not found, disabling WITH_CYCLES_DEVICE_ONEAPI")
set(WITH_CYCLES_DEVICE_ONEAPI OFF)
endif()
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
endif()
endif()
Fix compilation error with oneAPI disabled and GPU Embree enabled Happens with systems which do not provide GOLD linker: the linking state would failing with some missing symbols and print about missing libsycl.so.6. Seems that BFD linker expects to resolve all symbols, even the indirectly used ones. This is somewhat counter-intuitive and is not how LLD, GOLD, or MOLD worls. The current state of the CMakeLists.txt does request the cycles_bvh to be linked against SYCL_LIBRARIES. However, the SYCL was only requested to be found if WITH_CYCLES_DEVICE_ONEAP is true. Arguably the SYCL_LIBRARIES should only be linked-in into cycles_bvh if EMBREE_STATIC_LIB, but that does not solve the issue with BFD. This change makes it so the SYCL is requested to be found if the oneAPI device is enabled, or if the Embree is detected to require/use SYCL support. Pull Request: https://projects.blender.org/blender/blender/pulls/108965
2023-06-14 18:20:45 +02:00
if(WITH_CYCLES_DEVICE_ONEAPI AND WITH_CYCLES_ONEAPI_BINARIES)
if(NOT OCLOC_INSTALL_DIR)
get_filename_component(_sycl_compiler_root ${SYCL_COMPILER} DIRECTORY)
get_filename_component(OCLOC_INSTALL_DIR "${_sycl_compiler_root}/../lib/ocloc" ABSOLUTE)
unset(_sycl_compiler_root)
endif()
if(NOT EXISTS ${OCLOC_INSTALL_DIR})
set(OCLOC_FOUND OFF)
message(STATUS "oneAPI ocloc not found in ${OCLOC_INSTALL_DIR}."
" A different ocloc directory can be set using OCLOC_INSTALL_DIR cmake variable.")
set_and_warn_library_found("ocloc" OCLOC_FOUND WITH_CYCLES_ONEAPI_BINARIES)
endif()
endif()
Reference in New Issue Copy Permalink