[raspi-internals] Re: Rpi - cutting graphic stack?

  • From: Herman Hermitage <hermanhermitage@xxxxxxxxxxx>
  • To: "raspi-internals@xxxxxxxxxxxxx" <raspi-internals@xxxxxxxxxxxxx>
  • Date: Thu, 5 May 2016 21:17:38 +1200

Hi deco33000
(Apologies for the delay answering, I seem to have lost all rpi internals 
emails for a few months).
Good question.
I'm sure the answer many of us would like to hear is "no layers" :) ie just 
banging hardware registers directly from library / user code.
However we don't have that level of understanding of the hardware registers, 
and/or there is quite a high level of complexity required.
For simple bare metal, some people choose to get by with just the dumb 
framebuffer and forgo all acceleration for the sake of a simple API.
To get acceleration I guess most userland programs use APIs  like dispmanx, 
OpenGL ES etc which talk to the videocore side to do the real work.
The code at https://github.com/raspberrypi/userland is what you would replicate ;
to pass work to services on the videocore side.
Not exactly bare metal, but that is probably the simplest interface to exploit 
the high performance blocks on the SoC.
Cheers
From: deco33000@xxxxxxxxxx
To: raspi-internals@xxxxxxxxxxxxx
Subject: [raspi-internals] Rpi - cutting graphic stack?
Date: Wed, 17 Feb 2016 09:38:10 +0100

Hello, 

In a baremetal project, how many graphics layers do one really need to do video 
playback and simple graphics (cubes on screen, text) with hardware acceleration?

I would like to simplify and specialise the graphic stack for rpi. 

The end goal is learning to eventually teach.

Thanks

                                          

Other related posts: