[libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Cole Poirier]

Hi Libre-SOC Developers,

I have been working on a first draft of the script/contents of a
presentation pitching Libre-SOC to Amazon Alexa's IOT division. I have
put what I've been able to come up with on my own on a wiki page here: https://libre-soc.org/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/.

If you can, please review what I have written and edit, rearrange, and
add relevant points as you see fit. I would appriciate help specifically
in filling in or correcting technical details or false claims that I
have made.

Thank you, your help will be essential in putting together an impressive
and polished presentation for our potential customers at Amazon Alexa's
IOT division.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Luke Kenneth Casson Leighton]

On Mon, Jun 8, 2020 at 12:42 AM Cole Poirier <colepoirier@gmail.com> wrote:
>
> Hi Libre-SOC Developers,
>
> I have been working on a first draft of the script/contents of a
> presentation pitching Libre-SOC to Amazon Alexa's IOT division. I have
> put what I've been able to come up with on my own on a wiki page here: https://libre-soc.org/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/.

(i moved it to here, sorry!
https://libre-soc.org/systemes_libre/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/
)

> If you can, please review what I have written and edit, rearrange, and
> add relevant points as you see fit. I would appriciate help specifically
> in filling in or correcting technical details or false claims that I
> have made.

"GPU is in ADDITION to CPU (2 processors, 2 ISAs, 2 compilers)"

the idea being, it's 3 things, where as the presentation is made,
voice goes down, down, down.  punch, punch, punch.

i've done a little bit more, do take a look.

l.



> Thank you, your help will be essential in putting together an impressive
> and polished presentation for our potential customers at Amazon Alexa's
> IOT division.
>
> Cole
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Jacob Lifshay]

On Sun, Jun 7, 2020, 16:56 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Mon, Jun 8, 2020 at 12:42 AM Cole Poirier <colepoirier@gmail.com>
> wrote:
> >
> > Hi Libre-SOC Developers,
> >
> > I have been working on a first draft of the script/contents of a
> > presentation pitching Libre-SOC to Amazon Alexa's IOT division. I have
> > put what I've been able to come up with on my own on a wiki page here:
> https://libre-soc.org/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/.
>
> (i moved it to here, sorry!
>
> https://libre-soc.org/systemes_libre/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/
> )
>
> > If you can, please review what I have written and edit, rearrange, and
> > add relevant points as you see fit. I would appriciate help specifically
> > in filling in or correcting technical details or false claims that I
> > have made.
>

I added some notes.

Jacob

>
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Staf Verhaegen]

Jacob Lifshay schreef op zo 07-06-2020 om 17:29 [-0700]:
> On Sun, Jun 7, 2020, 16:56 Luke Kenneth Casson Leighton <lkcl@lkcl.net>wrote:
> > On Mon, Jun 8, 2020 at 12:42 AM Cole Poirier <colepoirier@gmail.com>wrote:
> > > Hi Libre-SOC Developers,
> > > I have been working on a first draft of the script/contents of apresentation pitching Libre-SOC to Amazon Alexa's IOT division. I haveput what I've been able to come up with on my own on a wiki page here:
> > 
> > https://libre-soc.org/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/.
> > (i moved it to here, sorry!
> > https://libre-soc.org/systemes_libre/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020/
> > )
> > > If you can, please review what I have written and edit, rearrange, andadd relevant points as you see fit. I would appriciate help specificallyin filling in or correcting technical details or false claims that Ihave made.
> 
> I added some notes.

OK, some comment from a guy coming out of the hardware development world. I may sound skeptical but this is to help you and prepare for a possible skeptical audience.

I get the advantage of RTOS and RPC needed between CPU and GPU; we will have to see how important your audience will find this.
Playing devil's advocate I would even wonder if IoT devices typically need a display (and thus GPU) functionality anyway ? Or if they do, can't they just live with a simple framebuffer; possibly with some 2D acceleration ?
Will the libre-SOC GPU instructions have advantage for machine learning/artificial intelligence ?

Big part of your pitch is based on power advantages, as also indicated by Jacob I would be very prudent in doing power claims without having real numbers to back it up.
Modern design techniques and recent (proprietary) EDA tools are good at having virtually no power consumption when a circuit is not doing anything. So I don't see a reason why your combined CPU-GPU would be so much better in power consumption then a chip with a CPU and GPU. Given that you currently are doing power instruction set I expect you will have more power consumption in decoding the power instruction set, so even if the GPU part would cause less overhead would you still be better than ARM + MALI or RISC-V + some GPU ?
As always I like to be proven wrong by real numbers.

Also to get there several man-years of development of the open source EDA tool chain will be needed: proper parasitic extraction of interconnects, timing driven P&R, support for DVFS (dynamic frequency voltage scaling), clock gating, power gating, ...

If there will be ASIC hardware developers in your audience they will be very skeptical when you present power consumption numbers based on simulation and will likely want to see the details how you derived the numbers; they will just dismiss power claims made on principle. Reason is that in smaller nodes power consumption is mainly driven by the capacitive load of the interconnects so doing power claims without an actual implementation in the targeted node is considered just guessing.

I don't understand the BOM advantage when CPU and GPU are integrated in one chip, e.g. ARM Cortex + MALI GPU.

greets,
Staf.


_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Luke Kenneth Casson Leighton]

On Mon, Jun 8, 2020 at 11:17 AM Staf Verhaegen <staf@fibraservi.eu> wrote:

> Given that you currently are doing power instruction set I expect you
> will have more power consumption in decoding the power instruction set,
> so even if the GPU part would cause less overhead would you still be
> better than ARM + MALI or RISC-V + some GPU ?

the architecture of a CPU + GPU arrangement is as follows:

* CPU L1 I-Cache, D-Cache
* GPU L1 I-Cache, D-Cache
* inter-connect on-die Shared Memory Bus between CPU and GPU.

therefore, to perform even the simplest GPU-based instruction - even
just the one instruction, the following must be actioned:

* CPU must run a compiler that turns (Vulkan?) command into GPU instructions
* CPU must "package" GPU instructions into a serial buffer.
* CPU must send the serial buffer through the CPU L1 D-Cache, onto the
Shared Memory Bus, into the GPU L1 I-Cache
* GPU must execute the instructions.
* GPU must respond indicating completion of the commands, back through
the L1 Caches, over the Shared Memory Bus.

in a hybrid architecture, steps 2 thru 5 are replaced with *DIRECT*
execution of the GPU instruction.

it should be clear that a complex detailed gate-level power analysis
of this scenario is not needed, because even at a high level it should
be obvious that there is significant power consumption just by having
this type of dual-processor architecture compared to a hybrid one.

where that does *NOT* work is if design mistakes are made in the
hybrid CPU-GPU architecture such as having insufficient registers.

Jeff Bush's Nyuzi work showed very clearly that the highest power
consumption of a GPU is getting the data through the L1 cache barrier.
GPU workloads are almost exclusively:

* LOAD
* compute
* STORE

with negligeable or zero cross-references between each cycle.  compare
this with general-purpose CPU workloads:

* LOAD
* partial compute
* STORE
* LOAD partial results (from multiple *different* previously
partially-computed prior sequences)
* compute
* STORE

i vaguely recall somewhere someone saying that the cross-referencing
of prior data, in general-purpose CPU workloads, is somewhere around
30% back-referencing of prior data.  in GPU workloads, due to the
parallelism, this is **ZERO** for the majority of data (hundreds of
megabytes per second)

therefore if *any* of the GPU data has to go back through the L1 Cache
(because there are not enough registers), it can result in a whopping
50% increase in power consumption when compared to a design that does
have enough registers to keep the computation from spilling over.

again: this does not need gate-level analysis, it's just a design
architectural fact.


another key critical aspect of what we are doing is down to the fact
that the CPU and GPU - being now one and the same - effectively have
the exact same I-Cache.

normally in a split CPU-GPU architecture, CPU execution would be
unaffected by GPU workload execution, because it is totally
*different* I-Caches.  because they are different, the designers of
the GPU ISA completely ignore instruction compactness, often using
VLIW (128-bit instructions) or 64-bit instructions, on the basis that
each of these instructions is executing 4 parallel tracks (4x FP
operations), and that therefore the high bang-per-buck ratio easily
justifies the large instruction rate.

with a shared I-Cache, when executing GPU instructions these require
context-switching the CPU instructions out. such massively-large
instructions become a serious problem for a hybrid architecture.

