<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 23, 2020, 16:31 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">
It's hard to know then what you can expect to leverage from Mesa for<br>
that sort of architecture, the SPIRV->NIR translation, and then you<br>
probably want some sort of driver specific NIR->LLVM translation,<br>
amdgpu is completely scalar, llvmpipe is manually vectorised, swr does<br>
something like you might want, afaik it does a scalar translation and<br>
then magic execution (but I haven't dug into it except to fix<br>
interfaces).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Kazan isn't built on Mesa or NIR (though it was originally intended to integrate with Mesa). Luke decided that Libre-SOC should also have a similar Mesa-based driver and applied to NLNet for funding for it, Vivek is currently starting on implementing that Mesa driver.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think you will hit problems with vectorisation, because it's always<br>
been a problem for every effort in this area, but if the CPU design is<br>
such that everything can be vectorised and you never hit a scalar<br>
path, and you workout how texture derivatives work early, it might be<br>
something prototype-able.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">My current plan for screen-space derivatives in Kazan is to have the fragment shaders vectorized in multiples of 4 pixels (IIRC there's a nvidia vulkan extension that basically requires that), so adjacent fragment shader can be subtracted as-needed to calculate derivatives.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But none of the current mesa drivers are even close to this<br>
architecture, llvmpipe or swr are probably a bit closer than anything,<br>
so it's likely you'll be doing most of this out-of-tree anyways. My<br>
other feeling is it sounds like over architecting, and reaching for<br>
the stars here, where it might be practical to bring vallium/llvmpipe<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I would expect it to be quite easy to get llvmpipe to run on Libre-SOC's processor, since it is PowerPC-compatible, it just won't have very good performance due to llvmpipe's architecture.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
up on the architecture first then work out how to do the big new<br>
thing, or bring up this architecture on an x86 chip and see it works<br>
at all.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The plan is to get Kazan working with vectorization on x86, then change the backend out to unmodified PowerPC (LLVM may scalarize the instructions here), then add the new vector ISA to the PowerPC backend, then add custom instructions as-needed to improve performance.</div><div dir="auto"><br></div><div dir="auto">Jacob</div></div>