This PR adds an extension to the TornadoExecutionPlan API in TornadoVM to allow developers to query backends and devices by applying filters. This API is designed as a consequence of the inconsistencies when obtaining a device using different APIs (more details in the next Section).
This API fixes this inconsistencies by giving the user a new Data Structure, called TornadoDeviceMap in which developers can query all backends, devices and apply filters.
Examples of use:
// Obtain an instance of the TornadoDeviceMap via the execution plan
TornadoDeviceMap tornadoDeviceMap = TornadoExecutionPlan.getTornadoDeviceMap();
// Obtain the number of backends installed
int numBackends = tornadoDeviceMap.getNumBackends();
// Query all backends installed
List<TornadoBackend> backends = tornadoDeviceMap.getAllBackends();
// Obtain the number of devices for the first backend
int numDevicesBackendZero = backends.getFirst().getDeviceCount();
We can apply more complex queries as follows:
TornadoDeviceMap tornadoDeviceMap = TornadoExecutionPlan.getTornadoDeviceMap();
// Obtain the OpenCL Backend
List<TornadoBackend> openCLBackend = tornadoDeviceMap.getBackendsWithPredicate(backend -> backend.getBackendType() == TornadoVMBackendType.OPENCL);
// Obtain Backends with at least, two devices
List<TornadoBackend> multiDeviceBackends = tornadoDeviceMap.getBackendsWithPredicate(backend -> backend.getDeviceCount() > 1);
// Obtain All backends that can access to an NVIDIA GPU
List<TornadoBackend> backendsWithNVIDIAAccess = tornadoDeviceMap.getBackendsWithDevicePredicate(device -> device.getDeviceName().toLowerCase().contains("nvidia"));
As part of this API, we needed to refactor some internal classes. The concept of Driver is not the same as we have in TornadoVM compared to the OS driver. Thus, all old driver classes became the Backend classes.
Problem description
The main problem is that to query the number of devices, developers need to access through the TornadoRuntime.getRuntime class. However, to select a device or a backend, developers need to the ExecutionPlan.
This PR fixes this inconsistencies by providing a more concise and expressive API to filter devices and backends without the need to instantiate or interact with the TornadoVM Core Runtime (internal class).
Backend/s tested
Mark the backends affected by this PR.
[X] OpenCL
[X] PTX
[X] SPIRV
OS tested
Mark the OS where this PR is tested.
[X] Linux
[X] OSx
[ ] Windows
Did you check on FPGAs?
If it is applicable, check your changes on FPGAs.
[ ] Yes
[X] No
How to test the new patch?
$ make
$ tornado-test -V uk.ac.manchester.tornado.unittests.api.TestDevices
$ make BACKEND=spirv
$ tornado-test -V uk.ac.manchester.tornado.unittests.api.TestDevices
$ make BACKEND-ptx
$ tornado-test -V uk.ac.manchester.tornado.unittests.api.TestDevices
Description
This PR adds an extension to the
TornadoExecutionPlan
API in TornadoVM to allow developers to query backends and devices by applying filters. This API is designed as a consequence of the inconsistencies when obtaining a device using different APIs (more details in the next Section).This API fixes this inconsistencies by giving the user a new Data Structure, called
TornadoDeviceMap
in which developers can query all backends, devices and apply filters.Examples of use:
We can apply more complex queries as follows:
As part of this API, we needed to refactor some internal classes. The concept of Driver is not the same as we have in TornadoVM compared to the OS driver. Thus, all old driver classes became the Backend classes.
Problem description
The main problem is that to query the number of devices, developers need to access through the
TornadoRuntime.getRuntime
class. However, to select a device or a backend, developers need to the ExecutionPlan.This PR fixes this inconsistencies by providing a more concise and expressive API to filter devices and backends without the need to instantiate or interact with the TornadoVM Core Runtime (internal class).
Backend/s tested
Mark the backends affected by this PR.
OS tested
Mark the OS where this PR is tested.
Did you check on FPGAs?
If it is applicable, check your changes on FPGAs.
How to test the new patch?