Comment by lkcl | Hacker News Reader

Comment by lkcl | Hacker News Reader

Parent Full thread

There's a lot of red flags, from NIH HDL generator language, to using an OoOE core for GPU tasks, to suggesting that you don't talk to your lawyer in the NLNet FAQ

i ask people, if they want to help, not to waste money on talking to lawyers. specifically saying that if they really want to talk to a lawyer they should request that lawyer to donate their time as "pro-bono" due to the charitable funded nature of the project (NLnet is a Charitable Foundation).

i'm kinda stunned that two people actually genuinely asked this, rather than saying "i'll speak to my Accountant".

think about it: imagine being contacted by the Linux Foundation, offered some donations to do some work, and you respond, "oh, errr i demand the right to pay 30% of that charitably-sourced money you are offering me to my Lawyer in fees to check if it's ok to receive that charitably-sourced money", i mean, wtf?? :)

regarding using an OoO engine: you may be interested to review this:

https://www.pixilica.com/post/pixilica-s-founder-atif-zafar-...

we're trying something new, basically. that's down to being funded by NLnet to do innovative research.

You have to admit "don't talk to your lawyer about our pretty close to unique legal situation" is pretty sketch. There's plenty of situations where you can get pro bono legal advice, so encouraging people not to without knowing their situation sends the exact wrong message, that your arrangement might not stand up to legal scrutiny or comes with a bunch of unstated tradeoffs that might not be apparent.

Regarding OoO, I don't see anything in those slides that's in favor of an OoO GPU. And the fundamental die area tradeoffs between a GPU and an OoO core are different. OoO comes with the idea that you can spend 10x+ the die area on your dispatch logic than your ALUs and register file, and your GPU is designed to amortize the dispatch logic as much as possible against a sea of ALUs and register files since you have enough parallelism to just barrel schedule through massive amounts of threads. Both designs at their best keep their ALUs fed every clock, but a GPU just plain can dedicate much more die area to those ALUs meaning markedly more FLOPs per mm^2.

i appreciate the perspective. with Asperger's, i'm just literal and up-front. i do make it clear that Bob Goudriaans is a Chartered Account, specialising in International Tax Law. perhaps i should also mention that NLnet has been operating for 18 years, now?

no i didn't go into heavy details on the internal architecture, i did the study (with help from Mitch Alsup) on OoO for 5 months straight, back at the beginning of 2019. when he explained how easy it is to do multi-issue if you use Unary (bit-level) encoding on the Dependency Matrices, i went, "ok that's it, we're using that" :)

what the plan is, is to do instead of big.LITTLE, to do "long.FAT" :)

by that i mean, we will have one core that is high multi-issue and high clock rate, but the rest of the cores are MASSIVE on SIMD engines but light on issue (single or dual).

all still SMP, but some cores just absolute processing Monsters.

now, we'll still need a separate Texture Cache (in addition to I-Cache and D-Cache) because texture interpolation, we'll still need a pixel tile memory area, and so on

but we want to see how far we can get and still not have everything shipped over to a completely separate processor. that is madness, the driver development alone having to contain a full-on RPC mechanism. no wonder latency on GPU Shader execution is so bad on commercial CPUs.

Reply on news.ycombinator.com