reword openpower section

diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn
index 072de1d684ffdfb8395b25b0ebddc798c5306cd0..6a9ca7b36c2aeae519460f65b4ace40ffda1ac89 100644 (file)
--- 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.