[libre-riscv-dev] Fall 2022 Interfaces
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Jun 12 14:30:42 BST 2020
On Fri, Jun 12, 2020 at 1:38 PM Yehowshua <yimmanuel3 at 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)
More information about the libre-riscv-dev