On Sun, Aug 23, 2020, 15:55 Dave Airlie <airl...@gmail.com> wrote: > What is your work submission model then, Vulkan is designed around > having work submitted to a secondary processor from a control > processor. Do you intend for the device to be used only as a > coprocessor, or as a CPU for normal tasks that can then use the > features in their threads, because none of the API are designed around > that model. They have a running thread of execution that queues stuff > up to a separate execution domain. >
It's intended to be a combination, where CPU threads schedule work and render threads dequeue and run the work, probably using something like Rayon: https://github.com/rayon-rs/rayon When a CPU thread waits in the Vulkan driver, it can possibly be used as a render thread instead of blocking on a futex, avoiding needing excessive numbers of Linux kernel-level threads. The CPU and render threads run on the same cores, as scheduled by Linux. > > What represents a vulkan queue, The rayon task queues. what will be recorded into vulkan > command buffers, a command sequence encoded as bytecode, a list of Rust enums, or something similar. what will execute those command buffers. the render threads will dequeue the command buffers, run through all the commands in them, and schedule the appropriate rendering tasks to rayon's task execution mechanism. These are > the questions you need to ask yourself and answer before writing any > code. Yup, did that 2 years ago, though I don't remember if I explicitly wrote them down before. Jacob
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
