<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 23, 2020, 12:49 Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The big thing doing what Jacob did before, and from memory where he<br>
went wrong despite advice to the contrary is he skipped the<br>
"vectorises it" stage, which is highly important for vector CPU<br>
execution, as opposed to scalar GPU.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">IIRC, my plan for Kazan all along was/is to vectorize and multi-thread it, I just didn't get that far during the GSoC portion due to running out of time, so, in order to get it to do something more impressive than parse SPIR-V I kludged a rasterizer onto it during the last few weeks of GSoC.</div><div dir="auto"><br></div><div dir="auto">Originally, my plan was to write a whole-function vectorization pass as a LLVM pass. The new plan is to have the vectorization pass be done in a new IR (shader-compiler-ir) before translating to LLVM IR since LLVM IR isn't very good at retaining the structured IR needed to do full-function vectorization. That also has the benefit of supporting non-LLVM backends, such as cranelift.</div><div dir="auto"><br></div><div dir="auto">For the rewritten version in Rust that I'm still working on (when not working on the hardware design side), I'm not going to skip ahead and actually get it to work properly.</div><div dir="auto"><br></div><div dir="auto">Jacob</div></div>