orrery::backend::DeviceDescription Struct Reference

What the runtime reports about a device, in types that do not require SYCL. More...

#include <orrery/backend/sycl_device.hpp>

Public Member Functions
bool	supports_build_precision () const noexcept
	True when this device can run the kernel in the precision this build was configured for.

Public Attributes
std::string	name
	The device's own name, for example "Intel(R) Arc(TM) 130V GPU (16GB)".
std::string	vendor
std::string	driver_version
	The driver version, which belongs beside any performance figure.
std::string	backend
	Which runtime the device was reached through, "Level Zero" or "OpenCL".
unsigned	compute_units {}
	Compute units, which is not the same count as Xe-cores.
unsigned	max_work_group_size {}
	The largest work-group the device will accept.
unsigned	sub_group_size {}
	The sub-group size the kernel was compiled for, which on Intel Xe is the SIMD width the hardware actually executes with.
std::uint64_t	global_memory_bytes {}
std::uint64_t	local_memory_bytes {}
	Shared local memory per work-group, which is what a tiled kernel has to fit its block of source particles into.
bool	supports_shared_usm {}
	Whether the device can allocate shared unified memory, addressable from both host and device.
bool	supports_device_usm {}
	Whether the device can allocate memory only it can address.
bool	supports_host_usm {}
	Whether the device can address host allocations.
bool	supports_system_usm {}
	Whether the device can address memory from an ordinary new or malloc, with no USM allocator involved at all.
bool	supports_double_precision {}
	Whether the device implements double precision.

Detailed Description

What the runtime reports about a device, in types that do not require SYCL.

Deliberately plain data. It crosses out of the SYCL translation units into benchmark tables, test messages and the performance document, none of which should have to include a device runtime header to print a device name.

Member Function Documentation

supports_build_precision()

bool orrery::backend::DeviceDescription::supports_build_precision ( ) const

nodiscardnoexcept

True when this device can run the kernel in the precision this build was configured for.

A single-precision build asks nothing unusual of any GPU. A double-precision build asks for fp64, which this project's target hardware does report, so the solver constructs in either configuration and the choice between them is made on measured throughput rather than on capability.

Member Data Documentation

driver_version

std::string orrery::backend::DeviceDescription::driver_version

The driver version, which belongs beside any performance figure.

A graphics driver update can move an integrated GPU's throughput substantially, and a number quoted without it cannot be reproduced.

backend

std::string orrery::backend::DeviceDescription::backend

Which runtime the device was reached through, "Level Zero" or "OpenCL".

Both can expose the same physical GPU, and they do not perform identically. Reported so that a figure says which one produced it.

compute_units

unsigned orrery::backend::DeviceDescription::compute_units {}

Compute units, which is not the same count as Xe-cores.

Section 2 of the implementation plan records 7 Xe-cores for this part and the runtime reports 64, because it counts the vector engines inside them rather than the cores. Both numbers are correct about different things, and this one is recorded under the runtime's name for it so that nobody reconciles them by assuming one is wrong.

supports_shared_usm

bool orrery::backend::DeviceDescription::supports_shared_usm {}

Whether the device can allocate shared unified memory, addressable from both host and device.

What this backend allocates.

supports_device_usm

bool orrery::backend::DeviceDescription::supports_device_usm {}

Whether the device can allocate memory only it can address.

True on essentially everything, and not useful on a part with no separate memory for such an allocation to live in.

supports_system_usm

bool orrery::backend::DeviceDescription::supports_system_usm {}

Whether the device can address memory from an ordinary new or malloc, with no USM allocator involved at all.

The aspect that would let a kernel read the particle arrays where the rest of the project already keeps them. False on the target GPU's driver, which is the measured fact ADR-0027 turns on.

supports_double_precision

bool orrery::backend::DeviceDescription::supports_double_precision {}

Whether the device implements double precision.

True on the target GPU, which is worth stating because the opposite is widely assumed of integrated Intel parts. What the aspect does not say is at what rate: reporting fp64 and executing it at a useful fraction of the single-precision rate are different claims, and only the second one matters to a simulation. docs/performance/sycl_direct.md measures it rather than inferring it from this flag.

---

The documentation for this struct was generated from the following file:

• orrery/backend/sycl_device.hpp