PowerVR Rogue GPUs set to deliver next-gen graphics and compute with new OpenGL ES Next API

2014 is gearing up to be an exciting year for CES. In conjunction with the launch of our PowerVR Series6XT and Series6XE GPUs, the Khronos Group has announced OpenGL® ES Next, a next-generation API standard which introduces a number of new features for mobile and embedded devices.

OpenGL ES Next is compatible with all PowerVR Rogue GPUs

As with any new API standard, there is always a risk of obsoleting GPU technology. However, the good news for developers targeting PowerVR-based hardware is that all our PowerVR Rogue GPUs are designed to meet the specifications of the OpenGL ES Next API. This means that any device with a PowerVR Series6, Series6XT or Series6XE graphics core will be able to support OpenGL ES Next, once conformance is achieved.

PowerVR Rogue graphics IP - OpenGL ES NextAll PowerVR Rogue GPUs are designed to support OpenGL ES Next

Imagination Technologies is a founder member of the Khronos Group and continues to be heavily involved in the creation and adoption of new graphics and compute standards, including the latest OpenGL ES Next standard. Our PowerVR Rogue GPU roadmap provides a broad and unique range of advanced graphics and GPU compute solutions from entry level to high end cores that have been designed to efficiently support the latest and greatest API standards, ensuring that both silicon vendors and consumers access the best GPU architecture available on the market.

We continue to believe the future of graphics is driven by the mobile market. The OpenGL ES Next API from the Khronos Group brings mobile platforms another step closer to performance parity with traditionally more capable desktops and consoles. OpenGL ES Next provides the compute and geometry functionality that will surely get developers excited about writing code for mobile.

What is OpenGL ES Next?

Until now, the evolution of mobile GPUs had been heavily driven by two separate APIs: OpenGL ES for graphics and OpenCL™ for compute. But the market always demands more flexible solutions and higher performance efficiency; to address this desire for faster and more feature-rich devices, the OpenGL ES Working Group devised OpenGL ES Next, a new API that combines the full OpenGL ES 3.0* standard with select extensions from OpenCL and OpenGL.

OpenGL-ES_1500

In terms of functionality, OpenGL ES Next introduces some notable features designed to meet new levels of graphics and compute performance demanded in a broad range of next generation embedded devices, including mobile phones, tablets, Ultra HD TVs, automotive and many others.

All PowerVR Series6, Series6XE and Series6XT graphics processors have been designed with features that conform to the main features of the new OpenGL ES Next API, including:

  • Backward compatibility with OpenGL ES 2.0 and 3.0
  • Compute shaders, with atomics and image load/store capability
  • Separate shader objects
  • Indirect draw commands
  • Enhanced texturing functionality including texture gather, multisample textures and stencil textures
  • Enhanced shading language functionality

See OpenGL ES 3.0 and OpenCL demos running on PowerVR-based hardware

If you are at CES and want to get a glimpse of our latest OpenGL ES 3.0 and OpenCL demos, come visit our booth in South Hall 4 Upper Level (enter at Suite S215) at the LVCC.

For those who aren’t able to attend CES 2014, we are preparing an article reviewing some of our most exciting demos from the event so stay tuned to our blog. Make sure you follow us on Twitter (@ImaginationPR, @PowerVRInsider and @GPUCompute) to stay up to date with the latest news and announcements from Imagination and our ecosystem partners.

 

Editor’s Note

* All PowerVR Rogue cores are based on published Khronos specifications, and are expected to pass the Khronos Conformance Testing Process. Previous generation PowerVR cores have already achieved conformance. Current conformance status can be found at www.khronos.org/conformance.

OpenCL and the OpenCL logo are trademarks of Apple Inc. used by permission by Khronos.

OpenGL is a registered trademark and the OpenGL ES logo is a trademark of Silicon Graphics Inc. used by permission by Khronos.

