[J-core] Video output on Turtle

[Cedric Bail]

Moving our discussion regarding Turtle design and constraint on the graphics part.

On Thursday, January 23, 2020 7:30 PM, Rob Landley <rob at landley.net> wrote:
> On 1/23/20 8:15 PM, Cedric Bail wrote:
> > Supporting 640x480 in digital only is ok, but if you are to go
> > with analogic, maybe supporting 576i and 420i would make sense to
> 

> We picked 640x480 because it's the closest VGA size that maps down to analog
> easily. (Horizontal resolution's sort of a handwave based on clock speed, but
> vertical is a 1-1 mapping.)

I see.

> We're using DVI, not HDMI, because it's out of patent. (HDMI is backwards
> compatible with DVI signals.)

Make sense and you get the DVI signal over the HDMI bits. From what I remember
this could be valid all the way up to 1080p, so quite enough margin with using
a non patented technology.

> > (So 720x576 at 50 and 720x420 at 60) with the rest of the space being padded
> > when generating analogical signal. 576i is ~30% bigger than 640x480,
> 

> 640x480 is 80x60 characters in an 8x8 font.
> 

> > it might already be challenging without any other hardware help to handle
> > this resolution.
> 

> Oh our hardware could generate a much faster output, the problem is memory
> bandwidth. We have one DRAM controller and are constantly streaming from it to
> refresh the display. I think it eats something like 20% of the bandwidth? (We
> have the numbers somewhere.)

Oh! I wasn't expecting that the DRAM controller would be that much of a
bottleneck. Arguably memory bandwidth is almost always the limiting factor. This
sounds like the total memory bandwidth would be something around 150MB/s. Would
you have that number somewhere?

> > An ARM at 500Mhz with NEON is what Qt would require to
> > handle this resolution at 24fps.
> 

> Nah, it's circuitry, not processor doing it. And we can scroll the screen
> vertically for _free_ by treating the bitmap as a ring buffer and have the
> starting location in a register.

Yes, that is an old trick for handling scrolling, especially in space shoot em
up style of game. Console can also use it to implement their scrolling ability.
I am wondering if we can use the Kernel KMS API to express this kind of
scrolling in a way that the console can use it right away.

> > EFL could do slightly better, but overall without SIMD it would be very
> > hard. Ideally having faster memset and memcpy would be also an improvement.
> > It really depends if the display system is important to the project or not.
> 

> It is, but the concerns you're raising seem completely unrelated? We may
> implement 2D acceleration at some point (bitblt via dma), but our first pass is
> just "raw linux framebuffer driver".

Indeed, I was expecting the CPU to be a bottleneck in its current state as I was
expecting memory bandwidth to be higher (I think I did a newbie error when reading
the LX45 specs and read MB/s when it was Mb/s). Anyway, I would not recommend
spending to much effort on a 2D acceleration unit as most software have completely
given up on supporting anything but KMS/DRM and OpenGL. The KMS/DRM allow for
multiple layer to be composited in hardware and software usually expect a small
amount of them with some constraint (Like size and color space). Having support
for hardware plane with different colorspace would allow for "compression"
and reduced memory bandwidth for compositing some use case (YUV background with a
pallettised buffer on top for example).
   The memory bandwidth constraint is going to be where the challenge and
interesting technics are. SIMD would most likely barely have any meaningful impact
from what I understand. Even if it might reduce a bit the amount of code being
processed, the framebuffer will still be the main contender for bandwidth.

Cedric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - cedric.bail at pm.me - 0x1FE1EA3D.asc
Type: application/pgp-keys
Size: 1805 bytes
Desc: not available
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20200124/bf6bfd68/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20200124/bf6bfd68/attachment.sig>