cubanismo / allocator Goto Github PK
View Code? Open in Web Editor NEWIncubator for a general Unix Device Memory Allocation library
License: MIT License
Incubator for a general Unix Device Memory Allocation library
License: MIT License
One of the resounding things that came out of the discussions at XDC was the mobile guys saying that they don't want to have to do contiguous memory allocation in their GPU driver. Instead, they wanted a central allocator (such as ION) that would understand all the constraints and be able to allocate an image. Both NVIDIA and Intel badly wanted to do the allocation inside their driver stack in the case of single-vendor interactions so that they could handle all their "magic".
Two options were discussed for resolving this:
In the end, we settled on the second option (central allocator) with the understanding that it would have a bunch of pluggable back-ends and would internally walk around to the different back-ends until it found one that could allocate.
This answers the question for the final allocation step, but there are several more steps involved:
There are a few possibilites here. (Thanks to @robclark for the write-up. I'm mostly just moving it to github.):
Possibly this new thing just ends up sitting on the side as a separate API which only deals with allocation, with some small extension to gbm to get from a alloc_bo_t
to a struct gbm_bo
? You could also maybe just do that via importing the dma-buf fd into gbm, but it would be convenient for buffers allocated via the gl/vk driver's "liballoc" backend, to be able to recover the original pipe_resource
or equivalent.
The other possibility is new set of EGL extension, plus maybe some optional (ie. not supported by all backends) features like surfaces, so this new thing replaces gbm. Although there are existing users who use gbm to do gl apps on "bare metal" so this would mean that mesa has to support both gbm and new thing as potential args to eglGetDevice()
..
My initial vision for memory allocation was to have independent blocks of capabilities where each block was fairly self-contained but could have complex interactions within it. This has the down-side that the driver has to be involved in the intersection process. The directions that @cubanismo was pushing was to have everything as small atomic capabilities. While this is less expressive, it's much simpler to perform an intersection operation. We need to double-check that everything needed is expressible this way.
Tentatively, we have said that the capabilities will be relative to the surface allocation parameters: width, weight, format, sample count, mip levels, array slices, etc. In other words, you don't have to worry about expressing every possible set of capabilities which could grow very large.
List of common capabilities (update as more common capabilities are found):
Constraints are a bit special because it will take more care to union them properly. We've determined that these constraints will have to be understood by the allocation library (and therefore common) so that they can be combined properly.
List of common constraints (update if more constraints are needed):
Because our strategy for allocation involves going to the different back-ends and asking them to allocate, we need some strategy for knowing which back-ends care to be involved at any given point. I really would like to avoid the Vulkan loader solution of "just load everything". Some companies are known to ship rather large drivers and are liable to make libdrm2_vendor.so a symlink to their libGL.so. I don't want doing something with the allocator to mean you always pay the cost of loading ~1GiB worth of shared libraries into your address space just because you have lots of big heavy GL drivers installed.
This means that you need some way of determining when a particular back-end will be needed. We have a few different options:
The prototype code doesn't allow devices to expose their maximum image width and height as a constraint. Support for this constraint should be added.
While reviewing the current prototype implementation, @mvicomoya pointed out the way I'd used length_in_words was more consistent with a field called extra_words or something, since it excludes the length of the header structure. Now I'm unclear which is preferable: Should length_in_words include the header structure or not? If not, should we change the name?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.