2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2005 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2019-10-03 16:21:23 +02:00
|
|
|
|
|
|
|
|
/** \file
|
|
|
|
|
* \ingroup gpu
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
Compositor: Support GPU OIDN denoising
This patch supports GPU OIDN denoising in the compositor. A new
compositor performance option was added to allow choosing between CPU,
GPU, and Auto device selection. Auto will use whatever the compositor is
using for execution.
The code is two folds, first, denoising code was adapted to use buffers
as opposed to passing in pointers to filters directly, this is needed to
support GPU devices. Second, device creation is now a bit more involved,
it tries to choose the device is being used by the compositor for
execution.
Matching GPU devices is done by choosing the OIDN device that matches
the UUID or LUID of the active GPU platform. We need both UUID and LUID
because not all platforms support both. UUID is supported on all
platforms except MacOS Metal, while LUID is only supported on Window and
MacOS metal.
If there is no active GPU device or matching is unsuccessful, we let
OIDN choose the best device, which is typically the fastest.
To support this case, UUID and LUID identifiers were added to the
GPUPlatformGlobal and are initialized by the GPU backend if supported.
OpenGL now requires GL_EXT_memory_object and GL_EXT_memory_object_win32
to support this use case, but it should function without it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136660
2025-04-04 11:17:08 +02:00
|
|
|
#include <cstdint>
|
|
|
|
|
#include <optional>
|
2024-09-23 11:18:24 +02:00
|
|
|
#include <string>
|
|
|
|
|
|
|
|
|
|
#include "BLI_span.hh"
|
2020-07-25 18:41:55 +02:00
|
|
|
#include "BLI_utildefines.h"
|
2019-10-03 16:21:23 +02:00
|
|
|
|
2025-01-26 20:08:03 +01:00
|
|
|
#include "GPU_platform_backend_enum.h" // IWYU pragma: export
|
2019-10-03 16:21:23 +02:00
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
/* GPU platform support */
|
2022-03-22 12:38:28 +01:00
|
|
|
|
2019-10-03 16:21:23 +02:00
|
|
|
/* GPU Types */
|
2024-03-23 01:24:18 +01:00
|
|
|
enum eGPUDeviceType {
|
2019-10-03 16:21:23 +02:00
|
|
|
GPU_DEVICE_NVIDIA = (1 << 0),
|
|
|
|
|
GPU_DEVICE_ATI = (1 << 1),
|
|
|
|
|
GPU_DEVICE_INTEL = (1 << 2),
|
|
|
|
|
GPU_DEVICE_INTEL_UHD = (1 << 3),
|
2022-04-04 16:33:33 +02:00
|
|
|
GPU_DEVICE_APPLE = (1 << 4),
|
|
|
|
|
GPU_DEVICE_SOFTWARE = (1 << 5),
|
Add check for Qualcomm devices on Windows
Some of these devices are not capable of running >=4.0, due to issues
with Mesa's Compute Shaders and their D3D drivers.
This PR marks those GPUs as unsupported, and prints info to stdout.
A driver update will be available for 8cx Gen3 on the 17th October
from here:
https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-8-series-mobile-compute-platforms/snapdragon-8cx-gen-3-compute-platform#Software
It will take longer via the standard MS Windows Update channels,
as there is certification, testing, etc required, but it is possible
to get the drivers, at least.
This issue applies even when using emulated x64.
If this does not get merged, all WoA devices will break with 4.0,
where older ones will just launch a grey screen and crash, and newer
ones will open, but scenes will not render correctly in Workbench.
These devices work by using Mesa's D3D12 Gallium driver ("GLOn12"),
which is why we have to read the DirectX driver version - the version
reported by OpenGL is the mesa version, which is independent of the
driver (which is the part with the bug).
Pull Request: https://projects.blender.org/blender/blender/pulls/113674
2023-10-20 17:18:35 +02:00
|
|
|
GPU_DEVICE_QUALCOMM = (1 << 6),
|
|
|
|
|
GPU_DEVICE_UNKNOWN = (1 << 7),
|
2019-10-03 16:21:23 +02:00
|
|
|
GPU_DEVICE_ANY = (0xff),
|
2024-03-23 01:24:18 +01:00
|
|
|
};
|
2019-10-03 16:21:23 +02:00
|
|
|
|
2020-10-01 23:51:01 +05:30
|
|
|
ENUM_OPERATORS(eGPUDeviceType, GPU_DEVICE_ANY)
|
2020-07-25 18:41:55 +02:00
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
enum eGPUOSType {
|
2019-10-03 16:21:23 +02:00
|
|
|
GPU_OS_WIN = (1 << 8),
|
|
|
|
|
GPU_OS_MAC = (1 << 9),
|
|
|
|
|
GPU_OS_UNIX = (1 << 10),
|
|
|
|
|
GPU_OS_ANY = (0xff00),
|
2024-03-23 01:24:18 +01:00
|
|
|
};
|
2019-10-03 16:21:23 +02:00
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
enum eGPUDriverType {
|
2019-10-03 16:21:23 +02:00
|
|
|
GPU_DRIVER_OFFICIAL = (1 << 16),
|
|
|
|
|
GPU_DRIVER_OPENSOURCE = (1 << 17),
|
|
|
|
|
GPU_DRIVER_SOFTWARE = (1 << 18),
|
|
|
|
|
GPU_DRIVER_ANY = (0xff0000),
|
2024-03-23 01:24:18 +01:00
|
|
|
};
|
2019-10-03 16:21:23 +02:00
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
enum eGPUSupportLevel {
|
2019-10-03 16:21:23 +02:00
|
|
|
GPU_SUPPORT_LEVEL_SUPPORTED,
|
|
|
|
|
GPU_SUPPORT_LEVEL_LIMITED,
|
|
|
|
|
GPU_SUPPORT_LEVEL_UNSUPPORTED,
|
2024-03-23 01:24:18 +01:00
|
|
|
};
|
2019-10-03 16:21:23 +02:00
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
enum GPUArchitectureType {
|
2023-09-28 12:49:55 +02:00
|
|
|
/* Immediate Mode Renderer (IMR).
|
|
|
|
|
* Typically, an IMR architecture will execute GPU work in sequence, rasterizing primitives in
|
|
|
|
|
* order. */
|
|
|
|
|
GPU_ARCHITECTURE_IMR = 0,
|
|
|
|
|
|
|
|
|
|
/* Tile-Based-Deferred-Renderer (TBDR).
|
|
|
|
|
* A TBDR architecture will typically execute the vertex stage up-front for all primitives,
|
|
|
|
|
* binning geometry into distinct tiled regions. Fragments will then be rasterized within
|
|
|
|
|
* the bounds of one tile at a time. */
|
|
|
|
|
GPU_ARCHITECTURE_TBDR = 1,
|
2024-03-23 01:24:18 +01:00
|
|
|
};
|
2020-07-27 11:40:47 +02:00
|
|
|
|
2024-10-31 15:18:29 +01:00
|
|
|
struct GPUDevice {
|
2024-09-23 11:18:24 +02:00
|
|
|
std::string identifier;
|
|
|
|
|
int index;
|
|
|
|
|
uint32_t vendor_id;
|
|
|
|
|
uint32_t device_id;
|
|
|
|
|
std::string name;
|
2024-10-31 15:18:29 +01:00
|
|
|
};
|
2024-09-23 11:18:24 +02:00
|
|
|
|
2021-12-09 20:01:47 +11:00
|
|
|
/* GPU Types */
|
2022-03-22 13:44:15 +01:00
|
|
|
/* TODO: Verify all use-cases of GPU_type_matches to determine which graphics API it should apply
|
|
|
|
|
* to, and replace with `GPU_type_matches_ex` where appropriate. */
|
2019-10-03 16:21:23 +02:00
|
|
|
bool GPU_type_matches(eGPUDeviceType device, eGPUOSType os, eGPUDriverType driver);
|
2022-03-22 13:44:15 +01:00
|
|
|
bool GPU_type_matches_ex(eGPUDeviceType device,
|
|
|
|
|
eGPUOSType os,
|
|
|
|
|
eGPUDriverType driver,
|
|
|
|
|
eGPUBackendType backend);
|
2021-12-09 20:01:47 +11:00
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
eGPUSupportLevel GPU_platform_support_level();
|
|
|
|
|
const char *GPU_platform_vendor();
|
|
|
|
|
const char *GPU_platform_renderer();
|
|
|
|
|
const char *GPU_platform_version();
|
|
|
|
|
const char *GPU_platform_support_level_key();
|
|
|
|
|
const char *GPU_platform_gpu_name();
|
|
|
|
|
GPUArchitectureType GPU_platform_architecture();
|
2024-09-23 11:18:24 +02:00
|
|
|
blender::Span<GPUDevice> GPU_platform_devices_list();
|
Compositor: Support GPU OIDN denoising
This patch supports GPU OIDN denoising in the compositor. A new
compositor performance option was added to allow choosing between CPU,
GPU, and Auto device selection. Auto will use whatever the compositor is
using for execution.
The code is two folds, first, denoising code was adapted to use buffers
as opposed to passing in pointers to filters directly, this is needed to
support GPU devices. Second, device creation is now a bit more involved,
it tries to choose the device is being used by the compositor for
execution.
Matching GPU devices is done by choosing the OIDN device that matches
the UUID or LUID of the active GPU platform. We need both UUID and LUID
because not all platforms support both. UUID is supported on all
platforms except MacOS Metal, while LUID is only supported on Window and
MacOS metal.
If there is no active GPU device or matching is unsuccessful, we let
OIDN choose the best device, which is typically the fastest.
To support this case, UUID and LUID identifiers were added to the
GPUPlatformGlobal and are initialized by the GPU backend if supported.
OpenGL now requires GL_EXT_memory_object and GL_EXT_memory_object_win32
to support this use case, but it should function without it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136660
2025-04-04 11:17:08 +02:00
|
|
|
|
|
|
|
|
/* The UUID of the device. Can be an empty array, since it is not supported on all platforms. */
|
|
|
|
|
blender::Span<uint8_t> GPU_platform_uuid();
|
|
|
|
|
/* The LUID of the device. Can be an empty array, since it is not supported on all platforms. */
|
|
|
|
|
blender::Span<uint8_t> GPU_platform_luid();
|
|
|
|
|
/* A bit field with the nth bit active identifying the nth device with the same LUID. Only matters
|
|
|
|
|
* if LUID is defined. */
|
|
|
|
|
uint32_t GPU_platform_luid_node_mask();
|