Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Device Properties #184

Merged
merged 2 commits into from
Mar 12, 2021
Merged

Conversation

alexander-g
Copy link
Contributor

Added Manager::getDeviceProperties() which exposes some device parameters that are relevant for Kompute

devprops = mgr.get_device_properties()
print(devprops)
Device Name:                   SwiftShader Device (LLVM 10.0.0)
Maximum Workgroup Count:       65535, 65535, 65535
Maximum Workgroup Invocations: 128
Maximum Workgroup Size:        128, 128, 64
Timestamps Supported:          False

(Single Include header changed more than I want, not sure why.)

Copy link
Member

@axsaucedo axsaucedo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have actually been thinking of convert a lot of the Manager functions related to vulkan resource creation into static functions, mainly as the creation of the Device, etc could be quite useful for the unit tests to test Tensors / other components in isolation without having to create a manager, so I think this is an interesting approach.

I added a couple of comments, the main one is to avoid creating structs and instead returning the vk:: objects instead in the C++, and returning a python Dict in the bindings instead of creating a new class binding

src/Manager.cpp Outdated
DeviceProperties Manager::getDeviceProperties() const
{
const vk::PhysicalDeviceProperties properties = this->mPhysicalDevice->getProperties();
const DeviceProperties output{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a new struct when we can just return a vk::PhysicalDeviceProperties? The PhysicalDeviceLimits object itself has a very long list of limits so it's a slippery slope exposing only a subset of these, as later on more will be required to the extent it's better to just expose the object itself

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it because creating a PyBind binding to the object is harder? Perhaps the subset of properties exposed can just be on the Python binding as opposed to the underlying component

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it because creating a PyBind binding to the object is harder? Perhaps the subset of properties exposed can just be on the Python binding as opposed to the underlying component

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was that most of the properties are not relevant for Kompute. Moreover, some of the properties could be post-processed for easier access by the user, e.g. amount of device memory: Using the raw vk:: struct one would need to find the correct memory type first.

Copy link
Member

@axsaucedo axsaucedo Mar 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand, what would be the requirements to find the correct memory type? I can see that you read for example properties.limits.maxComputeWorkGroupCount, is the memory type whether it's not of type Compute? I agree that there is a large number of options on the device properties, I'm just thinking that having a struct in between may result in more abstractions to maintain and potentially people requesting more to be exposed - what about the suggestion on having it in the python binding as a python dict? It could be buitl as a single-level python dict, where the key could just be limits_max_compute_work_group_count, etc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not yet implemented. I mean that the the user would need to iterate over the memory types as in Tensor::allocateBindMemory to find the correct memory heap that is used for the buffers.

uint32_t size() {
return this->mSize;
}
uint32_t size() { return this->mSize; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you run make format? or why is the kompute.hpp modifying the format?

Copy link
Member

@axsaucedo axsaucedo Mar 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the version of your CLIs / dependencies related to the creation of the single header?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make format uses hardcoded paths. I've manually run clang-format as in the Makefile, didn't help.

Versions:
clang-format 10.0
quom 1.2.0

@@ -217,7 +217,26 @@ PYBIND11_MODULE(kp, m) {
py::arg("spirv"),
py::arg("workgroup") = kp::Workgroup(),
py::arg("spec_consts") = kp::Constants(),
py::arg("push_consts") = kp::Constants());
py::arg("push_consts") = kp::Constants())
.def("get_device_properties", &kp::Manager::getDeviceProperties, "Return a struct containing information about the device");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to just return the device properties as a Dict instead of a new class? Conscious if we start exposing Vk classes it could lead into more vk classes being requested

Copy link
Member

@axsaucedo axsaucedo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting - thanks for the pr.

I have actually been thinking of converting a lot of the Manager functions related to vulkan resource creation into static functions, mainly as the creation of the Device, etc could be quite useful for the unit tests to test Tensors / other components in isolation without having to create a manager, so I think this is an interesting approach.

I added a couple of comments, the main one is to avoid creating structs and instead returning the vk:: objects instead in the C++, and returning a python Dict in the bindings instead of creating a new class binding

@alexander-g
Copy link
Contributor Author

Modified to return raw vk:: struct and Python dict

mgr.get_device_properties()
{'device_name': 'SwiftShader Device (LLVM 10.0.0)',
 'max_work_group_count': (65535, 65535, 65535),
 'max_work_group_invocations': 128,
 'max_work_group_size': (128, 128, 64),
 'timestamps_supported': False}

Copy link
Member

@axsaucedo axsaucedo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @alexander-g, python dictionaries look great in C++ with the pybind literals

const auto properties = self.getDeviceProperties();
py::dict py_props(
"device_name"_a = std::string(properties.deviceName.data()),
"max_work_group_count"_a = py::make_tuple(properties.limits.maxComputeWorkGroupCount[0],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool

@axsaucedo axsaucedo merged commit abd635c into KomputeProject:master Mar 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants