[Libre-soc-dev] Introduction

[vivek pandya]

On Mon, Mar 15, 2021 at 7:03 PM Jules Penuchot <jules at penuchot.com> wrote:

> Hi Vivek,
>
> On 3/14/21 1:49 PM, vivek pandya wrote:
> > Hi Jules,
> >
> > Nice to meet you!
>
> Nice to meet you too :)
>
> > 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 <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.
>
> I'll look into it, thanks!
>
> > 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
> > <
> 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.
>
> Sounds pretty nice already!
>
> > 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.
>
> Could some parts of that codebase be turned into C++? I should be able
> to help with that if you want.
>
That is nice to have but could take decent time because you need to rewrite
things. So better we do that once we can run a triangle.
One thing might interest you is write GetVertexAttributeData() from
spirv_compiler.cpp from visor and load that compiled code from the driver
library and make it available for ORCJit.
Basically JIT is not aware about the layout of the whole GPUState struct
instead whenever it adds a function call like GetVertexAttributeData() and
gets required things.
So that will be a very low level but interesting opportunity to load code
from a driver shared library and for now just print LLVM IR and see things
as per expectations.

If we try to implement GetVertexAttributeData() like function in LLVM IR
itself it will be tedious and error prone so above seems the correct
approach to tackle this problem.


> > 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.
>
> I'll dig into it this week! I might not be as active as you during the
> weekends however. I consider this work to be a good fit for my thesis so
> I'll spend time on it during weekdays.
>
> Awesome work so far.
>
> Regards,
> Jules
>

Thanks,
Vivek