therefore, to that end, we effectively designed Simple-V to be a
"hardware compression algorithm" - to compress a *Vectorised* ISA at
the *hardware* level.

instead of 64 or 128 bit Vector instructions, we have 32-bit
Vector-capable instructions and in some cases even 16-bit
Vector-capable instructions.

this *drastically* reduces I-cache utilisation, which is a major
factor in power consumption due to context-switching.


all of these things are at the architectural level.  we are not doing
anything fancy at the gate level.  it is a matter of making
*architectural* decisions that reduce power consumption, operating
within the exact same gate-level power consumption constraints as
every other ASIC out there.

how exactly this would be communicated - in summary form - to
Executives, i have no idea.


> I don't understand the BOM advantage when CPU and GPU are integrated in one chip, e.g. ARM Cortex + MALI GPU.

i also commented that this is incorrect.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Staf Verhaegen]

Luke Kenneth Casson Leighton schreef op ma 08-06-2020 om 12:13 [+0100]:
> 
> how exactly this would be communicated - in summary form - to
> Executives, i have no idea.
> 

I think it should be doable in a few slides showing the two alternative
block diagrams and how data moves through it.

greets,
Staf.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Hendrik Boom]

On Mon, Jun 08, 2020 at 12:13:48PM +0100, Luke Kenneth Casson Leighton wrote:
> 
> all of these things are at the architectural level.  we are not doing
> anything fancy at the gate level.  it is a matter of making
> *architectural* decisions that reduce power consumption, operating
> within the exact same gate-level power consumption constraints as
> every other ASIC out there.

You point out that the CPU and GPU share cache, being the same processor.

But we are designing a four-core chip?  To what extent to the four 
cores share cache?

And on avoiding data copying between CPU ad GPU:

I believe the OpenGL API involves copying data from CPU buffers to GPU 
buffers, with the understanding that the CPU copies can be discarded 
while the GPU goes on with its copy.

Having the same storage for both sets of buffers could obviously obviate 
these copies, except that software that uses this API will likely rely 
on being able to overwrite the CPU-side buffers with impunity.  So the 
copy will still have to be done.

Do I misunderstand OpenGL?  Is Vulcan different?  Will users want to 
bypass these libraries and use the graphics instructios directly?  Or 
is there some other sublety I'm missing? 

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Lauri Kasanen]

On Mon, 8 Jun 2020 09:55:54 -0400
Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> And on avoiding data copying between CPU ad GPU:
>
> I believe the OpenGL API involves copying data from CPU buffers to GPU
> buffers, with the understanding that the CPU copies can be discarded
> while the GPU goes on with its copy.
>
> Having the same storage for both sets of buffers could obviously obviate
> these copies, except that software that uses this API will likely rely
> on being able to overwrite the CPU-side buffers with impunity.  So the
> copy will still have to be done.
>
> Do I misunderstand OpenGL?  Is Vulcan different?  Will users want to
> bypass these libraries and use the graphics instructios directly?  Or
> is there some other sublety I'm missing?

Your understanding is correct at a high level, one way of using OpenGL
will have to do that memcpy even on the Libresoc. Vulkan is explicit and
there are other ways in OpenGL too.

However you're missing the copy after that. On a traditional system,
using OpenGL that way, there will be a copy after the memcpy, to
transfer everything over PCI-E to the GPU. That's one of the copies that
Libresoc eliminates.

Intel and AMD APUs may also eliminate that, sharing the main RAM, but
integrating the GPU in the same package does not save them from
marshalling the commands. Etc.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Luke Kenneth Casson Leighton]

(btw thank you staf for the insights)

On Mon, Jun 8, 2020 at 2:56 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:
>
> On Mon, Jun 08, 2020 at 12:13:48PM +0100, Luke Kenneth Casson Leighton wrote:
> >
> > all of these things are at the architectural level.  we are not doing
> > anything fancy at the gate level.  it is a matter of making
> > *architectural* decisions that reduce power consumption, operating
> > within the exact same gate-level power consumption constraints as
> > every other ASIC out there.
>
> You point out that the CPU and GPU share cache, being the same processor.

