Comments (10)
I know @robclark made some comments in the direction of (1) but I think I'd prefer (2) if we can make it work. One option would be to provide, with your capbailities, some sort of tag saying "You may need to load libdrm2_foo.so in order to allocate"
from allocator.
I think if we don't do (1) then that means knowing how map capabilities (by which I think you mean use-cases??) to a set of devices. Which gets us back to the gralloc problem, and not being suitable for a non-device-specific distro. Unless I misunderstand what you mean (since in "liballoc" parlance a set of capabilities are what you get from the backend/driver in response to assertion_t
(set of generic parameters) plus usage_t
)
My reasoning behind (1) is that the client already knows what set of APIs and/or devices are involved in whatever it is that it is trying to do.
from allocator.
If we go with the json-style backend description files GLVND and Vulkan are using, we could ask vendors to include some vendor->backend filename mapping in the json file.
However, I think the harder part is going from -> <backend .so name>. How does a client enumerate without first loading <backend .so name>? Presumably it could get them from some other API. However, if it has to ask the allocator library for them, the allocator library probably needs to open the backends to list them. That's the cache 22 that caused Vulkan and GLVND+EGL to load all available backends. FWIW, as a vendor with a giant monolithic lib[E]GL thing that does Vulkan too, we're aware it's not ideal for load times. There's some re-factoring planned. I view it as an implementation problem rather than Vulkan/GLVND+EGL interface design problem, but I'm still a bit wary of the "load everything" design anyway.
from allocator.
I guess I was hoping to avoid the bootstrap problem by declaring that the client somehow automagically figured out which APIs (via glvnd/vk-loader/etc), and v4l devices, and whatever else, since it would have needed to figure that out somehow already.. and now all it needs to do is figure out optimal buffer format to use across the various devices.
Partly that was based on my thinking that this was something that supplements gbm rather than replaces gbm. I'm still thinking about that part.. if you needed a liballoc instance before you had an EGLDisplay
that maybe changes things.. I'm still thinking about your comments in #1.
from allocator.
I don't think that magically loading things requires that we have a particularly complicated mapping. You get a list of capability/restriction tags from each driver/API in the negotiation. With that mapping, they can also provide an identifier specifying which liballoc back-end they're associated with. Then liballoc just loads those back-ends only.
We could possibly also go off of something where the json files have a list of vendor IDs. If there are caps with one of those vendor ids, then you should load that allocator. For the "common" cases such as ION, the back-end could be builtin and wouldn't need loading.
from allocator.
If the libraries loaded are based on those the capabilities require, then you have a chicken-and-egg problem: At least one instance of the allocator would have had to load some set of libraries to generate the capability set in the first place, and how does that bootstrap instance know which backends to load?
from allocator.
@jekstrand I punted on trying to define exactly how loader works (json or whatever).. that is kinda a boring detail once we figure out whether liballoc backend is the thing that bootstraps the API or just something that comes later once API is already bootstrapped.. I guess important question is whether you have the API (EGLDisplay or gbm_device or whatever) or fd first, or whether "liballoc" is your entry point into everything. I'd been assuming the former.. but depending on the conclusion of #1 that might change.
@cubanismo yeah, loading lib based on cap-set you get from the alloc_dev_t
doesn't work.. when you need to get the cap-set from the alloc_dev_t
in the first place.. I'm a bit in limbo on this until we figure out whether "liballoc" (or whatever it ends up getting called) replaces gbm or sits beside gbm. I have some vague conflicting half-baked thoughts on that. But my feeling until now is that for most devices, we actually have to open the device to query it to figure out caps-set so there isn't much we can do without already having the device fd (for things that are purely kernel interface) or some sort of userspace device handle (gbm or egl or whatever) first. And if that is the case "liballoc" loader doesn't have to open everything since whatever you want is already opened.
tl;dr: I think we solve #1 first, and then how the "liballoc" loader works falls out as a conclusion of that.
PS. whether chicken or egg came first, I think the scientific answer is neither :-P
from allocator.
from allocator.
@jekstrand right, I mentioned as much in USAGE.md: "In cases where the underlying device file is not exposed (such as OpenMAX or OpenCL, or OpenGL when not running on top of gbm) an extension would be required to retrieve the alloc_dev_t from that particular API.".. so I think we are on the same page there.
from allocator.
FWIW, right now the prototype loads backends like GLVND+EGL and libvulkan do based on json config files. When it gets a device file as proposed in USAGE.md, it asks each available backend if it supports that file, and inits a device instance on the first one that returns true.
I ran into some problems implementing this: The NVIDIA driver doesn't allocate out of a single FD. It allocates out of two or more depending on the type of allocation being made. Only one of those FDs is device-specific. The other ones can dispatch to all devices, so they aren't useful in identifying a device. However, we still need them to init our driver. This is sort of the fundamental problem with trying to integrate our driver into mechanisms like systemd that hand us an FD and expect us to init graphics drivers from it, so I probably should have anticipated it.
Given that, I'm kind of coming back to the idea of exposing at least one init path that works off of device UUIDs or some other stateless identifier.
Of course, there could always be the "extract an alloc_device_t from EGL/Vulkan/etc." path that @robclark proposed, but I think that would cause problems for something like gralloc using the allocation library as a backend, and you'd also get the circular dependency of how does EGL/Vulkan/etc. get an alloc_device_t in the first place? I'd prefer the answer to that not be "Some vendor-specific back door."
@jekstrand As far as getting caps from Vulkan, that sounds fine, but EGL/GL mostly lack the mechanism to describe caps well. I think you'd end up with "Everything for graphics" or "nothing", plus maybe a special case for OES_external_texture. Maybe that's OK, but if we're really going to expect people to build Vulkan drivers ON TOP of the allocator library, I think it has to be able to define usage itself that is at a minimum as expressive as what Vulkan can do. I know for our HW, we would still prefer even slightly finger-grained usage than what Vulkan exposes now, but that may be something addressable as a future Vulkan extension as well. Then of course, there are all the non-graphics devices where the allocator library will likely be the only game in town for capability queries, at least at first. And maybe it's not bad to try to centralize all of this logic in one library + driver module per vendor, even if it is some upfront work.
from allocator.
Related Issues (8)
- where does this sit with respect to gbm HOT 6
- What does the length_in_words field in capabilities/usage mean? HOT 1
- Add max width/max height constraints HOT 5
- Is this dead project?
- How do we want to specify formats? HOT 20
- Can we actually describe everything with positive capabilities and a few set constraints? HOT 5
- How [de]centralized do we want to be? HOT 22
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from allocator.