Skip to content
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.

Sign up for GitHub

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

update USAGE.md with central bo_create call #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

update USAGE.md with central bo_create call #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 6 additions & 8 deletions USAGE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,18 +101,16 @@ combine_capabilities(&result_capabilities, camera_capabilities);
Allocate Buffer
---------------

Just try allocating from each device until one succeeds.
Ask the allocator to create the buffer, it will go around and ask each
of the devices it knows about to do the allocation until one succeeds.

This means the allocation may be done on a device not involved in the
buffer sharing itself, like ION.

```
alloc_bo_t *buf;

buf = alloc_bo_create(display, &assertion, &result_capabilities);
if (!buf)
buf = alloc_bo_create(camera, &assertion, &result_capabilities);
#ifdef HAVE_ION
if (!buf)
buf = alloc_bo_create(ion, &assertion, &result_capabilities);
#endif
buf = alloc_bo_create(&assertion, &result_capabilities);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.


assert(buf);
```
Expand Down