-
Notifications
You must be signed in to change notification settings - Fork 171
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
The Vulkan allocator #614
The Vulkan allocator #614
Conversation
a226371
to
02e904f
Compare
ffd08b2
to
7e05e25
Compare
Codecov Report
@@ Coverage Diff @@
## master #614 +/- ##
==========================================
+ Coverage 31.04% 31.06% +0.01%
==========================================
Files 84 84
Lines 13770 13770
==========================================
+ Hits 4275 4277 +2
+ Misses 9495 9493 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
a7f97af
to
c0adddf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good, some questions:
557e21b
to
fa43594
Compare
f88ea80
to
80421ef
Compare
Scope
First is a thin lightweight wrapper around ash to get an Instance and PhysicalDevices. This helper is kept intentionally lightweight to prevent essentially replicating a crate like vulkano. Creation of a logical
Device
is intentionally not covered since extensions toDeviceCreateInfo
and queue creation are hard to model in a public API. The Vulkan allocator and a future renderer are expected to initialize their own logical device(s) and queues.The Vulkan allocator is modeled around the
Allocator
trait. Implementing memory import/export and dmabuf import could be done, but it involves much more complex lifetimes (since memory import/export requires copy commands, which means command execution and needing to delay destruction of images until command execution finishes). In the future we could expand the allocator api to handle this as an alternative to gbm's memory import/export functions. This may be harder to do but will allow custom Vulkan renderers to be build more easily (since all the external memory logical will be in one type you can just pull in).There are a few things we do need to do before merging:
A new ash release (ReleaseWill use 0.37.1 pre-release with a set revision for now.ash 0.37.1
ash-rs/ash#632). 0.37.1 will not eliminate the builders, so if we do not want to wait for 0.38.0 then we will need to readd the builders.