update USAGE.md with central bo_create call #8
Conversation
This is how I would envision the bo alloc call to work. Having the liballoc core do the work to ask around which device is able to allocate with a given set of caps/constraints makes the application API easier and would allow to plug in things like ION by just providing a liballoc driver backend on top of them.
| if (!buf) | ||
| buf = alloc_bo_create(ion, &assertion, &result_capabilities); | ||
| #endif | ||
| buf = alloc_bo_create(&assertion, &result_capabilities); |
There was a problem hiding this comment.
I don't know if we have concensus between these two usages. I've gone back and forth on this myself (and I still don't think I like the idea of explicitly exposing something as low-level as ION to the app, or even the allocator base lib at all), and currently lean towards looping inside the allocator. I'd be interested to hear what the benefits of keeping the looping in the application are though. I could be missing them.
Perhaps rework the pull request to indicate both directions are under consideration in the meantime?
There was a problem hiding this comment.
@lynxeye-dev I think we want to make it explicit, since some of the devices involved might not be accessible to all processes involved, ie. in some cases the buffer might need to be allocated in other process via some device-proxy protocol. I don't think that should be part of "liballoc", so best not to hide things.
In the end, I'd expect some window system specific, but shared, layer to be the one using the "liballoc" API, in the same way that you are normally using some toolkit like gtk or qt, rather than building x11 proto msgs directly, so it isn't really like we are exposing ION directly to the application.. just to something that sits above "liballoc" and below the app.
This is how I would envision the bo alloc call to work.
Pull request meant as a place to get a discussion about this going.