Meet the all-new, lean and mean PowerVR 5.0 Framework

Share on linkedin
Share on twitter
Share on facebook
Share on reddit
Share on digg
Share on email

Last week we were thrilled to bring you the announcement of the release of the latest version of the PowerVR SDK Framework 5.0 and Tools Release 2 for 2017. This offers a number of exciting changes and promises to make life easier for any and all developers working with PowerVR GPUs. One of the major developments with this new release is happening in our SDK Framework and this post explains what’s new inside it.
Our previous 4.x Framework focused on providing a unified interface between OpenGL ES and Vulkan and serving as the basis for a cross-platform, cross API engine solution. This was successfully accomplished and that version will still be available for that purpose. However, we’ve been listening to your feedback and we could see that a major rework could improve things for developers even more.
First of all, we decided we should go back to basics. The Vulkan API is all about empowering the developer with more control, and our previous versions involved more hand-holding for the developer, which could potentially hinder Vulkan development.
Secondly, we felt that Vulkan on OpenGL ES just wasn’t right for an SDK, and was interfering with what the OpenGL ES SDK should have been – a learning aid for the OpenGL ES API.
So now we’ve put the power back in the hands of developers by stripping everything right back and leaving only useful utilities and wrappers. It does mean it’s not backwards compatible but you’ll be working with Vulkan rather than working with a framework based on Vulkan.
So – introducing the PowerVR SDK 5.0 Framework!

The PowerVR SDK 5.0 Framework structure

There are three parts to the new Framework – the common libraries, and libraries for Vulkan and OpenGL ES.

  • The common libraries are PVRShell, PVRCore and PVRAssets.
    • PVRCore is a dependency for many modules as it provides a lot of their supporting code. This includes common types, streams, logging, reference counting and so on.
    • PVRShell is now an independent platform abstraction. It is API agnostic and responsible for the OS specific windowing systems and inputs, including new-for-this-release support for Wayland.
    • PVRAssets contains code that deals with assets like textures and models as they will be loaded from a file.
  • The OpenGL ES libraries consist of PVRUtilsGles, which contains useful utility functions specific to OpenGL ES and the PVRCamera library.
  • The new Vulkan libraries consist of PVRVk, which is the main SDK offering for Vulkan and a thin wrapper for Vulkan. It also provides PVRUtilsVk, which contains useful helpers specific to Vulkan.

We’ll talk more about these libraries later, but first, we will take a look at the previous PowerVR SDK Framework version 4.x to provide some context to the changes we’ve made.

What’s changed in PowerVR Framework 5.0?

First, let’s look at how the previous version was structured:

As you can see, version 4.x of the Framework looks quite different to the new 5.0 version. There is no separation for OpenGL ES or Vulkan and the dependencies are more complex. Some libraries from 4.x have merged into others in 5.0, or have become a part of entirely new libraries in 5.0.

  • PVRShell was similar to the newer 5.0, but it was more tightly coupled to other modules.
  • PVRCore and PVRAssets are basically the same between 4.x and 5.0 externally, although a lot of improvements have been made internally.
  • PVREngineUtils provided common utility functions relying on PVRApi for the API abstraction. With 5.0, we now have finely tuned and optimised versions of the utilities separately for OpenGL ES and Vulkan.
  • PVRApi contained the API abstraction for both Vulkan and OpenGL ES. In 5.0, no such abstraction exists.
  • PVRNativeAPI provided runtime bindings and utilities to the underlying API. In 5.0 the bindings are simple header files, so no projects are necessary.
  • PVRCamera is OpenGL ES only and provided abstraction for the hardware camera on iOS and Android – the same as in 5.0.

Improved Vulkan support

So what has changed? The Framework is now more focused on Vulkan only and has become more streamlined. It provides a wealth of new functionality, and helpers and has generally, been simplified.
PVRVk is essentially a standalone (no dependencies at all) C++ Vulkan wrapper with added smart pointer support, namespaces and strongly typed enums. They are all there to make the Vulkan developer’s life much easier. It is the slimmed down and much-improved version of the Vulkan-only parts of the 4.x PVRApi.
It has a lower level of abstraction compared to 4.x and has moved closer to the level of abstraction in frameworks such as Vulkan HPP, but still retains its PowerVR Framework roots of keeping things as easy as possible. Most things are now the developer’s responsibility just as with the Vulkan API, whereas in 4.x this was managed by the Framework.
Speaking of which, PVRUtilsVk is a new module that provides some helpers to simplify common tasks without requiring the user to write boilerplate code. These include regular tasks such as:

  • creating instances
  • creating devices
  • managing queues
  • creating swapchains
  • managing surfaces in a single line
  • uploading textures

PVRUtilsVk depends on PVRVkPVRCore and PVRAssets.
We now also provide our own vulkan_IMG.h header file. This is a modified version of the Khronos vulkan.h file, but uses strongly typed enums. We have also removed the global namespace function prototypes to declutter the global namespace as far as possible.
PVRVk has its own namespace – pvrvk:: as opposed to pvr:: which covers the rest of the Framework.

Simplifying the Framework

The OpenGL ES framework has been moved back toward its educational roots, as having a cross-API solution was hindering its educational purpose. This means that PVRGles does not exist anymore, and instead, the OpenGL ES version of PVRUtils (PVRUtilsGles) now offers everything needed. It provides tools that work directly on top of OpenGL ES rather than through intermediate abstractions.
The functions are dynamically loaded and they are all in gl namespace. DynamicEGL.h and DynamicGles.h are single headers for loading function pointers for EGL and OpenGL ES.Developers will be learning and enjoying full control, as raw OpenGL ES code will need to be used, for example gl::BindTexture().

Module simplification summary

Some parts have been merged into other modules and/or removed altogether, and the dependency chains are now much shorter. PVRCore remains the same as before, but common interfaces specific to the API have been cleaned up, such as IGraphicsContext, IPlatformContext, etc.
PVRShell now only depends on PVRCore so it is an independent platform abstraction, and as mentioned, now supports Wayland.
PVRNativeAPI and EngineUtils are merged into PVRUtilsGles and PVRUtilsVk, each one working natively on the corresponding abstraction. Both depend on PVRCore and PVRAssets. PVRUtilsVk also, not surprisingly, depends on PVRVk. Both libraries provide helpers for initialisation e.g. creating EGL/EAGL contexts, shaders, Vulkan swapchains etc and also for tasks such as uploading textures and so on.
PVRCamera remains the same as before and supports OpenGL ES only.

In conclusion

As you can see, we have made a lot of very significant changes to the SDK Framework, which can only offer a fantastic improvement and alternative to our previous 4.x version. If you need more information, our Framework documentation has been updated. If you need any further help, don’t forget about our support forums where our Support Team are ready to answer your questions. We hope you enjoy using this release as much as we did making it!

Gerry Raptis

Gerry Raptis

Gerry Raptis is an engineer. He always has been one, despite jumping a few times between fields (civil engineering to software engineering then information systems to graphics, C# and Java to C++ and graphics APIs). His main passions are physical simulations, including chiefly – but not limited to – graphics and physics. He is part of the DevTech team at Imagination Technologies, working as the lead engineer for the PowerVR SDK.

Please leave a comment below

Comment policy: We love comments and appreciate the time that readers spend to share ideas and give feedback. However, all comments are manually moderated and those deemed to be spam or solely promotional will be deleted. We respect your privacy and will not publish your personal details.

Blog Contact

If you have any enquiries regarding any of our blog posts, please contact:

United Kingdom
Tel: +44 (0)1923 260 511

Search by Tag

Search by Author

Related blog articles

bseries imgic technology

Back in the high-performance game

My first encounter with the PowerVR GPU was helping the then VideoLogic launch boards for Matrox in Europe. Not long after I joined the company, working on the rebrand to Imagination Technologies and promoting both our own VideoLogic-branded boards and those of our partners using ST’s Kyro processors. There were tens of board partners but only for one brief moment did we have two partners in the desktop space: NEC and ST.

Read More »
pvrtune complete

What is PVRTune Complete?

PVR Tune Complete highlights exactly what the application is doing at the GPU level, helping to identify any bottlenecks in the compute stage, the renderer, and the tiler.

Read More »


Sign up to receive the latest news and product updates from Imagination straight to your inbox.