, , , , , , , , , , ,

  • Sean Lumly

    This is Awesome! When I learned of GLES Next, I was speculating that it would see fast hardware support from imgtec, and out of the gate, Imgtec’s latest arch has it!

    Android SoCs need to be outfitted with your Series 6XT GPUs! (I’m also really interested in your Meta cores, as they seem to perform outstandingly at low mm2)

    I am also supremely excited (and relieved to be honest) that compute shaders will be making it into the API. As an Android dev that is forced to use renderscript, this seems like a refreshing alternative for graphic related tasks. It presumably guarantees execution on the GPU, will no doubt be extremely efficient with graphic related maths, and should be able to work on buffers that are associated with the pipeline. I wouldn’t be surprised to see a wrapper library surface that used CS as an simple RS alternative.

    It seems like the expanded feature set is very competent, and should help continue to normalise the API with the desktop.

    What are your thoughts on the omission of Tessellation and Geometry Shaders for mobile?

  • http://withimagination.imgtec.com/index.php/author/alexvoica Alexandru Voica

    Thanks, we’ve always made sure that our architecture is able to support the latest and greatest APIs (and even exposed some next-gen features on current gen hardware i.e. OpenGL ES 3.0 functionality through OpenGL ES 2.0 extensions for Series5XT).

    OpenGL ES Next is shaping up to be an interesting compute alternative to Renderscript for Android. I can’t comment on how Google will implement it though; however they choose to do it, we will be able to support it not just on Series6XT/6XE, but also on Series6 – which I think is very exciting.

    That last statement about how the API won’t include tessellation/geometry shaders is actually very interesting. OpenGL ES has always been (and continues to be) an API created first and foremost for mobile and embedded devices.

    Tessellation in particular requires additional area and can increase power consumption if not done right; supporting it just for the sake of feature claiming can have dire implications for a mobile SoC.

    As I was saying in the Series6XT thread, our roadmap is driven by consumer, ecosystem and customer feedback; and right now, tessellation is not a must-have feature. That doesn’t mean we can’t support it. In fact, the Rogue architecture can scale to DirectX 11. It’s all about right timing and delivering an optimal implementation.

    Regards,
    Alex.

  • Sean Lumly

    Thanks Alex,

    I suspected that to be the case regarding tessallation, and it seems like something that would be infrequently used in the mobile space at the moment — though consume valuable die area.

    And I certainly hope compute is a mandatory aspect of the spec and not an optional extension. It would be a shame if Android was forced to forgo this insanely powerful feature (I’m a big fan of general purpose compute). I am confident that it wouldn’t be omitted, though.

    Anyway, thanks again! I’m looking forward to seeing videos of the GLES30 demos!

  • Pingback: Imagination Technologies anuncia sus nuevos GPUs PowerVR Series6XT/XE “Rogue” | SINETEC

  • Marius Cirsta

    So series 6 and 6xt can in theory also support OpenGL 3.2 I presume ( given that they do support DirectX 10 ) , right ?
    No we come back to the discussion on cnx where it was really nice of you to contribute. Say I have an Android TV box with an Allwinner A80 and want to run regular Linux on it, Ubuntu Desktop. The Sunxi team does a great job and I get the kernel but then I want to have hardware 3D acceleration and I’m stuck. Will I be able to get something working without using libhybris or some other hacks ?
    If this box had a Qualcomm Adreno GPU there is a working driver, Freedreno as you know that can do what I want. Sure it’s performance is probably not on par with the binary from Qualcomm but it’s good enough.
    ARM is getting more flexible with the device tree and everything else and my personal feeling is that GPU drivers are holding things back, including those from Imagination. I don’t expect things to change over night I just want to see something more than nice PR words.
    On the x86 front even nVidia is sometimes helping the Nouveau developers.

  • http://withimagination.imgtec.com/index.php/author/alexvoica Alexandru Voica

    Hi,

    It is true that PowerVR Rogue supports OpenGL 3.x. The
    problem with your reasoning is you are confusing us with a chipset
    company. We cannot be compared with NVIDIA or Qualcomm in this respect because we sell IP, not chips.

    If we had sold SoCs, then yes, we would
    have had more flexibility with drivers. But we have tens of customers,
    each with a different microarchitecture, each with different CPU/GPU
    configurations, to which you add things like VPUs (hardware video encoders/decoders), ISPs, display controllers, memory controllers, sensor hubs and many other elements which need to communicate between each other.

    Therefore, it is almost impossible for us to release “generic” drivers. This is how things usually work:

    a) customer licenses PowerVR GPU, has access to our DDK (Driver Development Kit)
    b) customer starts integrating said PowerVR GPU into an SoC that can have very specific microarchitectural features; e.g. CPU ISA (x86, ARM v7/v8, MIPS32/64, etc.)
    c) customer works with partner OEMs/ODMs to target specific OS (Android, iOS, Linux, webOS, Windows RT, Windows 8, etc.)
    d) SoC is sold to OEMs/ODMs that manufacture end devices
    e) end device is released

    You can see how it would be very complicated for us to step in and assume the role of a customer or OEM, mainly because some elements of their work have nothing to do with us. Releasing their drivers without their approval would further complicate things even further and jeopardize our working relationship.

    I understand the needs of the open source community but you have to address your requests to the right people. If you want a certain OS to be supported, talk to the silicon vendor or the OEM/ODM and see what can be done. We can help by sending them your feedback (and obviously supply the DDK for that OS).

    Best regards,
    Alex.

  • Marius Cirsta

    Alex I understand you position and that of Imagination. What you’re saying does make sense but only until a certain point.
    Yes the companies you sell to take the DDK and build their own stuff based on that but I seriously doubt it that they make significant alterations to the code itself. I don’t think Allwinner can implement OpenGL 3.x for instance. They probably make slight modifications related to the memory locations and so on.
    I’m not saying Imagination should make it so everything is open source and works, I’m just saying you could do more. Some Intel Atoms for instance contain PowerVR SGX 545. There’s no open source support for that whatsoever and given Intel’s commitment to open source I’m not sure it’s their fault.
    Imagination could release some documentation at least or even some parts, pieces of code. There’s still gaps that would need to be filled but maybe someone would step in and make it work. The PowerVR 54x generation is old now, surely there are no big secrets in the documentation. If AMD can release docs for their latest GPUs ….
    I will compare PowerVR to Mali for which we’ll soon see the Lima driver in a working state. ARM doesn’t do SOCs either but someone managed to get a generic driver going and I think it will work. Unfortunately it’s true that LIMA received no support whatsoever from ARM.
    In conclusion … not saying Imagination should bring piece to the world but it could do more than it’s doing right now for this, which is IMO nothing. The fact that you’re at least trying to explain the problem is a start.

  • http://withimagination.imgtec.com/index.php/author/alexvoica Alexandru Voica

    Hi,

    Let me try and give a clearer view of how drivers for mobile SoCs work with one example.

    We’ve recently partnered with Hardkernel and provided full access to the PowerVR DDK for their ODROID-XU boards. Thanks to this collaboration, the ODROID-XU board supports the full OpenGL ES 2.0 and OpenCL 1.1 EP APIs on Android for the Samsung Exynos 5410 SoC.

    In theory Hardkernel could have supported Linux too since we granted full access to our OpenGL DDK, but Exynos 5410 was designed as an Android part and certain drivers, like the display driver, were not written with Linux support in mind.

    It’s common in mobile to just target one OS. The
    Atom SoCs you mention are in a similar situation; Intel has said that it designed those platforms for Windows; it might well be that they’d be good on other OS but they weren’t designed or implemented for those OS and there’s nothing we, as the IP supplier, can do about it.

    Regards,
    Alex.

  • tramper

    “the OpenGL ES Working Group devised OpenGL ES Next, a new API that combines the full OpenGL ES 3.0* standard with select extensions from OpenCL and OpenGL. “, It is really strange that OpenGL ES will borrow extention from OpenCL. I wonder what’s the probable ones?

  • Pingback: PowerVR GX6650: Redefining Performance In Mobile With 192 Cores | Smartphone & Tablet Design