[Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Dave Airlie]

On Mon, 24 Aug 2020 at 09:10, Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Sun, Aug 23, 2020, 15:55 Dave Airlie <airlied at 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.