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.

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

Implement a simple synchronous local HAL scheduling (sibling to task_*) #4680

Closed
benvanik opened this issue Feb 1, 2021 · 2 comments
Closed
Assignees
Labels
hal/cpu Runtime Host/CPU-based HAL backend platform/generic 🔩 Bare metal/generic target build, execution, benchmarking, and deployment

Comments

@benvanik
Copy link
Collaborator

benvanik commented Feb 1, 2021

Systems that have a single processor don't need the fancy task system - they just need a way to run through simple commands kept in a command buffer. Ideally really small systems would compile away all of the HAL but it's a much smaller investment (and keeps code portable) to have a lightweight local-execution HAL backend that just runs synchronously.

This would be similar in nature to what existed before with the async_command_queue (which was async from the host perspective but synchronous from the device perspective) but much much simpler. It's intended for when the host and device are in the same binary/process/bare - in cases where there's a host/device split (no shared memory/independent versioning/different processes/etc) something more involved is required.

@benvanik benvanik self-assigned this Feb 1, 2021
@benvanik benvanik added the hal/cpu Runtime Host/CPU-based HAL backend label Feb 1, 2021
@benvanik
Copy link
Collaborator Author

benvanik commented Apr 8, 2021

The old C++ command buffer stuff lives here:
https://github.com/google/iree/blob/2d534397009fb2bc8189c540799be1084c15499b/iree/hal/host/inproc_command_buffer.h#L205
https://github.com/google/iree/blob/2d534397009fb2bc8189c540799be1084c15499b/iree/hal/host/inproc_command_buffer.cc#L125-L138

This could be made much more efficient; a new version should use iree/hal/local/arena.h for storage and not record any recording-only state (push constants/descriptor sets/etc). The iree/hal/local/task_command_buffer.c does this and only actually commands are recorded. Even that could be made more memory efficient by slicing out the state tracking storage from the block pool and returning it after the iree_hal_command_buffer_end such that only the recorded storage persists.

Unlike in the task system-based one above since this would be unthreaded there's no need to pay attention to any barriers - all commands will execute in the order they are recorded.

@benvanik benvanik added the platform/generic 🔩 Bare metal/generic target build, execution, benchmarking, and deployment label Apr 18, 2021
@benvanik
Copy link
Collaborator Author

Some of the plumbing and the starting point is being done as part of #5508. The big work here (and what is mentioned above) is to add support for command buffer recording and explore pre-compiled command buffers (where we encode a binary structure in the compiler and load it at runtime without needing to issue the VM/HAL calls).

benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 19, 2021
This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
benvanik added a commit that referenced this issue Apr 20, 2021
#5509)

This is mostly just the plumbing to enable #4680 by defining a new
`dylib-sync` runtime driver (pending #4298 to cleanup drivers).

This driver does not support recording/replaying command buffers and has
some gotchas with semaphores (no deadline waits, probably bugs, etc).
@benvanik benvanik closed this as completed May 4, 2021
ScottTodd added a commit that referenced this issue Jan 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hal/cpu Runtime Host/CPU-based HAL backend platform/generic 🔩 Bare metal/generic target build, execution, benchmarking, and deployment
Projects
None yet
Development

No branches or pull requests

1 participant