From 423712408b2ba02c9759db3676701c9b56f850de Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 29 Mar 2020 10:22:14 +0100 Subject: [PATCH] reword openpower section --- ...23_2020mar26_decoder_emulator_started.mdwn | 31 ++++++++++++------- 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn index 072de1d..6a9ca7b 100644 --- a/updates/023_2020mar26_decoder_emulator_started.mdwn +++ b/updates/023_2020mar26_decoder_emulator_started.mdwn @@ -281,16 +281,28 @@ the newly-announced OpenPOWER Foundation effort as it progresses. One of the most important things that we, Libre-SOC, need, and are discussing with Hugh and Tim is: a way to switch on/off functionality -over a limited 32-bit opcode space, so that we have one mode for +in the (limited) 32-bit opcode space, so that we have one mode for "POWER 3.0B compliance" and another for "things that are absolutely essential to make a decent GPU". With these two being strongly mutually exclusively incompatible, this is just absolutely critical. +Khronos Vulkan Floating-point Compliance is, for example, critical not +just from a Khronos Trademark Compliance perspective, it's essential +from a power-saving and thus commercial success perspective. If we +have absolute strict compliance with IEEE754 for POWER 3.0B, this will +result in far more silicon than any commercially-competitive GPU on +the market, and we will not be able to sell product. Thus it is +*commercially* essential to be able to swap between POWER Compliance +and Khronos Compliance *at the silicon level*. + POWER 3.0B does not have c++ style LR/SC atomic operations for example, -and if we have half a **million** data structures **per second** that need -SMP-level inter-core mutexes, and the current POWER 3.0B multi-instruction -atomic operations are used, we're highly likely to use 10 to 15 **percent** -processing power consumed on spin-locking. +and if we have half a **million** 3D GPU data structures **per second** +that need SMP-level inter-core mutexes, and the current POWER 3.0B +multi-instruction atomic operations are used - conforming strictly to +the standard - we're highly likely to use 10 to 15 **percent** processing +power consumed on spin-locking. Finding out from Tim on one of these +calls that this is something that c++ atomics is something that end-users +have been asking about is therefore a good sign. Adding new and essential features that could well end up in a future version of the POWER ISA *need* to be firewalled in a clean way, and we've been @@ -300,13 +312,8 @@ and experience inside IBM, for them to consider. Some help in reviewing it would be greatly appreciated. These and many other things are why the calls with Tim and Hugh are a -good idea. The amazing thing is that they're taking us seriously. I believe -I may have mentioned (at least on the mailing list), that there have been -several people inside IBM and other places, working quietly for a long time -to get OpenPOWER in place - and, critically, *done right*. I believe Hugh -mentioned that it was quite amusing that several people contacted him to -say "why aren't you doing what RISC-V is doing, being open and all?" whilst -he and others had been quietly spearheading an effort to that for some time! +good idea. The amazing thing is that they're taking us seriously, and +we can discuss things like those above with them. Other nice things we learned (more on this below) is that Epic Games and RaptorCS are collaborating to get POWER9 supported in Unreal Engine. -- 2.30.2