PowerVR Rogue Architecture

They're still drawing the pixels, aren't they? Just not writing them to external memory?
Or do they always do Z first?
It does as much "Z-first" as feasibly possible, but if a hypothetical app were written such that it, say, sent transparent objects first and then the opaque, there's not much that can be done.
 
It's probably just me, but I can smell a 20-30% performance increase (depending on case) with OGL_ES3.1 drivers.
 
IMG announced the 16 cluster, 512 ALU, GT7900

"At a target frequency of 800 MHz for 16nm FinFET+, PowerVR GT7900 delivers 800 GFLOPS in FP32 mode and 1.6 TFLOPS in FP16 mode."

Appears they already have design wins for launch in 2016:-
"I’m really excited to see how our partners will use these new high-performance parts in designs coming later next year."

http://blog.imgtec.com/powervr/powervr-gt7900-redefining-performance-efficiency

IMG have been increasingly referring to "game consoles" in their recent press releases, and this one pretty much tags this GPU for that market.

I expect the design wins to be of a fruity nature. One might also ask who would be shipping 16nm Finfet designs at that time, as a good clue to potential licencees.
 
Last edited:
They're still drawing the pixels, aren't they? Just not writing them to external memory?
Or do they always do Z first?
As Simon said, a TBDR won't shade the fragments that fail the z test. It's performance is triangle submission order independent as long as all the opaque geometry is submitted first. That will probably change in the future though.
 
"I’m really excited to see how our partners will use these new high-performance parts in designs coming later next year."
One might also ask who would be shipping 16nm Finfet designs at that time, as a good clue to potential licencees.
"later next year" is an awfully vague time-frame.
If it had been later this year, well, then the number of candidates would have made a short list.
 
Yep, really slow compared with the A72 from ARM. IMG will have to adopt this fast execution otherwise the next-gen Mali-GPUs will come to market far earlier than the PowerVR GPUs. I at least expect that the fast execution we see for the A72 is not an exception but the norm for the future.
 
Yep, really slow compared with the A72 from ARM. IMG will have to adopt this fast execution otherwise the next-gen Mali-GPUs will come to market far earlier than the PowerVR GPUs. I at least expect that the fast execution we see for the A72 is not an exception but the norm for the future.
Umm, IMG have announced an entire range of new GPU processors, series7, non of which have made it to announced Socs. I would expect some to appear this year, in Apple products at least. The GT9700 is the very highest end of the 7series, so not surprising that it'll be later in the cycle.
 
Exactly would expect the GT74xx - GT78xx inside fruity products this year, if you have paid attention to what IMG have been saying.
 
As Simon said, a TBDR won't shade the fragments that fail the z test. It's performance is triangle submission order independent as long as all the opaque geometry is submitted first.

Just a clarification for something you probably already know, since the wording might be confusing to others. Nothing today will shade fragments that fail the Z test. What TBDR will do is not allow multiple opaque fragments to pass the Z test.

Conceptually it's kind of like doing a Z pre-pass, but more efficient and with facilities to repeat pixels where discards occur.

That will probably change in the future though.

Why do you think so?
 
Exactly would expect the GT74xx - GT78xx inside fruity products this year, if you have paid attention to what IMG have been saying.

Apple is different :) Apple invests a lot of money to be first.

A72 is something new, at least for me. Both big SoC producers, Qualcomm and Mediatek already announced products with the A72 and if this report is correct then the prototypes from Mediatek are already running:

http://www.gizmochina.com/2015/02/28/new-mediatek-processor-spotted-gfxbench/

The big difference for me is, that the new cores are used very fast from the normal SoC developers. They introduce the new A72-SoC's (at least it seems so) as fast as only AMD and Intel until now. IMHO a big difference maybe even a paradigm shift.
 
The linked page says the CPU is A57 in that product, not A72.
 
That GFXBench screenshot from February 28th mentions a dev board with a MT8173, and yesterday Mediatek announced the MT8173 as a 2*A72+2*A53 SoC.

Perhaps whoever is testing the MT8173 was using code from the A57 chipsets, like Samsung used Cortex A15/A7 code for their A57/A53 Exynos 5433.
 
According to reviewers and modders, the cpu code in the initial kernel for Galaxy Note 4 used almost a copy/paste of the kernel for Galaxy Alpha (5430 with Cortex A15), and only ARMv7 is supported.
The general public only found out the Exynos 5433 was using the new 64-bit cores when Samsung launched kernel updates.


The same thing could be happening in Mediatek's labs, where they're testing the A72 using A57 code.
 
According to reviewers and modders, the cpu code in the initial kernel for Galaxy Note 4 used almost a copy/paste of the kernel for Galaxy Alpha (5430 with Cortex A15), and only ARMv7 is supported.
The general public only found out the Exynos 5433 was using the new 64-bit cores when Samsung launched kernel updates.


The same thing could be happening in Mediatek's labs, where they're testing the A72 using A57 code.
Oh I thought that by "code" you meant the CPU id or some other hardware register :)
 
Just a clarification for something you probably already know, since the wording might be confusing to others. Nothing today will shade fragments that fail the Z test. What TBDR will do is not allow multiple opaque fragments to pass the Z test.

Conceptually it's kind of like doing a Z pre-pass, but more efficient and with facilities to repeat pixels where discards occur.
Good point.
Why do you think so?
Look at their patents.
 
I don't know what rpg.314 is referring to either, but I can think of at least one thing that can break both the overdraw removal and the submission order independence of TBDRs quite badly: Virtual Texturing.

Especially if the form introduced by AMD (http://www.anandtech.com/show/5261/amd-radeon-hd-7970-review/6) and made part of DX11.2 becomes the preferred form: this is a form of virtual texturing where, at the shader level, the texturing operation returns as part of its result whether it hit an unmapped part of the texture, and where the shader itself is supposed to record any such hits in a data structure on the side. Since such a shader necessarily has the ability to write to memory other than just the framebuffer, it is required to run even if it is opaquely-overdrawn later in the same frame, and as such, a TBDR cannot just skip it like it can with more traditional content.
 
I don't know what rpg.314 is referring to either, but I can think of at least one thing that can break both the overdraw removal and the submission order independence of TBDRs quite badly: Virtual Texturing.

Especially if the form introduced by AMD (http://www.anandtech.com/show/5261/amd-radeon-hd-7970-review/6) and made part of DX11.2 becomes the preferred form: this is a form of virtual texturing where, at the shader level, the texturing operation returns as part of its result whether it hit an unmapped part of the texture, and where the shader itself is supposed to record any such hits in a data structure on the side.
So this is so you can pre-fill the texture memory with textures that aren't visible? Seems this should be extended so that off-screen pixels, nay, all geometry, even that behind the view frustum, should be sampled too.
 
Back
Top