Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] Fall 2022 Interfaces
Date: Fri, 12 Jun 2020 14:30:42 +0100
Message-ID: <CAPweEDxSRNtU2Y8AS2Xc+mCP7wEpDtCUJkRuJ9k3bk5VHb9jKw@mail.gmail.com> (raw)
In-Reply-To: <8CDFD090-B84C-4013-BE76-D4815DDB7F5A@gatech.edu>

On Fri, Jun 12, 2020 at 1:38 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
>
> > that may not be enough to handle framebuffers as well as run an OS.
> > framebuffers are scarily demanding of memory bandwidth and they absolutely
> > MUST have total absolute top priority.
>
>
>  The OMI interface has 3200MT/s which is the same spec as DDR4.

3200 million transactions/sec, let's assume 8 bytes.  that's 3200
megabytes per second.  25 gigabit / 8 equals 3.125 so that fits with
the math , there.  one 25 gigabit lane provides 3200 million 8-bit
transactions per second (3.125).

4k is 1200 megabytes per second: 37.5% *percent* of the total memory
bandwidth consumed by a 4k 60fps framebuffer!  and if people wanted
120 fps instead, that's now a staggering 75% of a single OMI interface
dedicated to the framebuffer!

bear in mind that that is *just* the framebuffer hardware.  the CPU -
the GPU - is contending for the exact same memory resource.

we cannot possibly expect the GPU to operate effectively at that kind
of resource-starved level.  bear in mind that not only the GPU 3D
Vulkan / bitmap / texturisation data has to go over that same
interface, the Operating System *also* has to swap in and out as well

to get that down to only 5% of total bandwidth, going to 64 bytes per
transaction would, if i am reading this correctly, require *eight* of
those 25 gigabit per second SERDES.

and that alone is going to be mental as far as power consumption is
concerned.  i don't exactly know what the power consumption of a
single lane 25 gigabit SERDES is going to be, i am trying to recall
the conversations last year with Rudi when i visited him: it will
however be extremely important to find out.

i have a *vague* recollection of a number somewhere around 300mW.  if
we assume that to be correct, then those 10x Rx and 14x Tx would be
somewhere around *eight watts* just for the SERDES alone!


so here we have the basis of actionpoints, which i would suggest be
put into the bugtracker (otherwise we'll lose track, which i'm
starting to do, already, thank you gmail)

* to make a decision as to what top level of visual performance is
needed (maximum resolution, maximum framerate)
* calculate the framebuffer data transfer rate for that.
* to decide some top level of GFLOPs and MTriangles/sec (and other
waffly figures for the GPU side)
* estimate the memory bandwidth for the GPU side
* decide if we want to develop a hardware compression algorithm
between memory and framebuffer (an augmentation of Richard Herveille's
RGBTTL framebuffer RTL)
* find out the power consumption in 45nm for these SERDES
* talk to Rudi to see if he can do a SERDES PHY for us
* talk to SymbioticEDA likewise
* talk to Dmitri from LIP6.fr to see what he can do, whether a stable
50 GHz clock is achievable in 45nm (i understand from Dmitri that for
a given target clock - 25 gbit/sec in this case - you need the PLL to
do double the clockrate)

l.

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

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12  2:59 Yehowshua
2020-06-12  3:00 ` Yehowshua
2020-06-12  4:01 ` Jacob Lifshay
2020-06-12  4:33   ` Cole Poirier
2020-06-12  5:46   ` Yehowshua
2020-06-12  7:07   ` Yehowshua
2020-06-12 11:03   ` Luke Kenneth Casson Leighton
2020-06-12 11:21     ` Luke Kenneth Casson Leighton
2020-06-12 12:38     ` Yehowshua
2020-06-12 13:30       ` Luke Kenneth Casson Leighton [this message]
2020-06-12 14:06         ` Hendrik Boom
2020-06-12 14:23           ` Cole Poirier
2020-06-12 19:34     ` Yehowshua
2020-06-12 19:43       ` Yehowshua
2020-06-12 21:42       ` Luke Kenneth Casson Leighton
2020-06-12 23:17         ` Jacob Lifshay
2020-06-13  0:10           ` Luke Kenneth Casson Leighton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPweEDxSRNtU2Y8AS2Xc+mCP7wEpDtCUJkRuJ9k3bk5VHb9jKw@mail.gmail.com \
    --to=lkcl@lkcl.net \
    --cc=libre-riscv-dev@lists.libre-riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git