[J-core] How crazy would a nommu debian port be?

[Rich Felker]

On Sun, Aug 21, 2016 at 02:17:49PM -0700, Cedric BAIL wrote:
> On Fri, Aug 19, 2016 at 10:02 PM, D. Jeff Dionne
> <Jeff at se-instruments.co.jp> wrote:
> > Turtle has as noted below HDMI, and I've tested the hardware.
> > Turtle also has composite video, which I have not tested. Making a
> > quick circuit that generates timing for VGA, HDMI or composite
> > video is very simple (a few 10s lines of RTL), the question is
> > really if you want to be able to alter that timing or if it is
> > acceptable to have one or a small number of fixed resolutions (at
> > first, this could be fine).
> 
> Well, HDMI is kind of an overkill, but if it is there, it is
> definitively enough :-)

>From a standpoint of physical hardware on the board I suspect it's
actually simpler/cheaper, because you don't need a DAC. I assume this
is why the Numato board has low-quality 2/3/2 bit RGB on its VGA port
-- to avoid the cost of a proper DAC.

> As for a small number of fixed resolutions,
> does that means we could change the supported resolution in the VHDL
> and just rebuild it to match the output ? Or would it requires more
> work ? If it would be the first case, I believe that would be
> perfectly fine in my opinion.

I'm not clear on whether there's any reason to prefer fixed
resolutions. It's probably just a matter of whether the support for
programmable clock multiplier/divider is too costly for a small fpga.
I'm not really qualified to judge that but my guess would be not.

> > The issue is drawing into the buffer in the first place. Rich did
> > some benchmarking on memory copy, and this is a similar problem
> > set. With come clever programming or hardware, one could get DMA
> > assist on block copy.
> 
> Yes, I am expecting that. memcpy and memset are usually the limit on
> every hardware when doing graphics anyway. That's why the most
> important technic is to not draw anything if possible :-) Partial
> update and hardware plane are usually the best helper there. If you
> look at your screen how many pixels do really change at once. That's
> the only thing your CPU really need to work on. With clever UI design
> and proper cut off on the useless drawing, a J2 should provide enough
> possibility, but you are indeed pointing to an interesting point.
> Would it be possible to speedup memcpy and memset with some DMA assist
> ? It is usually not possible as the cost of going into the kernel and
> setting up MMU destroy all possible gain, but maybe on a J2 it makes
> sense.

Yes, but for it to be architecturally reasonable (and future-proof to
J3/J4 with mmu) for userspace Linux binaries to use dma memcpy, we'd
need to add a dma_memcpy syscall. There's precedent for this on
blackfin so I think it may be reasonable. But it would only make sense
for large, well-aligned copies.

> > But the real win would come from hardware assist on 2D primitives,
> > which X or anything else could use. That would make for an
> > interesting project, but not something our team here will be able
> > to spend time on, or even look into...
> 
> Hum, I don't know. Today, none of the major toolkit use X primitive
> and they are badly supported by all major GPU driver. I don't even
> know if a 2D raster accelerator (something that would allow arbitrary
> line compositing) would be beneficial, as the maintenance and porting
> of pixman and cairo will be quite tricky.

If nothing else, accelerated blit via dma would be a useful driver
feature and less invasive than dma memcpy for userspace.

Rich