PowerVR Insider FAQ

Memembership of the PowerVR Insider developer programme is free and open to all developers writing applications on PowerVR-enabled platforms. If you haven't already registered as a PowerVR Insider, please do so on this website. Once you've registered you are eligible for technical and co-marketing support and will receive the PowerVR Insider newsletter. You also will have access to our developer forums where you can post questions and browse and search for technical information from existing posts.

If you are a registered developer we encourage you to get in touch with us for feedback on the SDKs and utilities we provide and for technical assistance in the development cycle of your applications.

The e-mail address for developer support is devtech@imgtec.com.

OpenGL ES is a royalty-free, cross-platform API for 2D and 3D graphics application development on embedded systems. This includes handheld devices, appliances and vehicles. It is a well-defined subset of desktop OpenGL, creating a flexible and powerful low-level interface between software and graphics acceleration.

OpenGL ES 1.X is an API that works with fixed function hardware. OpenGL ES 2.X provides an interface for fully programmable, shader-based graphics work.

For more information about OpenGL ES please go to http://www.khronos.org/opengles

If you own embedded hardware or a development platform supported by one of the PowerVR SDKs you can download the corresponding SDK package and get started with the instructions provided (the list of supported hardware is mentioned next to the SDK name).

Note that more PowerVR SDKs may be available through our customers' web pages.

Regardless of whether hardware is available it is generally a good idea to start developing new applications using one of the PC Emulation SDKs as this allows for a much more rapid build time as well as convenient debugging facilities. Once an application runs as it should in the PVRVFrame emulation environment provided in this SDK, it can then be easily ported to the target platform by changing which version of the PVRshell is used (see "What is the "PVRShell" environment?"). You can then proceed to perform optimizations in your application for your target platform.

Our SDK contains a comprehensive training course which will guide you step-by-step through the API, from the most simple initialisation example, getting your first triangle on the screen, all the way to advanced feature programming.

To begin developing your own OpenGL ES applications it is recommended to start with one of these simpler SDK projects and modify it as required.

Imagination Technologies don't distribute driver files for PowerVR platforms as these should already be present on shipping devices or be available from the manufacturer of a development board. Please contact your hardware supplier to obtain these files if you do not have them, but bear in mind that sometimes they are hidden from the user in the device's file system.

Some of our SDKs contain stub libraries for cross-compilation within the SDK packages so that projects should build from the package (with a few exceptions, such as the iPhone and Android SDKs). These are not functional driver files.

We release new versions of the SDK twice a year - in the spring and late summer. SDKs for new devices and APIs are released as the platforms and support for development becomes available from device manufacturers. This means that the release date for some devices/APIs (e.g. OpenCL) are out of our control so we can't state a specific date for them.

The SDK source code may be used in software that is distributed in binary form without restriction. If source code from the SDK is to be distributed then the copyright notice from the top of the source file must be left intact.

If you do use code from the SDK then we would appreciate it if you would add a reference to Imagination in the materials you distribute and if you get in contact with us we can provide you with logos and web adresses, in this regard. Through the Insider program there may be other co-marketing initiatives that may benefit your developments.

Please email devtech@imgtec.com if you would like to bundle any of the PowerVR utilities and libraries included in the SDK with your software.

PVRShell is the abstraction layer used by most of the demo and training course projects in the SDKs. All source code is provided and commented so that customisation and extension of functionality is easiy available to developers.

This system allows an application to run on different combinations of OSs and platforms simply by changing the PVRShell files for the specific combination of OS and API and leave the developer's application code untouched. Programmers can develop using the PC Emulation SDK and then run their application on the desired platforms by following this process.

Applications that use PVRShell include the following files:
PVRShell.h/cpp: Generic source and header code that handles OS-independent initialization.

PVRShellAPI.h/cpp: API-specific shell initialization code, e.g. Shell\API\KEGL\PVRShellAPI.cpp performs initialization for the Khronos EGL API, used for both OpenGL ES and OpenVG.

PVRShellOS.h/cpp: OS-specific shell initialization code, e.g. Shell\OS\Windows\PVRShellOS.cpp performs initialization for Windows (used for PC Emulation) and WinCE/PocketPC OSs.

OGLES********.cpp: Source code containing the actual OpenGL ES rendering functions for the demo. Other demo-specific files can be added as required from here without requiring platform specific coding.

FileWrap is a utility that 'wraps' external data required for an application so that it can be included within an executable. Data is statically linked into the application and may be accessed at run time using the PVRTResourceFile tools code or from your application. This is useful for platforms without a file system and for application distribution and deployment because it keeps all required data in one place: the application executable.

Information and guidelines for FileWrap are included in the PowerVR Insider SDK User Guide included in the SDKs.

The 'Application Development Recommendations' document in the SDK's Documentation section provides advice and performance tips to optimize OpenGL ES applications running on PowerVR-enabled platforms.

It can also be found here: here

It is strongly recomended that all developers become familiar with this document when developing for PowerVR hardware.

Compressed textures allow for reduced memory footprint and reduced bandwidth use both in terms of total data transfer for a scene and also in cache efficiency. Less bandwidth use means increased performance and better power consumption. Both memory storage and bandwidth are finite commodities that can affect the performance and qualtiy of an application. Compressed textures that are smaller in data size than uncompressed data while being equvalent in image size can help with both of these costs.

In general, uncompressed image data is either 24bits per pixel(bpp) for RGB or 32bpp (RGBA) flatrate. A compressed format will be encoded at a lower data rate per pixel and so a reduction of data size can be achieved when compared to raw uncompressed textures. For example, the PVRTC format is available in 2bpp or 4bpp versions so that a reduction of 8 or 16 times is available.

For an RGBA texture of dimension 1024x1024 pixels, the uncompressed data size would be 1024 x 1024 x (32/8) = 4MB of texture data. With PVRTC 2bpp the same texture would occupy 1024 x 1024 x (2/8) = 256KB.

This is why PowerVR's demos use the PVRTC texture compression format that is supported by all our cores, where possible. Loading code is provided for PVRTC textures in the Tools folder of the PowerVR SDK and we also provide the PVRTexTool suite of tools that export texture data in this format. In addition, you can download PVRTexLib, a C++ library that can be used directly in custom tools chains.

For more information on PVRTexTool, PVRTexLib and PVRTC, please read the documents included in the PowerVR SDK package.

A requirement for graphics hardware to use textures natively is that the format of the texture must be random accessible for the hardware. PVRTC is this kind of format, PNG and JPG are not. Partly because of this, PNG and JPG can achieve greater file compression ratios than PVRTC for file storage, but as a runtime, deployment format, PVRTC is much smaller.

PNG and JPG compression don't work at flat bitrates and are more complicated to retrieve specific pixel values from; memory needs to be accessed from multiple locations in order to retrieve a single colour value and far more memory and processing would be required every single time a texture read occurs. This makes them unsuitable for use as a native texture format and this is why PNG and JPG textures must be decompressed before the graphics hardware can use them - so the data that the CPU passes to the graphics core is actually at 32bpp or 24bpp. This increases bandwidth use when compared to PVRTC, which requires no CPU decompression step for use (see "Why should I use compressed textures in my applications?").

PVRTC data has a flat compression rate so it is easy to calculate where in memory to retrieve the data required to derive a particular texel's value from and so only one access to memory required. There is dedicated circuitry in the graphics core which will decode the PVRTC values and give the texel value to your shader/texture combiner etc. so no extra shader cycles are used or other performance cost is incurred.

So, for offline storage (the size of your application on disk), PNG or JPG may be smaller than PVRTC which is definitely smaller than completely uncompressed texture data. For runtime memory footprint and performance, PVRTC is smaller and faster than PNG or JPG which both must be decompressed before use and so are just as large and slow as uncompressed textures. The only advantages PNG and JPG textures have are for storage and at initialisation for disk access, but at runtime time any advantage is lost entirely.

PVRTC is also in the correct data ordering for PowerVR hardware and doesn't need to be re-ordered when uploaded to GL so, combined with their smaller data size, PVRTC textures should also upload faster.

It is important to remember that most of the depth-sorting accuracy in a scene is a direct factor of the front clip plane value used when setting the projection matrix. The larger this value, the better the depth accuracy. Always push the front clip plane value as high as you can to improve depth accuracy and eliminate 'Z-fighting'.

One of the strongest features of the Tile Based Deferred Rendering (TBDR) architecture is its capability to significantly reduce overdraw in 3D and 2D rendering by performing efficient on-chip Hidden Surface Removal (HSR) on a per tile basis. The ability to do this is commonly referred to as "super" fill rate, because, unlike traditional IMR hardware, the only fragments that are processed are those that will affect the rendered frame.

To take advantage of this all 3D and 2D applications should use opaque objects (blending off, alpha test off, no discard in shader) as much as possible so that the HSR process can reduce fragment processing to a minimum. These should be rendered first, before any objects with transparency. Examples of this kind of sprites could be background graphics, terrain tiles, pop-up message windows.

For sprites with transparent areas, create polygons that are optimal for the visible area and exclude fragments that are completely transparent. If an application was to render a simple triangular shaped tree texture on a quad polygon, there would be large, empty areas that would need to be blended. A better approach in this situation would be to use a triangle that tightly fits the shape of the texture. By doing so, most of the empty area that would have to be blended when using a quad to render the tree sprite can be removed, which means there are fewer fragments to blend. Geometry used to tightly fit sprites in a given application should be kept as simple as possible while eliminating as many unwanted fragments as possible. Finding the balance between geometric complexity and the empty space that will be removed by using more complex geometry is a balance that is very application and platform specific. A tool such as the one described here: http://www.humus.name/index.php?page=Cool&ID=8 can be used to generate the geometry required.

For further optimisation, when rendering sprites with partially transparent areas, break each object down into an area that can be rendered as an opaque sprite and a second area of partially transparency that can be blended. By taking this approach, the number of fragments that need to be blended for each sprite can be significantly reduced, which allows the HSR process to provide a "super" fill rate. In order to maintain sprite ordering, use of the depth buffer will be required - each sprite will need a unique offset to avoid artefacts. Generating the areas for this technique can be done with a similar tool to that mentioned above, but this time looking for opaque pixels instead of completely transparent. As stated previously, the opaque objects should be drawn first followed by the blended objects as this will allow the blended objects to gain the most benefit possible from the hardware's HSR process.

Alpha test or fragment shader discard should only be used sparingly, as they don't benefit from the same advantages the TBDR architecture provides for opaque and blended fragment operations. In many cases, using blending with a zero alpha value can give just as good a visual result as alpha testing when rendering sprites.

By separately rendering opaque sprites, using tightly fitting polygons and breaking objects down into opaque and blended sections the performance of sprite rendering can be significantly improved on PowerVR platforms. Although these performance recommendations are aimed towards PowerVR TBDR graphics cores, they are also relevant for other graphics architectures. Please examine our performance documentation for more general recommendations and remember you should always use profiling and other means of analysis to determine whether your application will actually benefit from these techniques.

The PowerVR Insider SDK does not cover these topics and is solely targetted at the graphics aspect of programming PowerVR enabled platforms. Other resources should be consulted for platform-specific topics, usually available on the platform providers' websites.

However, example code is designed to be easily integrated with or extended for other functionality (see "What is the "PVRShell" environment?").

PVRVFrame has a known issue (BRN29913) with rendering from any other thread than the 'main' one. It will be fixed in a future release, but, in general, we recommend only using the 'main' thread for UI (Windows/X11) interaction and rendering. This fits well with DirectX usage and will also work around the issue with PVRVFrame.

When Print3D renders it requires various GL render states and doesn't necessarily set them back in order to avoid potentially redundant state changes. If you have a look at the APIRenderStates function that is part of the Print3D code you'll be able to see what it changes. This function should give you an idea of what might need to be reset after your call to Flush() to put things back the way they were.

This message is given when functions are used inside a conditional block which require gradient information.

Gradient information is based on a 2x2 pixel block processing: if any of the pixels in a 2x2 block are not taking the same branch as the other pixels then the resulting data, which is used for gradient calculation, might be undefined and thus the resulting gradient invalid.

Between iPhone OS 3.2 and iOS 4 there was something of a break in compatibility for XCode projects. We try to set the PowerVR SDK projects to use the latest Apple SDK at the time of release, but produce binaries that are backwards compatible with as early a version of iOS as possible. For the 2.7 release of our SDK Apple's SDK was at version 4.0.

The problem is that 4.0 is no longer the most up to date version and installing 4.1 doesn't also install earlier versions of the Apple SDK. This leaves XCode reporting a missing SDK when one of the PowerVR SDK projects is opened.

The solution that has been applied here is to ensure the Base SDK in the project settings (and the target settings if required) for each project (including the PVRTools project) by hand. It is also worth checking the "iOS Deployment Target" field.

Note that to deploy to iPad you will have to set the iOS Deployment Target to 3.2 or earlier (at least until Apple updates the OS for the iPad).

If this doesn't allow the examples to run and you still have errors, please post in our forum or email devtech@imgtec.com and we will try to help you with them. This issue should be resolved for our next SDK release.

The compiler we provide with the SDK (PVRUniSCo - the default compiler used by PVRUniSCoEditor) is supplied to give cycle count estimates. This compiler cannot be used to generate shader binaries for any devices using PowerVR hardware.

If you want to use binary shaders in your application, there are two options:

1. Use the OES_get_program_binary OGLES2 extension (http://www.khronos.org/registry/gles/extensions/OES/OES_get_program_binary.txt) to retrieve shaders that have been compiled online by the target device so they can be cached for later use. Doing so means an application can deploy shader source to all target PowerVR platforms, but can benefit from the lower initialisation overhead of using pre-compiled shaders once they've been compiled once and retrieved (which could be done on first launch of the application, or during installation etc). There is a Training Course in the SDK called BinaryShader? that demonstrates the use of this extension.
   
   
2. Compile shader binaries offline for the target device. The downside of this approach is that the compiled binaries are specific to a graphics core and driver revision, so they are not portable between all PowerVR platforms. The benefits of this approach are that the application does not have the overhead of compiling the shaders once online (as option 1) requires), and that shaders can be deployed to a platform without storing them in human readable text. In applications where the algorithms used in shaders are the main IP of a developer, managing binaries for different hardware and driver configurations is one way of protecting this IP. If you have any need for an offline shader compiler for your target platform, you can request one by emailing devtech@imgtec.com