LibreSOC Still Striving To Produce An Open-Source Hybrid CPU/GPU Built On OpenPOWER

[lkcl]

This is true, but not relevant here. LibeSOC had no extensions to add (although maybe at some point they would have).

not true. i spent 5 months on the simulator and the unit tests, and around 18 months on developing the standards, collating a huge amount of information. this cost me - personally - my own money, and also wasted NLnet funding. that's EU funds wasted. the EU Commission has been alerted.

The NDA isn't required to design extensions, only to go through the RISC-V standardisation process when dealing with other companies. As no sane company would entertain running a software 3D renderer on a CPU, the NDA to work with others is beside the point.

a Trademark Holder is not permitted to make such discriminatory judgements. not, "and continue to hold the Trademark". if they had such issues, they should have had the guts to tell us to our faces.

instead, they systematically failed to respond, in *direct* violation of their responsibilities under Trademark Law.

i won't provide you with a copy of the derogative and discriminatory message i received from david patterson.

[lkcl]

The thing that really helps with the POWER ISA, is that it's been around for decades, and at one point it was even quasi mainstream due to Apple. It's also seen some various other uses such as GameCube/Wii/WiiU, PS3, and XBox 360. And, as you noted, is still around as a server platform.

yehyeh - the "Cell Processor".

I'm not a major CPU expert by any means, but something I read many years ago is that the PPC ISA was pretty well designed from the start and was designed with 64-bit support eventually being added. It definitely helps it is one of the newest of the old RISC designs so it had hindsight to draw from and as a result doesn't have any of the gimmicks of that era such as register windows and branch delay slots.

absolutely: condition registers were a huge part of it, you calculate the branch condition as a result of one instruction, then the *only* way you can do a branch is by evaluating one of the CRs. this decoupling saves a huge number of instructions and resources.

basically, if you look closely, you find evidence that OpenPOWER is specifically designed for high performance.

A year+ ago, I decided to learn some PPC Assembly. Wasn't too bad as far RISC goes. Helps that I studied some SPARC back in my university days.

nice. yeah i am having to get right down to nitty-gritty assembly level, especially with the Vector Engine, man that's been a lot of work finally just started on implementing that. https://libre-soc.org/openpower/sv/i...ation/

[ultimA]

not true. i spent 5 months on the simulator and the unit tests, and around 18 months on developing the standards, collating a huge amount of information. this cost me - personally - my own money, and also wasted NLnet funding. that's EU funds wasted. the EU Commission has been alerted.

Why did you find it important to try to add the extensions designed for LibreSOC as official RISC-V extensions? Your primary goal should be to finish the implementation as fast as possible, at this stage spending 18 months to standardize your custom extensions without any real industrial partners interested in them seems very questionable to me. ATM that looks like much more where the funding got wasted instead of others not talking to you. Given that you could have just implemented your extensions for your own use, and then deal with the standardization after you've shown the new ideas actually work (which would also help incite external interest in your extensions).

[Old Grouch]

...So what if one of the instructions got modified out because there was an issue where TSMC had a patent conflict with Intel? That level of transparence isn't important IMO.

Thank you for sharing your opinion, Not everyone agrees about the level of importance, which is why this argument keeps on returning.

With regard to attending all meetings, you are right: but people do want to be able to see meeting minutes (or indeed recordings of the meeting/video conference). It is pretty much the same principle as courtrooms having public galleries, and council/government chambers having public galleries. For people to trust the output, it has to be possible for people to audit the proceedings. You don't need to attend every meeting: but attend a random sample and check the minutes accord with your experience. Openness and transparency in law and government is a long-standing, hard-fought principle (and yes, courts and government chambers do go into closed sessions, so sometimes secrecy is necessary, but covering all activities with a blanket NDA is not the same thing).

Doing things properly is hard. And it may be that LibreSOC is not the right path, but I hope it, or something like it succeeds.

[lkcl]

Why did you find it important to try to add the extensions designed for LibreSOC as official RISC-V extensions?

because the nature of a hybrid mass-volume CPU-VPU-GPU is to be upstream. think about it: if we were doing a proprietary design, like Think Silicon did, we could have done it entirely as Custom Extensions. no source code from that company has or will ever see the light of day.

Custom Extensions in RISC-V are specifically designed for one of two primary purposes:

1) academic or "open source" research (read "absolutely no commercial value")

2) hidden proprietary secretive closed-source hard-fork implementations which will never see the light of day. for example: Western Digital's Custom Extensions in their proprietary HDD / SSD Firmware.

can you see how neither of those is appropriate for a *high profile* mass-volume CPU-VPU-GPU processor where all sources are upstream? RISC-V Custom Extensions *must not* be allowed into upstream sources for toolchains because of the conflict that arises.

Your primary goal should be to finish the implementation as fast as possible, at this stage spending 18 months to standardize your custom extensions without any real industrial partners interested in them seems very questionable to me.

