Scene graph validation and settings refinement

[robertosfield]

Hi All,

I'm opening this disucssion thread to get feedback from the community and get gather ideas on how we might tackle the topic of validating scene graph settings to the capabilities of the hardware/drivers available on machine.

The seed for this discussion was a PR from @siystar that implemented an automatic disabling of mipmap generation when hardware didn't support it on a per device basis, rather just failing like the VSG was doing previously when the vsg::Image/vsg::Sampler settings required mipmap generation but the hardware/drivers didn't actually support the required blitting for the image format.

@siystar also provide a modified version of the vsgheadless example to illustrate the problem with the existing VSG versions and to illustrate how the above PR fixes them. I have taken this mods, removed all the irrelevant parts from the original example and created a vsgvalidate example, which just has the test code blocks. This is checked into vsgvalidate branch of the vsgExamples.

My thought is we can use this example as a starting place for testing issues that need resolve in some manner, which we can then use as base for testing changes/additions to the VSG.

I have decided to close the PR to the VSG as I feel it's too usage case specific a solution to the problem of how to adjust scene graph settings to avoid attempting to do things that aren't supported by the hardware that a user is running their applications on. This PR does attempt to fix a real problem, even if I feel it's not resolved in a way I think is ideal, so even thought I've closed this PR the problem still very much exists.

What I'd like to seed now is a discussion on the general topic of how we should detected support for the features required by the users scene graph and when features aren't supported how to adjust the settings to something that is supported by the hardware.

This topic also touches upon how we should handle the case where a scene graph requires a feature but by default Vulkan doesn't enable it even if the actual hardware supports it - for instance enabling geometry shaders or ray tracing.

Right now VSG users will need to handle both issues within their own libraries/applications, we could just leave it at that, but as the tagline for vsg-dev is "Vulkan made easy" I don't think this is good enough, the VSG really should provide coherent support to make these tasks easier without trying to nanny users into certain sets of defined mechanisms.

These topics I have flirted with now and then since the inception of the VSG project, but haven't dedicated time to coming up with coherent solution. There are hundreds of topics that scene graphs touch upon so one can't solve them all instantly, so I'm happy that we bit by bit tackle different issues as they become more critical to end users.

I have other tasks that still require my time so I can't dive straight into coming up with possible solutions - I have other PR's and reported Issues from the community to handle, as well as getting another stable release of the VSG out, and keeping moving the Shadows work along. While I'm busy on all these items I'll leave this Discussion thread open for ideas from community and chip in where I can.

[timoore]

vsgCs is one of those libraries that has to handle this on its own, although the feature set needed isn't particularly large. Currently I implement my own logic for querying the physical device and setting up DeviceFeatures in the window traits, and I maintain my own small structure describing the supported features.

A good first step would be to keep around the DeviceFeatures chain that was used to create a device.

It's hard to imagine that VSG could provide very many useful fallbacks; what to do if geometry shaders aren't supported? It could throw an error from a compile task if an unsupported feature is requested.

[robertosfield]

The vsg::ResourceRequirements would probably be a natural place to add vsg::DeviceFeatures settings. The vsg::ResourceHints could also be extended. The vsg::CollectResourceRequirements visitor that fills in the required extensions/options.

Presently the vsg::CollectResourceRequirements is invoked as part of the VIewer::compile() which happens after the Window and associated vsg::Device has been created so we'd need to explore running this prior to device creation.

The fallback implementation would need to happen after vsg::Device creation, but would really need to be done before anything is compiled. The fallbacks would be different for different applications but perhaps there are common enough fallbacks that could be implemented as a basic Validation/Fallback visitor that developers could subclass from to implement their own mechanisms.

These mechanisms would also need to be called from when dynamically loaded new scene graphs such as with the DatabasePager. In the case of new vsg::DeviceFeatures one could possible force recreation of windows to handle, but this again really isn't something we should be doing automatically - some apps will want to just use fallback others will want to recreate Windows, or better at application start up look ahead and set up vsg::DeviceFeatures setting that may be required later.

[robertosfield]

This morning it occurred to me the Issue #945 I generated as follow up to a PR, would probably be best resolved by as part of scene validation traversal. This morning I'll create a Validation branch a see if I can come up with a quick solution for #945 so it can be part of 1.0.9. However, the topic is potentially quite a big one so probably appropriate for deferring till after 1.0.9 is tagged.

[robertosfield]

I have created the Validate branch of the VSG and have begun experimenting with changing how ImageInfo/Image/Sampler handle setting of the Image::mipLevels. Only minor change checked in so far:

https://github.com/vsg-dev/VulkanSceneGraph/tree/Validate

[robertosfield]

I have completed my first pass at refactoring ImageInfo/ImageView/Image so that ImageInfo no longer calls ImageInfo::computeNumMipMapLevels() and only calls it from within DescrtiptorImage::compile(Context&) if the Image::mpLevels is still 0.

I have also removed the setting of the Sampler::maxLod in ImageInfo::computeNumMipMapLevels() so that even if you share Sampler between ImageView the state of the Sampler won't be modified, replacing it with a warning if the Sampler::maxLod isn't compatible with mipmapping being disabled which is required in the case of an Image format that isn't compatible.

The complete changes are: #950

I made a chance to CollectResourceRequirements to make it easier down the line to add computing a Image::mipLevels priot to the compile traversal. I will leave resolving this to a later date as I think what is now checked into VSG master and the 1.0 branch is good enough for the 1.0.9 stable release.