-
Notifications
You must be signed in to change notification settings - Fork 603
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
Comments
The old C++ command buffer stuff lives here: 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 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. |
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). |
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.
The text was updated successfully, but these errors were encountered: