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
next prev parent 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