-# Draft letter
+# Letter to OpenPOWER Foundation Board of Directors
-* letter to OpenPOWER Foundation Board of Directors
* purpose: dialog on how LibreSOC and RED Semiconductor propose extensions
* review thread: <http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002258.html>
* 25mar2021 first revision
* fix typos
* grammar fix
+* 30mar2021 - sent
to be sent to:
* OPF Board board@openpowerfoundation.org
-* Tim Ansell blog@mithis.com
+* Tim Ansell me@mith.ro
* Toshaan Bharvani
* James Kulina
* Mendy
As you know the LibreSOC team have been working for over 3 years on a massive conceptual upgrade to the OpenPOWER ISA, based on Cray-Style Vectors, which will modernise it for today's 3D and VPU workloads, with an incidental side-effect of upgrading it for future supercomputing needs over the next few decades in a clean and elegant fashion.
-RISC-V has RVV, ARM has SVE2, x86 has AVX512, whilst OpenPOWER has an out-of-date SIMD ISA which is already so large that efforts to update it would do far more harm than good. It goes without saying that over the past few decades, SIMD has been demonstrated to be harmful.
+RISC-V has RVV, ARM has SVE2, x86 has AVX512, whilst OpenPOWER has an out-of-date SIMD ISA which is already so large that efforts to update it to suit modern 3D Shader and Video workloads would do far more harm than good. It goes without saying that over the past few decades, SIMD has been demonstrated to be harmful.
https://www.sigarch.org/simd-instructions-considered-harmful/
More than that, going far beyond the "letter" of our obligations to respect the stability of the OpenPOWER ecosystem, given that LibreSOC is targeting high-profile mass-volume general-purpose computing, it is our duty and responsibility to ensure that use of EXT22 does not result in end-user developer pressure for upstream tool-chains to override the OPF's remit, by *unintentionally* de-facto dominating EXT22 for LibreSOC use simply by popular overwhelming end-user demand, outside of everyone's control.
-We are also getting slightly concerned in that the resources needed (SPR allocations, allocation of Reserved v3.1 64 bit EXT01 prefix space to support SVP64) is quite large, and well outside of the "anticipated" resources allocated for Sandboxing, yet after one year we still have no two-way communications channel established to discuss the possibility of additional reservations.
+We are also getting slightly concerned in that the resources needed (SPR allocations, allocation of Reserved v3.1 64 bit EXT01 prefix space to support SVP64) is quite large, and well outside of the "anticipated" resources allocated for Sandboxing. There is no allocation of EXT01 *at all* for example. Yet after one year we still have no two-way communications channel established to discuss even the possibility of additional reservations.
-The advice in the PowerISA v3.0C document therefore *require* us to contact the OpenPOWER Foundation, to initiate the process of including our opcodes, and SVP64, in the OpenPOWER ISA.
+The advice in the PowerISA v3.0C document *requires* us to contact the OpenPOWER Foundation, to initiate the process of including our opcodes, and SVP64, in the OpenPOWER ISA, yet, here, we run into an interesting twist.
In speaking verbally and informally with various people (Toshaan, Paul and Hugh) we have pieced together the way that the OpenPOWER Foundation ISA Workgroup is to be set up, and we have become aware that there may be a mis-match here caused by "otherwise normally expected" provenance of ISA proposals which, from what we can gather, is being built-in to the ISA WG's by-laws.
The key person acting as the bridge between both world will be myself (Luke Leighton), and I will ensure *and require* that RED Semiconductor provides adequate funds and resources for the long haul, in order to not only see through the proposals but also ensure that the associated toolchains, test suites, documentation etc. are properly written and maintained, long-term. Yet I stress, again, that despite committing the financial resources, RED Semiconductor will *not* own the Copyright or any patents on LibreSOC work.
-My question to you is, therefore: what is the best way forward, here? What "vehicle" or arrangement would be suitable that takes into account these unique circumstances? Would a conference call perhaps be a good idea to discuss a way forward?
+Our goal here is the ongoing long-term evolution of OpenPOWER, meeting
+the needs of an entirely new market of end-users currently not served by
+OpenPOWER or any OPF Members, and still maintaining the long-term stability and reputation of the OpenPOWER ecosystem.
+
+My question to you is, therefore: what is the best way forward, here? What "vehicle" or arrangement would be suitable that takes into account these unique circumstances? Would a conference call perhaps be a good idea to discuss?
Respectfully,
projects / libreriscv.git / blobdiff