cutting us off from communicating with those industrial partners was where the discrimination - in direct violation of Trademark Law - started.

ATM that looks like much more where the funding got wasted instead of others not talking to you. Given that you could have just implemented your extensions for your own use, and then deal with the standardization after you've shown the new ideas actually work (which would also help incite external interest in your extensions).

Simple-V for RISC-V was completed extremely early on. *it worked*. however david patterson had, by that time, already sent me a shockingly extraordinarily demeaning, dismissive and derogative message which, to be honest, i should have realised at that point that these are not nice people, with their own hidden agenda, and walked away.

by complete contrast, the OpenPOWER Foundation has been amazingly supportive.

[lkcl]

With regard to attending all meetings, you are right: but people do want to be able to see meeting minutes (or indeed recordings of the meeting/video conference). It is pretty much the same principle as courtrooms having public galleries, and council/government chambers having public galleries. For people to trust the output, it has to be possible for people to audit the proceedings. You don't need to attend every meeting: but attend a random sample and check the minutes accord with your experience.

exactly. for business reasons we chose transparency as a core fundamental principle. if you investigate why Supermicro was de-listed from NASDAQ you find that it was because they couldn't demonstrate the provenance of the components and source code after someone asked the pertinent question, "are there any spying backdoors in your motherboards or any of the components used on them?".

the moment we compromise *even once* on transparency, that's it, it's game over.

[hiryu]

That's pretty cool! Maybe I could check it out a bit. I don't really remember the small amount of x86 asm I did in college though, but it could fun.

Also I meant a positive impact on performance. The glibc 2.33 dynamic linker will load an optimized version for different cpu generations (by using more recent instructions from my understanding). P9 and P10 are among the first supported by this release, hence why I was curious if the gains would be small or noticeable.

CISC or "CISC" is the way to start IMO... POWER, like many RISC CPU's of its time has instructions of all the same length. I thought this was a RISC thing generally but ARM has some variable length instructions.

All your instructions are 4 bytes, which means your operands are limited to what can fit in 4 bytes (and instructions consist of opcodes, one or more operands, etc)... Which means to load ful 32 bit values (takes more instructions. And even more so for 64-bit values. These aren't a big deal, but something you won't be used to coming from CISC where don't have to think about operand sizes nearly as much.

Not sure if that glibc change will help too much. Time will tell.

[lkcl]

CISC or "CISC" is the way to start IMO... POWER, like many RISC CPU's of its time has instructions of all the same length. I thought this was a RISC thing generally but ARM has some variable length instructions.

the problem comes when you want to do multi-issue. an article on medium.com showed *why* the Apple M1 is literally pissing all over Intel, and it's down to the simplicity of the instruction decode phase.

very interesting reading:

https://debugger.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2

[ultimA]

because the nature of a hybrid mass-volume CPU-VPU-GPU is to be upstream. think about it: if we were doing a proprietary design, like Think Silicon did, we could have done it entirely as Custom Extensions. no source code from that company has or will ever see the light of day.

Custom Extensions in RISC-V are specifically designed for one of two primary purposes:

1) academic or "open source" research (read "absolutely no commercial value")

2) hidden proprietary secretive closed-source hard-fork implementations which will never see the light of day. for example: Western Digital's Custom Extensions in their proprietary HDD / SSD Firmware.

can you see how neither of those is appropriate for a *high profile* mass-volume CPU-VPU-GPU processor where all sources are upstream?

I'm only saying that upstreaming and commercialization could have waited a lot longer, For example, keep your custom extensions in the 1st category above temporarily (you intend to stay open-source in the long term too anyway so should be hardly a problem for you), then when you have an early working prototype showing advantages over the competition, go start the industrialization and with that the standardization process. That's what a great many of other projects do, kind of even necessary.

RISC-V Custom Extensions *must not* be allowed into upstream sources for toolchains because of the conflict that arises.

No problem, because upstreaming your extensions at this point in time is not the right thing to do anyway. Toolchains are rarely interested in upstreaming custom extensions unless there's significant interest in them and you can make upstream believe someone will stay committed for their maintenance over a long-ish time. Usually people just maintain their toolchain patches locally until they reach a high degree of maturity and also enough community interest to actually use them today. Neither is the case with LibreSOC yet. So you maintain them locally for the time being and then there is no such conflict you speak of, then when the hardware actually starts to mature and it is time for commercialization, you upstream the toolchain parts. This doesn't mean you have to keep anything secret until this comes about, just share your own sources until then.

[hiryu]

the problem comes when you want to do multi-issue. an article on medium.com showed *why* the Apple M1 is literally pissing all over Intel, and it's down to the simplicity of the instruction decode phase.

very interesting reading:

https://debugger.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2

I'll have to give this a read... But yeah, I've often wondered out loud how much power, chip real estate, and therefore performance x86 has to spend on instruction decoding.