This is part of T79131
The problem is that basically all these sockets are read-only, and that API users can't simply create a DeviceInfo by themselves. There is a list of devices provided and then a choice from that can be made.
I think probably DeviceInfo should not be what we have as nodes. Rather there could be a new class (e.g. RenderDevice or something), which has just the device type and ID. And then finding the corresponding DeviceInfo would be up to the session.
Does that make sense?
SessionParams now holds an array of RenderDevices to account for multi-device setups. This array holds pointers to RenderDevice as it has to be a socket, and we only support sockets of arrays to Node pointers.
The Session constructor takes the array of RenderDevice and constructs a DeviceInfo from it which is then used to create the actual Device.
The logic to construct the DeviceInfo is similar to that of blender_device_info, although it has to work a RenderDevice array. Hopefully the logic is similar and works for all cases, it seems to work fine for the limited set of devices that I personnaly own.
Because we allocate RenderDevice objects on the heap, we would have to use create_node instead (the Session could own those nodes), but first I want to check that this is indeed the right path.
For now, the RenderDevice Node is located in the session.h/cpp files, but could be moved elsewhere more appropriate.
Because of this refactor, DeviceInfo::has_peer_memory is not set anymore in the Blender exporter, not sure how to properly introduce it back.
Modified TileManager to have a setter for the number of devices as it is no longer possible to pass this information to its constructor while constructing a Session.