[libre-riscv-dev] SoC Video Output

[Luke Kenneth Casson Leighton]

On Sun, Oct 7, 2018 at 7:02 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> I was wondering if the video output we were planning on
> using with the new GPU supports multiple video planes
> (basically like windows in a GUI, but implemented in hardware)

 no: it's a plain framebuffer (vga_lcd by richard herveille)  if
something like that is needed, it will need implementing [or tracking
down].  it will be possible to change the address of the framebuffer:
i'll have to ask and check if changes to it can be synchronised so as
to not cause frame-tearing.... it does!

 https://github.com/RoaLogic/vga_lcd

 so it has triple-buffering.

> and if there is a driver already written supporting KMS with mmap-able
> framebuffers, where the memory is allocated from system ram

 as the idea is to do a mobile-class SoC, there's no distinction
between types of RAM.  it's completely shared, just like with other
embedded GPUs.

> (aka not being slow for the cpu to access or uncachable) and where
> each framebuffer can be allocated a little larger than what's actually
> used so the GPU can have the framebuffer laid out in a tiled fashion
> when rendering to it then transition back to a linear layout for display?

 vga_lcd is a linear design.  in other SoCs (the allwinner a20 for
example) i have seen them do separate "rescaling" blocks (the A20's
rescaler can do YUV to RGB of arbitrary pixel sizes as well), where it
might be a good idea to have something like that, as a separate
DMA-based engine.

 or, let's think about it a minute.  from what jeff bush tells me, the
most expensive thing (power-consuming) is getting the data in and out
through the L1/L2 caches.  so this is why it will be very important to
have a scratch memory area (for tiles).  and to work on one tile until
it is complete, and only then write it out (once) to main memory.

 if that is feasible, my thoughts are: it may be worthwhile to have a
custom instruction that can "target" any given tile out to lhe linear
framebuffer.

> If the driver is not upstream yet, we should try to get it
> upstream soon so we can use the upstream kernel on the soc.

 the only reason i happen to have a linux kernel driver matching
richard's vga_lcd work is because ICubeCorp used vga_lcd in the
IC3128.  it's a very, very lucky break.

 i haven't looked at the source code since 2012: i expect it to be
very, very basic.  it does however support the full range of bit
depths (including monochrome) which is great.

l.