yes.  or: the CPU instructions and GPU instructions, by being in the
same ISA, the GPU *workload* will push CPU workload(s) out of the
(same) L1 Cache.

>
> But we are designing a four-core chip?

yes.  therefore there will be 1x L1 Data and 1x L1 Instruction Cache
per each of those four cores.

>  To what extent to the four cores share cache?

L1?  not at all - ever.

> And on avoiding data copying between CPU ad GPU:
>
> I believe the OpenGL API involves copying data from CPU buffers to GPU
> buffers, with the understanding that the CPU copies can be discarded
> while the GPU goes on with its copy.

... because the assumption is that the GPU is a completely and utterly
separate processor, the "command" to perform that copy is expected to
involve the excruciatingly-painful process previously mentioned, from
which i excluded the userspace-kernelspace context-switching so as not
to have people run away screaming in terror.

in our case: it would simply be... a memcpy.

> Having the same storage for both sets of buffers could obviously obviate
> these copies, except that software that uses this API will likely rely
> on being able to overwrite the CPU-side buffers with impunity.  So the
> copy will still have to be done.

sounds reasonable to me.  actually now that i think about it, if the
buffer is placed into a shmem segment with copy-on-write semantics,
the memcpy will not be needed, and the "overwriting", because of the
CoW semantics, would only be done on-demand.

this however would be an optimisation.

the *only reason* that we can even remotely consider such an
optimisation is precisely because of the hybrid architecture.

> Do I misunderstand OpenGL?  Is Vulcan different?

don't know.

> Will users want to bypass these libraries and use the graphics instructios directly?

only if they want to become an assembly-level expert, with all the
inherent implications and performance-complexity tradeoffs that always
come with doing assembly programming.

> Or is there some other sublety I'm missing?

no idea :)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Cole Poirier]

Thank you Staf, Lauri, Hendrick, Jacob, and Luke, your provided
insights, criticisms, and questions have allowed me to make a much
more informative script for Wednesday's pitch. I'm still working on
the revised script, however I now have a work-in-progress polished
version of the presentation to show. There's a 1 min recorded video of
the presentation available on youtube (unlisted) here
(https://www.youtube.com/watch?v=0alD47XlsbM) if you'd like to take a
look. Unfortunately youtube has lowered the quality. Also the
script/text on the slides in the video is out of date and will be
updated tomorrow.

Thank you all, again, your help has been incredibly valuable,

Cole


On Mon, Jun 8, 2020 at 8:28 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> (btw thank you staf for the insights)
>
> On Mon, Jun 8, 2020 at 2:56 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> >
> > On Mon, Jun 08, 2020 at 12:13:48PM +0100, Luke Kenneth Casson Leighton wrote:
> > >
> > > all of these things are at the architectural level.  we are not doing
> > > anything fancy at the gate level.  it is a matter of making
> > > *architectural* decisions that reduce power consumption, operating
> > > within the exact same gate-level power consumption constraints as
> > > every other ASIC out there.
> >
> > You point out that the CPU and GPU share cache, being the same processor.
>
> yes.  or: the CPU instructions and GPU instructions, by being in the
> same ISA, the GPU *workload* will push CPU workload(s) out of the
> (same) L1 Cache.
>
> >
> > But we are designing a four-core chip?
>
> yes.  therefore there will be 1x L1 Data and 1x L1 Instruction Cache
> per each of those four cores.
>
> >  To what extent to the four cores share cache?
>
> L1?  not at all - ever.
>
> > And on avoiding data copying between CPU ad GPU:
> >
> > I believe the OpenGL API involves copying data from CPU buffers to GPU
> > buffers, with the understanding that the CPU copies can be discarded
> > while the GPU goes on with its copy.
>
> ... because the assumption is that the GPU is a completely and utterly
> separate processor, the "command" to perform that copy is expected to
> involve the excruciatingly-painful process previously mentioned, from
> which i excluded the userspace-kernelspace context-switching so as not
> to have people run away screaming in terror.
>
> in our case: it would simply be... a memcpy.
>
> > Having the same storage for both sets of buffers could obviously obviate
> > these copies, except that software that uses this API will likely rely
> > on being able to overwrite the CPU-side buffers with impunity.  So the
> > copy will still have to be done.
>
> sounds reasonable to me.  actually now that i think about it, if the
> buffer is placed into a shmem segment with copy-on-write semantics,
> the memcpy will not be needed, and the "overwriting", because of the
> CoW semantics, would only be done on-demand.
>
> this however would be an optimisation.
>
> the *only reason* that we can even remotely consider such an
> optimisation is precisely because of the hybrid architecture.
>
> > Do I misunderstand OpenGL?  Is Vulcan different?
>
> don't know.
>
> > Will users want to bypass these libraries and use the graphics instructios directly?
>
> only if they want to become an assembly-level expert, with all the
> inherent implications and performance-complexity tradeoffs that always
> come with doing assembly programming.
>
> > Or is there some other sublety I'm missing?
>
> no idea :)
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 2:17 AM Cole Poirier <colepoirier@gmail.com> wrote:

