[Libre-soc-bugs] [Bug 251] Initial 3D MESA non-accelerated software-only driver is needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=251

--- Comment #62 from vivekvpandya <vivekvpandya at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #61)
> (In reply to vivekvpandya from comment #60)
> 
> > Again may be some low hanging fruits like
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4385
> 
> interesting, a parallel addition.
>  
> > > that said if you've managed to get as far as you have, and opened up
> > > a new development path with it, that's fantastic, and a good call.
> > 
> > This particular path can get us started on LLVM side. I am thinking to
> > modify LLVM power-pc backend which will run a simple vectorizer pass (just
> > before Global ISEL)and create libre-soc specific LLVM intrinsics (can be
> > added with TD) and then updated Global Isel to generate libre-soc's textual
> > assembly for newly added llvm instrinsics. 
> 
> great idea.  if that can be done as stand-alone programs (not needing
> the entirety of mesa) that would be particularly good, or, more to the
> point, if the *assembly* can be generated stand-alone that's really
> good.
> 
More info on building llvm and use it in mesa this gist
https://gist.github.com/Venemo/a9483106565df3a83fc67a411191edbd#building-llvm-and-using-it-with-mesa

> then it can be run through the python-based simulator, which can do around
> 2,500 instructions per second on high-end hardware, and that's perfect for
> running short programs.
> 
> in parallel with that, a c-based simulator can be written, which can do
> 100,000 instructions per second even on low-end hardware.
> 
> 
> btw a word of caution: if expanded out to a single 1D linear sequence
> there are over a QUARTER OF A MILLION possibly even HALF A MILLION
> instructions in SVP64.
> 
> let the implications sink in for a minute.
> 
> LLVM Vector ISA support will have assumed that there are a limited number
> of instructions, possibly as many as 1,000, maybe even 10,000 when all
> intrinsics are permuted out, so it is "perfectly fine" to have programs
> which auto-generate all possible IR combinations.
> 
> for SVP64 this approach would create multi-megabyte IR files.
> this is down to the fact that there is a 32-bit opcode space *MULTIPLIED*
> by a 24-bit prefix.
> 
> it would be much, much better if LLVM's IR was designed around the 2D
> {prefix}{suffix} concept rather than the 1D {prefix * suffix} space.
> 
> but, we work with what we've got.

-- 
You are receiving this mail because:
You are on the CC list for the bug.