[Libre-soc-dev] Introduction

[vivek pandya]

Hi Jules,

Nice to meet you!

I have been working on this experimental driver for sometime now.
What I have been trying to do is inspired from
https://github.com/baldurk/visor , as I only work on this on weekends and I
am not an expert in mesa codebase or SwiftShader I am referring to simple
implementations like visor.
As this is a software rasterizer it has a GPUStatus struct to hold
indexBuffer and vertexBuffer , image is also stored as a pointer to bytes.
Basically no hw abstraction in linux driver space to use actual memory on a
device , everything is on CPU memory.

The driver is able to execute a simple DrawTriangle function which executes
vertex shader and fragment shader  through LLVM's ORCJit but it does not
generate meaningful results. Because codegeneration is not yet aware about
the GPUStatus struct, that is the next thing I have to do to get the first
triangle. Current code generation is all code copied from AMD's radv driver
implementation which is not a software rasterizer.
The resterization is a bit slower but it can be improved by threads but not
a priority for now.

However since the driver is able to receive the Draw command that means
lots of vkCreate... functions are implemented to do basic stuff that is
required to get up to this point.
Also I am able to run
https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html
that means driver is able to use image from a CPU memory and present it on
display with mesa's WSI layers. And hopefully that means I am on the right
path. Once I update codegen to use GPUStruct and get a triangle on screen
it should be sufficient to prove that this is the correct way.

The codebase is in C so it's a bit painful to work with. Also I have to use
LLVM's C bindings to create IR an and that is very painful compared to
LLVM's C++ API.
The code has lots of unused code as I started copying things from other
implementations, I will clean up things but not a priority.

An experienced mesa/vulkan driver engineer may not have taken this path but
once I get a triangle on screen I will be more confident about my approach.

Hope this helps and if you dig into the codebase please feel free to send
email to my email address (CC list) . I will be happy to explain.

Thanks!
Vivek


On Sat, Mar 13, 2021 at 9:19 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sat, Mar 13, 2021 at 2:58 PM Jules Penuchot <jules at penuchot.com> wrote:
>
> > On 3/13/21 2:52 PM, Luke Kenneth Casson Leighton wrote:
>
> > >
> http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002089.html
> > >
> > > it's a progressive series of steps that has some interesting
> side-effects:
> > > a general-purpose software-rendered 3D MESA driver is one of them.
> >
> > I'm looking into it thanks! I'm scanning through this to get an idea of
> > what the whole project is all about.
>
> basically, we're not doing "totally separate GPU totally separate ISA
> connect over shared-memory do some insane full-blown
> Inter-Process-System with massive queues and god knows what else"
>
> instead:
>
> 1) the shader is compiled.
> 2) the 3D instructions are ***NATIVE*** to the CPU.
>
> not, "native to a foreign GPU where the main CPU driver has to
> communicate with a competely alien system over shared memory"
>
> consequently, we are *actually* adding *actual* 3D opcodes to
> OpenPOWER, *and* adding predication, *and* adding Vectorisation, *and*
> adding Swizzle, *and* adding vec2/3/4 *and* adding Matrix operations
> and many more.
>
> but because this has never been done before, none of the existing
> Vulkan MESA drivers are of any use to us, and neither is google
> SwiftShader.
>
> therefore we need an incremental approach.
>
> > > i'll let vivek respond: if you're happy with the plan then we can move
> to
> > > the next step(s), are you happy with the Charter, you've found the
> mailing
> > > list already, etc. etc.
> > >
> > > warmest,
> >
> > Happy with the plan, happy with the charter, thanks for the info!
>
> excellent, ok so when you're ready send me an ssh public key.
>
> you can get set up with these:
>
> https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-mesa-apt-reqs;hb=HEAD
>
> https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=lsoc-mesa-dev-env-setup;hb=HEAD
>
> that will save you a lot of time
>
> l.
>
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev
>