On Mon, 24 Aug 2020 at 09:10, Jacob Lifshay <programmerj...@gmail.com> wrote: > > 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. > >
It's hard to know then what you can expect to leverage from Mesa for that sort of architecture, the SPIRV->NIR translation, and then you probably want some sort of driver specific NIR->LLVM translation, amdgpu is completely scalar, llvmpipe is manually vectorised, swr does something like you might want, afaik it does a scalar translation and then magic execution (but I haven't dug into it except to fix interfaces). I think you will hit problems with vectorisation, because it's always been a problem for every effort in this area, but if the CPU design is such that everything can be vectorised and you never hit a scalar path, and you workout how texture derivatives work early, it might be something prototype-able. But none of the current mesa drivers are even close to this architecture, llvmpipe or swr are probably a bit closer than anything, so it's likely you'll be doing most of this out-of-tree anyways. My other feeling is it sounds like over architecting, and reaching for the stars here, where it might be practical to bring vallium/llvmpipe up on the architecture first then work out how to do the big new thing, or bring up this architecture on an x86 chip and see it works at all. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
