Re: screenblanker vs login
> Do they not understand that the market for their hardware would expand
> considerably if they'd supply the info and encourage our FSF aligned
> people to write the drivers,?
>
> Look at the nouveau situtation.
AFAIK Nvidia doesn't understand much more than ARM does: they get as
much in the way, but it's not like they're supportive of the
nouveau effort.
But I agree: ARM is being stupid.
>> Other relevant information is that Mali is really just the GPU,
>> i.e. a processor that can perform efficient computations like those
>> used for 3D rendering. This is separate from the display engine
>> itself (the thing that takes a framebuffer and pushes the pixels to a
>> screen), or from the video encode/decode hardware.
> And the framebuffer is both slow, and in the case of the pi, limited
> color depth, 5,6,5 I think as opposed to the full 8,8,8. The pi3b
> manages about 7 frames a second for a refresh rate running jessie and
> lxde.
The framebuffer is not an alternative to a GPU: the GPU is the
co-processor used to speed up generating images into the framebuffer, so
if you want to see something on your screen, you'll need
a framebuffer anyway.
Think of a GPU (such as Mali) as a specialized floating-point
co-processor. In the x86 world, the term GPU is used to refer to
a graphics card that incorporates various elements, such as the display
engine, the GPU per se, and the video en/decode engine. This is because
you can't easily get them separately. In the ARM world this is not so:
the Mali line of GPUs is just the GPU itself and is combined by SoC
vendors with various vendor-provided display engines and VPUs (video
processing units: the thingies that can perform encoding/decoding of
video and audio in specialized hardware). Note that VPUs also are
separate from the display engine: you may very well use a VPU on
a headless machine, e.g. to re-encode a video stream coming from
a camera before streaming it to a disk, or to re-encode a video stream
coming from a disk and streamed to some remote client for display.
> That does NOT give us a backplot thats in time with what the
> machine is doing. And that can be dangerous to both the machine and the
> operator if he gets in its way. But I do get the impression the
> framebuffer of a rock64 is some faster.
framebuffers are not faster or slower in this sense: all that they do is
to tell you: "here is a chunk of memory which I will send to your
HDMI/DVI/... connector at the usual 60Hz frequency".
Then someone else is in charge of actually drawing something useful into
it (and changing this something whenever needed). So, if you don't have
a GPU to do the writing, you use the CPU, and a faster CPU will result
in faster drawing.
> Color depth I haven't checked other than to note that synaptic, with
> its plethora of shades of white, is considerable more usable on
> a rock64 running stretch + xfce, than it is on the pi running lxde.
The color depth is specified by the framebuffer (aka display
engine), yes. If the driver is complete you can usually control the
color depth, the screen size (horiz x vert number of pixels), and the
refresh rate via things like xrandr.
>> So for example on Allwinner (sunxi) hardware there's recent progress
>> on getting support for the display engine (some of it already in
>> mainline Linux) and the video decoder (work still in progress).
> Having built the v4.14.15-rt13 kernel on the rock64, that has not or is
> not shown in the "make menuconfig" options when the arch is set for
> rockchip. At least not that I have tripped over.
IIRC the sunxi display engine driver (sun41-drm) now (i.e. in 4.15)
supports the A10/A20/A13 and A31(s?) CPUs. I don't know how far along
they are w.r.t support for more recent chips.
> However, I just checked the modules.builtin file in the built kernel tree
> and found this entry: kernel/drivers/gpu/drm/arm/mali-dp.ko but I've not
> a clue what it can do, primarily because there is not a ready recipe as
> to how to go about changing the kernel in a u-boot install. If anyone
> has that recipe, please share.
IIUC this is the kernel side of the Mali support: thanks to the GPL this
part of the Mali support legally has to be Free Software so it is
distributed that way (tho AFAIK it hasn't been integrated into the
mainline kernel because it doesn't try to integrate into the standard
GPU infrastructure). But to make use of the Mali GPUs you need to
couple that with a user-space driver which is only available as a blob
(and even distributing that blob legally is sometimes problematic).
Stefan
Reply to: