Imagination Technologies and future daughterboards

[veloknight]

Hey all,

I don't know if anyone else here has seen this, but apparently Apple and Imagination Tech are going to go mostly separate ways. While Imagination Technologies might still wind up with some income from Apple, everyone seems to think this is a big blow for them. I know the current OMAP5 SoC the Pyra uses has a PowerVR GPU - I was wondering if anyone wanted to discuss or speculate the possible fallout from any shakeup in the ARM GPU space for future Pyra daughterboards.

 

[Exophase]

IMG barely has a presence anymore outside of Apple SoCs, which is why the Apple licensing issue is such a crippling blow to them. So odds are that a successor Pyra SoC wouldn't have used an IMG GPU anyway. But it doesn't really matter, for the most part the GPUs are interchangeable.

Might be a good idea not to release software for Pyra that relies on PVRTC (PowerVR's proprietary texture compression format) without including fallbacks for other more generally supported formats.

 

[vcoleiro1]

Already a trhread on this here: https://pyra-handheld.com/boards/threads/apple-ends-gpu-contract-with-imagination-powervr.80141/

 

[Exophase]

Already a trhread on this here: https://pyra-handheld.com/boards/threads/apple-ends-gpu-contract-with-imagination-powervr.80141/

Yeah but that's just a general offtopic about the news, while this is about the actual implications it'll have on the Pyra's future development.

But I don't think there'll be very much to this one.

 

[TrashyMG]

Texas Instruments has ownership of providing graphic drivers for their SoCs.

 

[levi]

Texas Instruments has ownership of providing graphic drivers for their SoCs.

Do they develop them themselves though? I'd be surprised if there wasn't a lot of input from imgtec, although it's always possible that it's TI's repackaging that gimped certain old builds of course.

 

[TrashyMG]

Do they develop them themselves though? I'd be surprised if there wasn't a lot of input from imgtec, although it's always possible that it's TI's repackaging that gimped certain old builds of course.

I'm sure they do have a lot of input during initial development, but the SGX 544 MP2 is most likely already as developed as it can be and Ti already has the means of building these drivers themselves.

 

[Grench]

Do they develop them themselves though? I'd be surprised if there wasn't a lot of input from imgtec, although it's always possible that it's TI's repackaging that gimped certain old builds of course.

There isn't exactly a line forming of SoC manufacturers willing to sell their product/systems to small projects. I am thankful that TI was willing to allow this project to purchase their product.

 

[JonnyH]

Do they develop them themselves though? I'd be surprised if there wasn't a lot of input from imgtec, although it's always possible that it's TI's repackaging that gimped certain old builds of course.

I believe TI use 99% of the code from our 'reference' driver, with most of the changes being in platform integration code and whatnot. I would be surprised if there were many (any?) people at TI who knew the 'core' shader compiler or GLES state tracker well enough to make effective changes without a large amount of digging through the code and playing around first.

And TI had the full code, and are able to modify/build it as required with no ImgTec involvement.

 

[Kev2442]

I'll add to what has already been said that the GPU part being integrated into the CPU chip (the bare-bones principle of an SoC in fact), we never bought it directly from them. And about future boards, I don't think anybody really bet on PowerVR because no major manufacturer makes any high-end chips based on it anymore... not that I know of anyway. (EDIT : excluding Apple of course)

 

[Exophase]

And about future boards, I don't think anybody really bet on PowerVR because no major manufacturer makes any high-end chips based on it anymore... not that I know of anyway. (EDIT : excluding Apple of course)

The only notable exceptions I can find in the smartphone SoCs space are Mediatek Helio X30 and Spreadtrum SC9861G-IA (which is also an x86 Airmont SoC manufactured by Intel)

 

[Kev2442]

Well that might actually be a good option for future SoCs. Plus we already know a bit about PVRs.

 

[Grench]

The only notable exceptions I can find in the smartphone SoCs space are Mediatek Helio X30 and Spreadtrum SC9861G-IA (which is also an x86 Airmont SoC manufactured by Intel)

Maybe move away from the smartphone SoC space and into the automotive infotainment SoC space?
https://pyra-handheld.com/boards/threads/linux-on-arm-automotive-infotainment-socs.80145/

 

[JonnyH]

Maybe move away from the smartphone SoC space and into the automotive infotainment SoC space?
https://pyra-handheld.com/boards/threads/linux-on-arm-automotive-infotainment-socs.80145/

Automotive tends to have slightly different use cases - for example the jacinto6 (effectively the progression of the omap5 into the car space) has a very large number of video decoders, but no faster cpu or gpu than the omap5 itself.

And power constraints are often a little relaxed compared to mobile - the worry is more the cost of verification and possibly heat, so they tend to be a generation behind or so compared to most mobile SoCs. And the vendors may be even less able to deal with 'small unit' runs if they're used to selling millions at a time to Ford.

But it might be an area that does offer something useful

 

[Grench]

But it might be an area that does offer something useful

TI is a bit behind in this space, but there are others. Are you familiar with the Renesas H3 and M3?

H3 SoC process: 16nm?
H3 CPU: Quad A-57, Quad A53, Dual R7
H3 GPU: IMG PowerVR Series6XT GX6650
H3 Devboard: Unavailable but listed at $850 - may just be a placeholder as the chips are barely in fabrication now.

M3 SoC process: Unknown
M3 CPU: Dual A-57, Quad A53, Dual R7
M3 GPU: Imagination Technologies PowerVR® Series 6XT GX6250
M3 Devboard: Available for $311.25

Both use LPDDR4 memory. From what I can tell, they can control 4 screens, 5 SD card type interfaces, multiple USB (maybe not OTG though), 8 cameras (likely irrelevant), oodles of memory (64bit part), SATA, serial debugging, etc... Renesas appears to be emphasizing an automotive Linux build as the primary target OS. From what little poking around I've done, they seem to be taking Linux and OSS fairly seriously - they even have a public GIT for these.

With in-car infotainment and multiple OLED/LCD panel based gauges & displays and multiple cameras all over the car, vehicle SoCs seem to be moving forward at seeming light speeds.

Granted to fit them into a mobile handheld form factor, heat is going to be an issue. But - the heat should be relative to the processing power. Where they seem to be using a 16nm process, the performance per watt should be significant. Hypothetically a handheld could simply not use 3/4 of the 8-10 processing cores and whatever other stuff is in there of less interest and bring the energy use and heat down to a tolerable level.

I'm not saying, "We should use this chip!!!" I'm saying that in a year or two when examining available SoCs for a Pyra upgrade board, the project should look very carefully at what the automotive sector has been up to. There are signs that the automotive sector may be embracing Linux on ARM more readily than the handheld mobile sector ever has.

 

[JonnyH]

TI is a bit behind in this space, but there are others. Are you familiar with the Renesas H3 and M3?

Yes, I know Renesas (They used to be NEC ages ago, so they have had a *long* relationship with PowerVR). Though I personally don't work with them much, being mostly focused on Android right now.

I do not know how open to small quantities that we would be interested in, but possibly worth investigating. I also believe that Linux isn't the primary platform for them, as most automotive stuff works on RTOSs like neutrono, or virtualised Linux environments on top of similar, though they do appear to have pretty solid upstream support.

While both the M3 and H3 should be a decent upgrade from a omap5, the H3 is a *beast*. Though it might easily blow past the thermal/power limits we have.

 

[Letalis Sonus]

I also believe that Linux isn't the primary platform for them, as most automotive stuff works on RTOSs.

AFAIK they are usually using more specialized and MMU-less (hence Linux incompatible) chips like the Cortex-R family for their RT stuff, those heavy duty application class SoCs are targeting infotainment systems that don't have any need for realtime properties. These infotainment systems are usually running Linux (BMW, Mercedes) or some kind of Windows CE (Ford)

 

[JonnyH]

AFAIK they are usually using more specialized and MMU-less (hence Linux incompatible) chips like the Cortex-R family for their RT stuff, those heavy duty application class SoCs are targeting infotainment systems that don't have any need for realtime properties. These infotainment systems are usually running Linux (BMW, Mercedes) or some kind of Windows CE (Ford)

A *Huge* cost of anything attached to any automotive product is the verification, to *guarantee* that nothing can accidentally tell your car to "ACCELERATE A FULL POWER GOGOGOGO" because an app crashed, and that "necessary" processing is guaranteed a timeslice and not denial-of-serviced. This is on the infotainment systems, not even looking at the lower-level control systems, which often do run on specialized embedded 'realtime' chips. The requirements are lessened, but just being attached to the car information bus means it still has very strict standard it must meet.

The current focus here seems to be running a *much* simpler RTOS-style hypervisor, with a larger general purpose OS (like linux) below that. And that can have implications about how the drivers interact with the system so it may be some amount of work to get it running "bare metal" if the current code assumes it's not.

 

[Grench]

AFAIK they are usually using more specialized and MMU-less (hence Linux incompatible) chips like the Cortex-R family for their RT stuff, those heavy duty application class SoCs are targeting infotainment systems that don't have any need for realtime properties. These infotainment systems are usually running Linux (BMW, Mercedes) or some kind of Windows CE (Ford)

They do have a nice documentation start for installing Linux on the Renesas H3/M3 dev boards:
http://elinux.org/R-Car
http://elinux.org/R-Car/Boards/H3SK
http://elinux.org/R-Car/Boards/M3SK

 

[Letalis Sonus]

but just being attached to the car information bus means it still has very strict standard it must meet.

That's why gateways exist - a non-critical system shouldn't even be able to reach any safety critical systems through data packages.

The Linux kernel is able to provide RTOS features and even got a certification for that at some point, BTW.