[Tinkerphones] Librem 5

H. Nikolaus Schaller hns at goldelico.com
Sat Oct 28 16:38:09 CEST 2017


> Am 28.10.2017 um 15:45 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Saturday 28. October 2017 14.14.26 rhn wrote:
>> On Sat, 28 Oct 2017 13:33:17 +0200 "H. Nikolaus Schaller"
>> <hns at goldelico.com> wrote:
>>> 
>>> But I just found this morning:
>>> 	https://community.imgtec.com/developers/powervr/documentation/
>>> 
>>> This looks to be very important (dated 07 Apr 2017):
>>> 	http://cdn.imgtec.com/sdk-documentation/PowerVR+Instruction+Set+Referenc
>>> 	e.pdf
>>> 
>>> I haven't spent time to look through the other material, but it looks as
>>> if IMG has become much more open!
> 
> I think expectations are so low with Imagination Technologies and openness of 
> PowerVR that any new public documentation (if it is new) could easily pass by 
> unnoticed. I wonder if policies will change under their new ownership (subject 
> to approval of the acquisition).
> 
>>> Maybe this material is already sufficient to write an open source
>>> firmware for the PVR and assembler/compiler for shaders but this is
>>> something for 3D/GPU experts (you know I am hardware expert and still
>>> struggle with Linux kernels :).
>> 
>> this is a nice find! Quite a few documents there indeed.
>> 
>> As you have said, shaders got suddenly much easier. Still, there's a long
>> way to go from there, as shader ISA is only part of the equation. I had
>> just a skim, but I couldn't immediately find the two other important
>> pieces: communication protocol and, if it's relevant for this GPU,
>> initialization and power features.

Well, the communication protocol can either be found out by analyzing the
open source drivers on SoC side, e.g.:

	http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/letux-base/hns/gpu/pvr-v4

or we could think about developing our own. It must only match between libs and firmware.

The firmware is of course very important and almost unknown, except that it
exists and is loaded into the GPU by the SoC.

And to add another unknown: memory management.

> 
> I also saw this:
> 
> "Refer to the main PowerVR ISR document (NDA required) for precise information 
> regarding feature availability."

Yes, I have seen this as well, but if it is about feature availability only,
we could start with the lowest common denominator which would be PowerVR 5.

> 
> I don't see any opcode or instruction format details, so perhaps this is also 
> an obstacle.

Yes, but there has been done some reverse engineering years ago. It was just
not possible to match that with assembler mnemonics:

	http://web.archive.org/web/20161110215418/http://powervr.gnu.org.ve/doku.php?id=opcodes
	http://web.archive.org/web/20160423202102/http://powervr.gnu.org.ve/doku.php?id=instructionencoding

We were never able to understand what these bit patterns mean. With the new documentation
it seams in reach.

And for instruction encoding, there are also tools for download to compile
shader code from source (PowerVRShaderEditor). It looks like it shows a disassembler
listing, just not the binary. But if we have the binary of known code, it is not that
difficult to deduce the encoding scheme.

For example:

#version 310 es

precision mediump float;

in vec4 inVertex;
out vec2 textureCoordinate;

void main()
{
    textureCoordinate = vec2(1.0, 1.0);
	gl_Position = inVertex;
}

=>

0    : mov ft0, vi3
       mov ft0.e0.e1.e2.e3, ft0
       uvsw.write ft0, 3;

1    : mov ft0, vi2
       mov ft0.e0.e1.e2.e3, ft0
       uvsw.write ft0, 2;

2    : mov ft0, vi1
       mov ft0.e0.e1.e2.e3, ft0
       uvsw.write ft0, 1;

3    : mov ft0, vi0
       mov ft0.e0.e1.e2.e3, ft0
       uvsw.write ft0, 0;

4    : mov ft0, c64
       mov ft0.e0.e1.e2.e3, ft0
       uvsw.write ft0, 5;

5    : mov ft0, c64
       mov ft0.e0.e1.e2.e3, ft0
       uvsw.write ft0, 4;


> 
> [...]
> 
>> Depending on the level of control that firmware has on PVR, replacing it
>> may be necessary. With new NVIDIA cards, nouveau is stuck with power
>> issues: clock speeds can only be altered by signed firmware they have no
>> access to. I haven't seen anything about firmware among the PVR docs.
> 
> This kind of thing was already worrying me, and now you have confirmed that it 
> is actually done, which is very troubling indeed.

As far as I have experiences, it is not. At least for the older SGX530 and SGX544
inside TI SoC.

BR,
Nikolaus




More information about the Community mailing list