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

[Dave Airlie]

On Mon, 24 Aug 2020 at 07:25, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> On Sun, Aug 23, 2020 at 8:50 PM Dave Airlie <airlied at gmail.com> wrote:
>
> > I don't want to get involved in half-thought out schemes here,
>
> [this has been in the planning stage for... almost 2 years now?]
>
> > but I'm
> > going to indulge myself in one post.
>
> appreciated.
>
> > The programming model is what designs the driver:
> > If your "GPU" is a scalar processor with 1000s of threads, then you
> > want to operate it with a GPU driver.
> > If your "GPU" is a wide-vector processor with only 10s of threads, you
> > want to use llvmpipe style driver.
>
> ironically due to it being a general-purpose processor with wide
> vector processing added, and custom vectorised 3D opcodes, and no
> SIMT, it strictly fits neither of those definitions, neither being
> SIMT, nor SIMD, and yet having the possibility (through a NoC such as
> OpenPITON) to run thousands of SMP cores (not SIMT threads: SMP
> cores).
>
> consequently we are in... "new ground".  luckily, NLNet recognise that
> this is a Research Project.
>
> > The big thing doing what Jacob did before, and from memory where he
> > went wrong despite advice to the contrary is he skipped the
> > "vectorises it" stage, which is highly important for vector CPU
> > execution, as opposed to scalar GPU.
>
> i saw the cross-over message, he explained why that was as part of an
> early prototype (back in... 2018?)
>
> > I'm guessing you want to add an LLVM backend for your "GPU"
> > instructions (are these all vectorised?),
>
> yes they are.  or, more to the point we're taking the *entire* scalar
> POWER9 ISA and vectorising that (and extending the regfiles to 128x
> 64-bit entries).  vectors may be up to 64 elements (although doing so
> @ 32 bit takes 1/2 the entire 128-deep FP or INT regfile)
>
> > and just work out how to use llvmpipe and vallium.
>
> as i am focussing primarily on the hardware, and trusting jacob and
> vivek's knowledge, i am summarising.  we decided to treat the CPU,
> from the perspective of this MESA driver, as more a GPU than a "SMT
> multi-processor".

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.

What represents a vulkan queue, what will be recorded into vulkan
command buffers, what will execute those command buffers. These are
the questions you need to ask yourself and answer before writing any
code.

Dave.