Archive

Posts Tagged ‘vivante’
Orange Pi Development Boards

Telechips TCC898x (Alligator) 64-bit ARM SoC is Designed for High-end 4K Set-Top Boxes

March 18th, 2016 3 comments

Telechips processors were often found in consumer devices such as Android tablets, mini PCs and TV Sticks a few years ago, but it’s been a while since I have seen a devices based on Telechips. So after seeing an automotive SoC from the company, I decided to visit the company website to check if they were still designing processors for the consumer market, and found TCC898x quad core Cortex A53 processor for “Smart Stick, IP-Client and STB with 4K 60fps decoding” with some interesting features.

Telechips_TCC8980Telechips TCC898x SoC specifications:

  • CPU- Quad core Cortex A53 processor with NEON, TrustZone, 32KB/32KB L1 cache and 512KB L2 cache
  • MCU – Cortex-M4 micro-controller
  • GPU
    • 2D – Vivante GC420 composition processing core for 4K user interfaces
    • 3D – ARM Mali-400MP2
  • VPU – Multi-format VPU and 4K VPU with HEVC and VP9 support
  • Memory I/F – DDR3/4
  • Storage I/F – NAND controller (60-bit ECC), SD/eMMC controller
  • Peripherals
    • Video Output – Display Controller, LVDS transmitter, HDMI 2.0 with HDCP 2.x, video composite
    • Video Input – Yes, but no details.
    • Audio – S/PDIF Tx and Rx, 9.1 channels I2S , stereo I2S
    • USB – USB 2.0 host, USB 2.0 OTG, USB 3.0
    • Gigabit Ethernet MAC
    • TS and TS demux (normally used to interface tuners)
    • PCIe interface
    • I2C, UART, GPSB (General Purpose Serial Bus), SDIO
    • Timer/RTC, DMA, IR receiver

The overall concept is pretty similar to their Telechips TCC893x Cortex A9 + Cortex-M3 processor, except most items have been upgraded, except notably the 3D GPU which remains a Mali-400MP2.

Telechips TCC898x supports Linux (with HTML5 interface) and Android operating systems, and contrary to most other Android TV boxes and set-top boxes, devices based on the new processor will support 4K user interfaces too thanks to Vivante GC420 2D GPU.  The chip also support hardware cyphers and conditional access (CAS) for “full compliance with 4K contents security guideline for variable STB applications”. I could not find much more information, and Googling for TCC8980 processor (and others up to TCC8989) did not return anything interesting so far. The last update to Telechips open source page shows the company released Linux 3.4.45 source code in February 2015.

Freescale i.MX6 DualPlus and QuadPlus SoCs Gets Faster 2D and 3D Graphics, Higher Memory Bandwidth

August 11th, 2015 5 comments

Freescale unveiled three new models for its i.MX 6 family processor for consumer, industrial and automotive markets in May. Two models are an upgrade to existing i.MX6 Quad and i.MX6 Dual processors, as the new i.MX 6QuadPlus and i.MX6DualPlus processors features four and two Cortex A9 cores, together with improved 2D and 3D GPUs delivering around 50% faster performance, an “optimized” SDRAM controller, more SRAM, and a prefetch and resolve engine. The third model, i.MX 6UltraLite, features a single ARM Cortex A7 core and hardware security, and targets applications such as electronic Point Of Sales (ePOS).

Freescale i.MX6 Processor Family

Freescale i.MX6 Processor Family (Click to Enlarge)

That means there are now 9 i.MX6 processors, and today, I’ll focus on the two new “Plus” versions. Since they are based on the original i.MX6 Quad and i.MX6 Dual processors, the best way to have a look at these is to compare them to their predecessors.

Features i.MX 6QuadPlus i.MX 6Quad i.MX 6DualPlus i.MX 6Dual
CPU 4x ARM Cortex A9 up to 1.2GHz 2x ARM Cortex A9 up to 1.2GHz
I-Cache/D-Cache 32KB/32KB L1, 1MB L2
Embedded SRAM 512KB 256KB 512KB 256KB
Memory Interface 2x 32 LP-DDR2, 1-ch, x 64 DDR3/LV-DDR3, Page and Channel Interleaving at 533 MHz
Hardware Video Acceleration Open GL ES 1.1/2.0/3.0
OpenCL 1.1 EP
OpenVG 1.1, 2DBLT, 8 layer composition, 4 shaders, 720 MHz, embedded prefetch and resolve engine
Open GL ES 1.1/2.0/3.0
OpenCL 1.1 EP
OpenVG 1.1, 2DBLT, 2 layer composition, 4 shaders, 594 MHz
Open GL ES 1.1/2.0/3.0
OpenCL 1.1 EP
OpenVG 1.1, 2DBLT, 8 layer composition, 4 shaders, 720 MHz, embedded prefetch and resolve engine
Open GL ES 1.1/2.0/3.0
OpenCL 1.1 EP
OpenVG 1.1, 2DBLT, 2 layer composition, 4 shaders, 594 MHz
Package 21 x 21 BGA 0.8mm

So we can see the SRAM doubled, GPU improvements include a faster shader frequency (720 MHz vs 594 MHz), and 8-layer composition support instead of just two, and the prefetch and resolve engine. Strangely the “newly optimized 64-bit DDR3/LVDDR3/LPDDR2-1066 memory interface to increase bus bandwidth ” is not reflected in this table, and the company did not name Vivante has the GPU vendor. The good news is that the news parts use the same package, and actually pin-to-pin compatible, meaning in due time we may see Wandboard Quad Plus or UDOO Quad Plus or other boards and products coming to market.

Freescale i.MX 6QuadPlus Block Diagram

Freescale i.MX 6QuadPlus Block Diagram

All other features and peripherals are identical including video playback capabilities, Gigabit Ethernet, SATA, low speed I/Os, and so one. The data in this table has been extracted from Freescale’s i.MX 6 Series Comparison Table.

Freescale posted a video comparing the 2D and 3D graphics performance of i.MX 6QuadPlus against i.MX 6Quad with a memory bandwidth, fractal, texture and 8-layer composition demos, indeed showing significant performance improvement in the order of 50% to over 100%.

i.MX 6DualPlus and i.MX 6QuadPlus processors have been sampling since May, but mass production is only planned for October 2015, while i.MX 6UltraLite processor must have started sampling in July 2015, with no date announced for production. More information should soon be available on Freescale i.MX6 product page.

Thanks to Nanik.

Marvell Announces Quad Core ARMADA 1500 PRO 4K STB SoC with HEVC 10-Bit Support

September 11th, 2014 No comments

Marvell has just announced a new member of its ARMADA 1500 family of multimedia processors with ARMADA 1500 PRO 4K (88DE3214), a quad-core ARM processor (12K DMIPS), with a Vivante GC3000 GPU, and Qdeo video processor supporting 4K (UHD) output and HEVC 10-bit codec. These processors will be used in smart TVs, set-top boxes (STB), over-the-top (OTT) boxes, thin-client devices, etc..

Block Diagram for Older ARMADA 1500 PRO SoC (no 4K)

Block Diagram for Older ARMADA 1500 PRO SoC (no 4K)

Details are scarce, but ARMADA 1500 PRO 4K could be an evolution of the ARMADA 1500 PRO processors with four Cortex A9 cores as shown above, but with a different GPU, 4K and HEVC support, and possibly some extra features for DRM. The key features mentioned by the company are as follows:

  • 3840×2160 (UHD) at 60 frames per second 10 bit HEVC Video Decode
  • Up to 12K DMIPs Quad Core ARM CPU
  • Multi-core GPU, 8 shader Vivante GC3000 GPU
  • Robust Security EngineSecurity features include Trusted Rendering Path and full TrustZone integration, which ensures the protection of premium content on the Android platform.

The company will provide Android and RDK SDKs. More information should eventually show up on Marvell ARMADA 1500 PRO 4K product page. Further details may also surface at  IBC, on September 12-16 in Amsterdam, where Marvell will showcase their latest solutions.

Vivante Unveils Details About GC7000 Series GPU IP Family

April 19th, 2014 9 comments

Earlier this month, Vivante Corporation has announced several silicon partner integrations (but no names given) of its GC7000 Series GPU IP into SoCs targeting wearables, mobile, automotive, and 4K TV products, and provided some more details about its GC7000 family which supports features such as OpenGL ES 3.1 API, and hardware TS/GS/CS (tessellation / geometry / compute shader) extensions for Android.

Vivante_GC7000_Architecture

According to the company, they key benefits of their GC7000 GPU IP can be summarized as follows:

  • True GPU Scalability – GC7000 Series products support limited silicon area to match form factor and market requirements. Products can snap to grid starting at 3.0 mm2 (28 nm) for the smallest single GPU GC7000 instance and grow in simple modular fashion for high end implementations to achieve what the company’s claims to be the the industry’s best PPA (power/performance/area).
  • Smallest Licensable OpenGL ES 3.1 Cores with Geometry, Tessellation, and Compute Shaders – Die area of the GC7000 is reduced by 20% over previous generation mass market cores and includes the new evolution of OpenGL ES 3.1 and DirectX 11 shader/GPU technologies and upcoming mobile platform requirements, including support for hardware TS/GS shading extensions for Android OS.
  • Faster Graphics Performance – Better real time utilization of shaders speeds up rendering performance, quality and effects to effectively scale up for 4K gaming content at 60 FPS.
  • Cooler Cores – GPU thermals and system power are reduced 30% and bandwidth is reduced by 50% through bandwidth modulation using Vivante frame buffer (vFB) and pixel compression, Khronos ASTC, geometry/tessellation shader rendering, and Android optimized intelligent composition (Regionizer).
  • Configurable Shader Core Implementations – Cores range from highly silicon optimized eight shader solutions to performance optimized multi-GPU/multi-shader solutions, all with hardware support for security (secure GPU) and OS virtualization.
  • Hardware and Software Integration Simplified – The single unified software stack supports all Vivante GPU cores and existing software platforms to create a seamless transition to the latest technologies. GC7000 hardware is even more modular to allow faster integration with easier place-and-route design and reduced wire congestion.
  • System Friendly Architecture – GC7000 is designed for hybrid and heterogeneous computing systems supporting OpenCL and HSA using AMBA ACE-Lite (CPU – GPU cache coherency) and the vStream interface. Other additions include a pixel compression fabric that allows GC7000 to create a streamlined pixel processing pipeline across the ISP, CPU, DSP, memory, and display processor.

GC7000 Series GPU cores come packaged with a single driver software stack that supports board support packages (BSP) running Android KitKat, Chrome OS, Linux, QNX, Tizen and Windows operating systems. They will also support Unreal Engine 4, Unity 4 and the upcoming Unity 5 SDKs

Vivante_GC7000_FamilyThere are currently 6 GPUS available from the GC7000 series with GC7000 UltraLite, GC7000 Lite, GC7000, GC7200, GC7400, and GC7600 with 8 to 256 Vega Shader Cores clocked up to 1GHz, and all supporting OpenGL ES 3.1, OpenGL 2.x desktop, and OpenCL 1.2. Performance will range from 32 to 1024 GFLOPS with medium precision operation, 16 to 512 GFLOPS for higher precision operations, and GC7000 GPUs will be able to deliver up to 25.6 GTextel/s and up to 16 Gvertex/s.

AndroidPC.es also reports GC7000 GPU performance, I’d assume GC7600 performance, should be 40% higher than Nvidia Tegra K1 “Kepler” GPU and 122% higher than Imagination Technologies PowerVR GPU GX6650 “Rogue 2.0”.

GCW Zero Handheld Console Runs 3D Games via Open Source Vivante GPU Drivers (Etnaviv)

December 16th, 2013 1 comment

GCW Zero is an open source handheld gaming console featuring Ingenic JZ4770 MIPS processor with Vivante GC860 GPU, 512MB RAM, 16GB internal storage, and a 3.5″ LCD with 320×240 pixels. The device runs Linux (OpenDingux) , and retro games and emulators. GCW Zero had a successful kickstarter campaign, and is now available in a few shops such as ThinkGeek (US), DragonBox (EU) for $150 / 125 Euros.

GCW_ZeroToday, I’m writing about this console, not because of amazing specs, nor price, but because it could be the first  device with an embedded SoC that retails with an open source GPU driver. In September of this year, GCW Zero received a firmware update with Etnaviv GPU driver for Vivante GC860 adding support for 3D games via OpenGL ES support. The video below shows Quake 3 Arena running on the game console with the Etnaviv drivers.

Lots of OpenGL ES1 and 2 features are supported as you can see from the release notes for the latest firmware (October), but some may still needs to be implemented including loops in shaders, GLSL (OpenGL Shading Language) “texture” bias parameter and “textureLod”, and a few more more. Beside Quake 3D arena, D2X (Descent 2 rebirth), Dark Places, and Hurrican are some of the few 3D games that have successfully been tested on the platform.

That means any platform based on Vivante GC600, GC800, GC860, GC880, and GC1000 should be able to support OpenGL ES via the open source Etnaviv drivers in Linux or Android. Vivante GC2000, as used in Freescale i.MX6 Quad, is not yet supported mainly because multiple pixel pipes support is missing, although progress has been made.

Etnaviv appears to be mainly a one person effort by Wladimir J. van der Laan, and despite this, progress has been very fast for the last year or so. The hard parts have been done, i.e. reverse-engineering and 3D drivers, but there’s still more work to be done, such as integrating the Mesa stuff into DRI/DRM, upstreaming, and X11 2D driver.

If you are interested in contributing to the project, trying it out, or simply watch the progress of the project, you can do so on Wladimir’s blog, or on #etnaviv IRC channel on freenode. For source code and documentation, visit the project’s github repo.

Most Embedded GPUs Do NOT Support Hardware Video Decoding Acceleration. The VPU Does.

December 10th, 2013 8 comments

Many people seem to get confused with the actual function of GPUs used in embedded (ARM / MIPS) SoC, and I can often read comments similar to “with lima drivers we should get video decoding in XBMc soon”,  and I’ve just received any email reading “My main task is to build a full hd media player based on ffmpeg with hardware decoding acceleration for linux. Is it possible with mali400mp4?”. So I’ve decoded to write a short post about it to make things a bit more clear. Contrary to GPUs in the PC world, embedded GPUs only take care of 3D, and sometimes 2D graphics, and leave video encoding and/or decoding to another block called Video Processing Unit (VPU). There’s at least one exception with Broadcom Videocore IV GPU as found in the processor used in the Raspberry Pi that apparently takes care of 2D & 3D graphics as well as hardware video decoding & encoding, but this is not the norm.

Let’s take an example with Freescale i.MX6 Quad SoC.

Freescale i.MX6 Quad Block Diagram

Freescale i.MX6 Quad Block Diagram

In the multimedia section in the middle of the block diagram above you’ll see hardware graphics accelerators, and video codecs:

  • 3D via Vivante GC2000 GPU
  • 2D via Vivante GC320 GPU
  • Vector Graphics (OpenVG 1.1) via Vivante GC355 GPU
  • 1080p30 Enc/Dec via a Video Processing Unit (VPU)

Freescale SoC is using one GPU for 3D, two separate GPUs for 2D composition and vector graphics, and a VPU to handle video by hardware. That means Vivante GC2000 has nothing to do with video hardware decoding for example.

Let’s give another short example. AllWinner A20 features a Mali-400 (MP2) GPU with 3D graphics and OpenVG support, a separate 2D engine, and CedarX VPU for hardware video processing.  So please, don’t come to ask me if it is possible to use Mali-400 hardware video decoder in Linux. 🙂

Where it gets a little confusing, is that some of the GPU capabilities can be used to decode video codecs that are not supported by the Video Processing Unit. For example, the Raspberry Pi guys used some features of the VideoCore IV GPU, but not the hardware codecs, to implemented VP6, VP8, MJPEG decoding in standard resolution. More recent GPUs comes with Renderscript and OpenCL support, which allows 1080p HEVC (H.265) video decoding using the CPU and GPU. That’s called GPU compute, and although it works, it won’t be as power efficient as video hardware decoding in the VPU.

Vivante GC4000 is The Best Mobile GPU… When It Comes to Accuracy

May 7th, 2013 5 comments

Most of the time, mobile GPU comparisons involve benchmarks such as Antutu, Nenamark 2, etc…, or people may consider which games will be able to run smoothly with a particular device, but we seldom compare image quality, for the simple reason it’s usually more difficult to achieve.

YOUi Labs has just done that, however, by running the shader code below on several hardware platforms, mainly Android tablets, with the most common mobile GPUs, and used the results obtained with a  Desktop PC GPU, Nvidia Geforce GT 630M, has a reference.

Here are the results:

Mobile GPU FPU Accuracy

The worst GPUs are Mali-400 MP4 in Exynos 4412 and Geforce ULP in Tegra 3, which can respectively only show 5 and 8 lines before degradation, and the top two GPUs are Qualcomm Adreno 225 in MSM8660A, and Vivante GC4000 in HiSilicon K3V2 processor. Imagination Technologies SGX544 and ARM Mali-T604 also provide decent results, but just not as good as the two aforementioned.

YOUi Labs has also released a free Android app called Shader Effect Test that allows you to evaluate your GPU floating-point accuracy by running visual effects tests on your own device, but for some reasons it does not include the code above.

The company explains that if you plan to run this application on your hardware, this demo will push your GPU and/or drivers to the limits so it may crash, or some shaders may appear off-center or incorrectly positioned. They explain this is normal, at least for some hardware.

I’ve tried it on AMLogic AML8726-MX hardware (Mali-400 MP2), and some of the tests do not look pretty at all, but I can’t draw any conclusion as I haven’t tried with other SoCs.

Shader Effects on Mali-400MP2 (Click to Enlarge)

Shader Effects on Mali-400MP2 (Click to Enlarge)

Shader Effects on Mali-400MP2 (Click to Enlarge)

Shader Effects on Mali-400MP2 (Click to Enlarge)

I’m pretty sure it’s possible to draw smooth edges and properly rounded 3D balls with Mali-400 MP2, but the nature of the tests requires more precision than this GPU can handle.

Via Imagination Technologies

Open ARM GPU Drivers FOSDEM 2013 Video and Call to ARM Management

February 14th, 2013 4 comments

As I previously wrote, FOSDEM organizers are slowly uploading FOSDEM 2013 videos. One of the most interesting talk “Open ARM GPU Drivers” is now available. I’ve also uploaded it to YouTube (embedded below) to give it more exposure. Luc Verhaegen has also written a recent blog post entitled “Hey ARM!” where he announces the release of the modified source for Quake 3 Arena demo, and asks ARM to join them in making an open source driver.

Open ARM GPU Drivers @ FOSDEM2013

This session covers the following key points:

  • Problem – Binary drivers are mainly designed to run in Android, and it’s very difficult to have proper GPU drivers for Linux, and companies are not interested to release open source drivers or even just documentation, as they are not convinced it will benefit them in any way.
  • Legal – This is actually the main issue, as open sourcing existing driver is a legal nightmare, and may cost a lot of money.
  • ARM Mali Overview – Mali-200/400, 450 & T6xx
  • Lima Project Status – No big secrets left in command-stream, compiler is tough due to Mali architecture, and actual driver work will start after FOSDEM. Full GNU/linux systems available.
  • Qualcomm Adreno Overview – Adreno 2xx/3xx
  • Freedreno Project Status – WIP driver. Command-stream and Shader architecture is mostly known. WIP xf86 (exa), mesa (gallium) drivers available. No proper GNU/linux available (The developer is currently using Android)
  • Nvidia Geforce ULP (Tegra) Overview
  • Tegra-re Project Status – Early research, early shader disassembler and early command stream capture. Limited availability of GNU/linux systems (AC-100, Trimslice).
  • Vivante GCxxxx Overview
  • Etnaviv project Status – Early research: Slowly prying apart command stream, full command stream capture and replay, and shader disassembler and assembler.
  • Broadcom Videocore Overview
  • The Raspberry Pi is a closed platform – “Open source” driver release by the Raspberry Pi foundation is just a shim (message-passing interface between ARM and the GPU), and the GPU itself runs a RTOS that handles the real processing.
  • Videocore Project Status – Research stage: documentation, assembler/disassembler., compiler work started,
    scalar processor fully reverse engineered, and some some “Hello World” code is available for booting the Raspberry Pi. 9 people are currently working on this project.
  • Imagination PowerVR SGX Overview – PowerVR SGX (5xx), and Rogue (6xx) in the future
  • Open Source Project Status (from the slides):PowerVR SGX Open Source Driver
  • Lima driver demos on Mele A1000 – Cube demos and Quake 3 Arena timedemo.


You can also download the presentation slides for his sessions

Quake 3 Arena Time Demo Source Code for Lima and Limare Driver

As I just mentioned, part of the session was a demo of Quake 3 Arena running on top of Lima drivers in Mele A1000 set-top box running Linux. Luc has now made the source code available on github, and you can get it as follows:

You can them compile it natively in any AllWinner A10 device:

You’ll also need to get a full Quake 3 Arena version first as the binary data files (paks files) must be copied to   ~/ioquake3/baseq3 (NB: Those files can not be redistributed, as they belong to ID Software), and edit demofour.cfg as follows:

You can now run the game demo with (I haven’t tried, so I’m not sure of the quake binary name):

The full games is not playable yet, and Luc welcomes fixes for input support, sound, or even for the missing GLES2 shaders.

Call to ARM Management to Work with Open Source Developers

Luc Verhaegen claims “Absolutely nothing stops us now from delivering an open source driver that broadly matches the binary driver in performance! And this is exactly what we will be doing next!”, and calls upon ARM to join them:

We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.

It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.

So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.

Open source developers are not the only ones to ask for this, if you’ve ever wanted to use Linux with proper 2D/3D GPU drivers on ARM, you are in the same boat, and even Linaro engineers complain about this (Linaro is an organization working on open source software for ARM SoCs, and ARM is obviously a core member), because those need to be updated for each kernel version, and it’s a nightmare as they have to go through the GPU company’s FAE which talks to the engineer and back. This wastes a lot of time (and money), as a task that could be done within a few hours/days with open source drivers, may instead take days or weeks because of binary blobs. An example is Linux Mali-400 support on Hardkernel ODROID-X/U2, they announced their intention to provide hardware GPU acceleration months ago, last month they released an Ubuntu image which can support GPU drivers (but not the driver), and they could only release the drivers yesterday (I’ll have to try that). The point is that it could have taken a much shorter time with open source drivers.

I understand there must be complicated legal issues, but there must certainly be a way to provide open source drivers, as it would just benefit everyone (from end users to engineers to SoC companies). Since Lima developers have now proven they can match the performance binary drivers for their “research” driver, and seem to be committed to deliver a proper open source driver for Mali-400, that should be a sufficient reason for ARM to cooperate with open source developers, even if it is only by releasing the GPU documentation.