> version of the presentation to show. There's a 1 min recorded video of
> the presentation available on youtube (unlisted) here
> (https://www.youtube.com/watch?v=0alD47XlsbM) if you'd like to take a
> look.

0:49 - billions of cryptocurrency is lost if the hardware wallet
cryptochip cannot be trusted.

that's the "fear" version.  do we want to present a "fear" strategy?
(you know what i mean)

rework:

0:49 - cryptocurrency hardware wallets and banking identification
terminals containing cryptochips can be trusted if the hardware is
formally verified and the entire HDL available for a full independent
audit.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Cole Poirier]

On Jun 9 2020, at 3:34 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 0:49 - billions of cryptocurrency is lost if the hardware wallet
> cryptochip cannot be trusted.
> 
> that's the "fear" version.  do we want to present a "fear" strategy?
> (you know what i mean)
> 
> rework:
> 
> 0:49 - cryptocurrency hardware wallets and banking identification
> terminals containing cryptochips can be trusted if the hardware is
> formally verified and the entire HDL available for a full independent
> audit.

Thanks, I like that formulation much better. I'll make these edits on
the wiki page, and send a link with the updated video later today. Or
Yehowshua may be able to embed the presentation. We will see.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Hendrik Boom]

On Mon, Jun 08, 2020 at 06:17:17PM -0700, Cole Poirier wrote:
> Thank you Staf, Lauri, Hendrick, Jacob, and Luke, your provided
> insights, criticisms, and questions have allowed me to make a much
> more informative script for Wednesday's pitch. I'm still working on
> the revised script, however I now have a work-in-progress polished
> version of the presentation to show. There's a 1 min recorded video of
> the presentation available on youtube (unlisted) here
> (https://www.youtube.com/watch?v=0alD47XlsbM) if you'd like to take a
> look. Unfortunately youtube has lowered the quality. Also the
> script/text on the slides in the video is out of date and will be
> updated tomorrow.

Looked at it today.  Seems somewhat OK, but on a few pages there's too 
much text to read for the short time the page is on-screen.

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Cole Poirier]

On Jun 9 2020, at 3:01 pm, Hendrik Boom <hendrik@topoi.pooq.com> wrote: 
> Looked at it today.  Seems somewhat OK, but on a few pages there's too 
> much text to read for the short time the page is on-screen.

Thanks for taking a look Hendrick. Yes, sorry, the video is far too
fast, it was just done so I could show you what the pitch looked like in
it's more marketing-friendly form. Yehowshua is working on getting the
presentation embedded on systemeslibres.org, where it will hopefully be
interactive like other slide decks, so one can navigate at their desired pace.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Yehowshua]

It actually already works - it is a huge WIP:
https://systemeslibres.org/prez/assets/player/KeynoteDHTMLPlayer.html#0 <https://systemeslibres.org/prez/assets/player/KeynoteDHTMLPlayer.html#0>

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Request for input and technical expertise for Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020

[Hendrik Boom]

On Tue, Jun 09, 2020 at 08:44:35PM -0400, Yehowshua wrote:
> It actually already works - it is a huge WIP:
> https://systemeslibres.org/prez/assets/player/KeynoteDHTMLPlayer.html#0 <https://systemeslibres.org/prez/assets/player/KeynoteDHTMLPlayer.html#0>

Much easier to read in this format.  but there's some du[lication, and, of course, 
it's obviously not finished. 

-- hendrik

> 
> Yehowshua
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev