<br><br>On Thursday, January 9, 2020, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

<div>
<div dir="auto">
<div dir="auto">Drive-by comment:</div></div></div></blockquote><div><br></div><div>really appreciate the feedback.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto"><div dir="auto"> I don't think you actually want to base any decisions an a vec4 architecture. Nearly every company in the graphics industry thought that was a good idea and designed vec4 processors. Over the course of the last 15 years or so they have all, one by one, realized that it was a bad idea and stopped doing it. Instead, they all parallelize the other way and their SIMD instructions and on scalar values across 8, 16, 32, or 64 invocations (vertices, pixels, etc.) Of the shader program.</div></div></div></blockquote><div><br></div><div>for simplicity (not outlining nearly 18 months of Vector Architecture ISA development) i missed out that we have designed a vector-plus-subvector architecture, where the subvectors may be of any length between 1 and 4, and there is an additional vector loop around that which may be from length 1 (scalar) to 64 </div><div><br></div><div>individual predicate mask bits may be applied to vector however they may only be applied (one bit) per subvector.</div><div><br></div><div>discussions have been ongoing for around 2 years now on the LLVM dev lists to support this type of concept.</div><div><br></div><div>on the libre soc lists we have also had detailed discissions on how to do swizzles at the subvector level.</div><div><br></div><div>AMDGPU, NVIDIA, MALI, they all support these capabilities.</div><div><br></div><div>to be clear: we have *not* designed an architecture or an ISA which critically and exclusively depends on vec4 and vec4 alone.</div><div><br></div><div>now, whether it is a bad idea or not to have vec2, vec3 snd vec4 capability, the way that i see it is that Vulkan supports them, as does the SPIRV compiler in e.g. AMDVLK, and we would be asking for trouble (performance penalties, compiler complexity due to having to add predicated autovectorisation) if we did not support them.</div><div><br></div><div>however, there are two nice things:</div><div><br></div><div>1. we are at an early phase, therefore we *can* evaluate valuable "headsup" warnings such as the one you give, jason (so thank you)</div><div><br></div><div>2. as a flexible Vector Processor, soft-programmable, then over time if the industry moves to dropping vec4, so can we.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto"><div dir="auto">That isn't too say that Mesa is there wrong choice or that there aren't other reasons why SwiftShader would be a bad fit. However, I would recommend against making major architectural decipmentsions for the sole reason that it allows you to repeat one of the biggest architectural mistakes that the graphics industry as a whole managed to make and is only recently (last 5 years) finally gotten over.</div></div></div></blockquote><div><br></div><div>consequently i am extremely grateful as the last thing we need is to spend NLNet funds on repeating industry mistakes.</div><div><br></div><div>this is why i love libre hardware.  can you imagine the hell it would have taken to get you signing an NDA just to be able to provide the insight that you did?</div><div><br></div><div>:)</div><div><br></div><div>warmest,</div><div><br></div><div>l.</div><div><br></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>