Letter to OpenPOWER Foundation Board of Directors

edit history:

  • 25mar2021 first revision
  • fix typos
  • grammar fix
  • 30mar2021 - sent
  • 31mar2021 - response received from Mendy (with many thanks)

to be sent to:

  • OPF Board board@openpowerfoundation.org
  • Tim Ansell me@mith.ro
  • Toshaan Bharvani
  • James Kulina
  • Mendy
  • cc Alain Williams
  • cc David Calderwood
  • cc Paul Mackerras
  • cc libre-soc-isa

actions required, resulting from response(s)

Contents

Dear OPF Board,

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 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/

Normally, such huge ISA development efforts would be instigated, organised and funded through either Academia or an extremely large Corporation, or a Consortium combining multiple such entities. It is therefore without precedent across the Computing Industry for something of this magnitude of effort to come not only from individuals with a completely independent non-affiliated Libre background but from a Libre background that is funded by a Charitable Foundation with a mandate to exclusively fund "Works for the Public Good" (NLnet).

From reading the PowerISA v3.0C sections we have learned and taken on board that a "Sandbox" opcode exists (EXT22) which is intended for "small private extensions" to the OpenPOWER ISA. The expectation that these extensions not be supported by upstream tool-chains is something with which we wholeheartedly agree.

The problem is that our Bit-Manipulation Extension alone, needed for Audio/Video and Cryptographic workloads, struggles to fit into that space, and we have not yet added Custom 3D opcodes or the IEEE754 Transcendentals (SIN, COS).

http://libre-soc.org/openpower/bitmanip

More than that, these are all "general-purpose" opcodes with uses far beyond LibreSOC's use-case (notwithstanding LibreSOC's use-case itself being by definition general-purpose).

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. 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 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.

From what we understand, individuals with no affiliation (to a Company or Academic Institution) would be prevented from tabling arbitrary ISA extensions (without a sponsor, that is). Given that the OPF ISA WG has to act entirely fairly i.e. in a non-discriminatory fashion towards all proposals, yet also take into account the huge burden of time and responsibility that results in perpetuity from any such inclusion, it is a reasonable balance. We understand and respect that proposers should demonstrate the willingness and access to resources sufficient to see through a long-term committment to the OpenPOWER ISA.

Yet at the same time, whilst being perfectly reasonable, we feel that our unique circumstances have not been anticipated. We would therefore welcome some constructive feedback as to how we would go about submitting our work, and also how we can communicate effectively that we are in this for the long haul, and are committed to seeing it through.

Note: the work that LibreSOC is doing is definitively intended for the long term. Thanks to NLnet's "Works for the Public Good" remit, even if, by some mischance, LibreSOC was to evaporate the work that we are doing would still be available since what we do is entirely libre.

At this point however it is important to provide some context as to why RED Semiconductor exists. RED Semiconductor is being set up to realise LibreSOC designs and concepts in actual silicon. It is NOT intended to REPLACE LibreSOC because to assign Copyright to a Corporation is prohibited by our relationship with NLnet (assigning to a Foundation however such as OPF is perfectly fine).

Therefore whilst we in LibreSOC as individuals are the actual non-affiliated architects of the ISA Extensions, RED Semiconductor will not own the Copyright but will be in exactly the same boat as any other Corporation at liberty to implement SVP64 because of its Libre provenance.

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.

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,

Luke Leighton