Closed HansKristian-Work closed 3 years ago
LunarG has created a VLLF (Vulkan Lightweight Layer Framework) and is using the VLLF to create an "Assistant" layer to check for poor usage. We have been collecting suggestions of things to track in this LVL issue. @mark-lunarg is working on this and can elaborate more about the features and it's current status.
performance checking layer which can find the most common issues for different IHVs in a common layer.
I believe the layer is currently targeted to catch bad usage applicable for all IHVs. Mark can elaborate.
@HansKristian-ARM (and everyone else), by all means, please review the tracking issue that @KarenGhavam-lunarG pointed to and add your observations or suggestions. Not only will the assistant layer provide coverage for many of the Vulkan performance/practice pitfalls, use of the layer framework should allow users to add customizations quickly and easily.
Based on discussions yesterday, it is clear that if we want to progress on this, we will need to convince IHV that it is worthwhile to do this. One start would be to better promote the current work in this area I think.
In a previous comment I mentioned the VLLF (now called VLF) and wanted to provide an update on this tool that I believe is part of the solution to this issue.
The Vulkan Layer Framework (VLF) allows developers to quickly and easily create layers to aid in application development. The frame makes it possible to create a throwaway layer for just about any purpose. As well, it highly simplifies the creation of full-featured layers by abstracting the extensive and complicated standard layer setup and initialization for the user.
Some simple VLF Use Cases:
There is some suggestion that a tool simplifying layer creation could help motivate IHVs to create hardware specific "best practice" monitoring layers.
The VLF is found in LunarG/VulkanTools in the Layer Factory directory, and will be available in an upcoming Vulkan SDK.
In addition, we have begun implementing "best practice" checks as collected in github issue 1612 . These best practice checks are being put into the "Assistant Layer" that is also found in the LunarG/VulkanTools repo in the assistant_layer directory and will be delivered in a future Vulkan SDK.
I guess I'll jump in and say I personally think the core issue here is developers swamped with advice. There exists a world where we make authoring layers easy where each gpu vendor has a layer and poor game devs now have to know where to find each of these layers and bring it together.
In contrast, Microsoft is just "making it work" in pix. https://blogs.msdn.microsoft.com/directx/2017/03/01/gpu-plugins-improved-sdk-layers-and-hang-debugging-bringing-directx-12-tools-to-the-next-level/
I think its worth us talking about the end game here, then doing what we can to make our individual technical choices that we make along the way take us to the end game.
From what I can tell, that's exposing hardware counters through vendor-specific plugins, which is a separate issue to me.
If the model of creating layers to solve individual problems is considered flawed, then that places the entire layering system under question. I think it's more of a packaging problem than anything.
For an integrated experience where a single tool can handle everything, we'd still need to see IHVs committing to a single debugger and some kind of plugin interface.
While discussing #11 we reached the conclusion that many of the same factors surrounding that issue also apply here. We're trying to figure out what the right way to expose this kind of information is, and where this functionality should be (see https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/11#issuecomment-371573864 for more details).
LunarG had some internal discussions about this issue as well as issue #11. Our recommendation is the following:
So perhaps we should close out issue #7 and issue #11 since they are being tracked in theAssistant Layer tracking issue #1612? And then we create a new issue focused on IHV/vendor specific best practices/performance checks. By having this new focused issue, perhaps the "Ecosystem forum team" can reach out to the IHVs to help influence them to create such layers?
This repository is being archived as it has been replaced with the vulkan.org website (https://www.vulkan.org) and is no longer being maintained (i.e., issues posted here are no longer being addressed ). After reviewing issues posted here, most (if not all) have been resolved or have already been re-opened in Vulkan-Docs (https://github.com/KhronosGroup/Vulkan-Docs) or other repositories for further consideration. Therefore, all issues in this repository will be closed. If you believe your issue has not yet been resolved, please re-open in Vulkan-Docs. Thanks!
Vulkan being a more explicit API means more room to make poor decisions for performance which can be hard to catch during development. It would be interesting if we could have a performance checking layer which can find the most common issues for different IHVs in a common layer. There is one vendor specific layer out in the wild: https://github.com/ARM-software/perfdoc