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.
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.
"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:
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.
"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.
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.
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.
Why do you think so?
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.
D
Deleted member 13524
Guest
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.
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.
What do you mean?
D
Deleted member 13524
Guest
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.
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
Could you give me something more specific than that please? That's very open ended, and even a single patent can be pretty hard to read, never mind all of them..
arjan de lumens
Veteran
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.
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.
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.
Similar threads
