ARM Midgard Architecture

No love for those new second gen T6xx cores?

you mean this?
http://www.engadget.com/2012/08/06/arm-second-gen-mali-t600-gpus/

Well, it seems ARM had to improve their offerings to stay competitive.

I wonder a little bit about the "Adaptive Scalable Texture Compression"; especially about the bit-rates (3,56bit/pixel???) and which competitors will use this ASTC too? The market share of the Mali-GPUs was not so great last time I checked. So a additional Texture-compression standard from "someone" could be a waste of time, even if it is a Kronos-Standard.

Link: http://en.wikipedia.org/wiki/Adaptive_Scalable_Texture_Compression
 
And? You asked who else would be using ASTC. As long as it has some tangible benefits vs. other forms of texture compression, then more and more companies will adopt it, but it won't happen overnight.
 
I wonder a little bit about the "Adaptive Scalable Texture Compression"; especially about the bit-rates (3,56bit/pixel???) and which competitors will use this ASTC too? The market share of the Mali-GPUs was not so great last time I checked. So a additional Texture-compression standard from "someone" could be a waste of time, even if it is a Kronos-Standard.
Quite the contrary I think, this standard was agreed upon by several companies. I suspect you have to support it to not get obsolete rather sooner than later. Well maybe not really absolutely necessary for this generation of chips but it can't hurt. ETC support will be necessary, but it is nowhere near as flexible and not that useful for some textures.
The odd bitrates are just a result of supporting different block sizes for fixed sized chunks (which is an interesting concept), who cares if the resulting bitrate is odd?
 
One wonders is the Mali texture compression a response to issues around PVRTC increasingly becoming a standard, ie iOS and many android designs. If developers design for PVRTC first and foremost, then it leaves non IMG solutions at a disadvantage.

Does this new compression algorithm require an arm license for the hardware implementation ?
 
Could anyone explain the architectural differences between T-62x and T-65x?

I see both the T-628 and T-658 as "8-core" GPUs, so what's the difference? Clocks and power budget?
 
Could anyone explain the architectural differences between T-62x and T-65x?

I see both the T-628 and T-658 as "8-core" GPUs, so what's the difference? Clocks and power budget?
The T-628 has 2 ALUs per core while the T-658 has 4 ALUs per core so ARM considers the latter to be compute focused.
 
I'm not all that familiar with GPGPU, but how important are the vector integer ops? And does Midgar's ALU contain similar integer throughput at varying data sizes?
 
Hi;

after visiting the website from ARM I have to say that I'm rather impressed with ASTC now. ASTC seems to be the texture compression format to "rule them all". The only downside seems to be, that it will be implemented in two stages in all(?) GPUs, except Mali as "LDR" und "Full". I want to see ASTC-"Full" now. ;)

http://blogs.arm.com/multimedia/643...m-pushes-the-envelope-in-graphics-technology/

http://blogs.arm.com/multimedia/754...texture-compression-at-hpg-conference-part-1/

http://blogs.arm.com/multimedia/755...texture-compression-at-hpg-conference-part-2/

http://blogs.arm.com/multimedia/771-arms-astc-adopted-by-khronos-group/
 
Hi;

after visiting the website from ARM I have to say that I'm rather impressed with ASTC now. ASTC seems to be the texture compression format to "rule them all". The only downside seems to be, that it will be implemented in two stages in all(?) GPUs, except Mali as "LDR" und "Full". I want to see ASTC-"Full" now. ;)

http://blogs.arm.com/multimedia/643...m-pushes-the-envelope-in-graphics-technology/

http://blogs.arm.com/multimedia/754...texture-compression-at-hpg-conference-part-1/

http://blogs.arm.com/multimedia/755...texture-compression-at-hpg-conference-part-2/

http://blogs.arm.com/multimedia/771-arms-astc-adopted-by-khronos-group/

If ASTC is going to expand to other markets beyond small form factor, I'd say it's excellent news, since it's my understanding that developers would love to have a high quality low bpp tc format.
 
Hi;

after visiting the website from ARM I have to say that I'm rather impressed with ASTC now. ASTC seems to be the texture compression format to "rule them all". The only downside seems to be, that it will be implemented in two stages in all(?) GPUs, except Mali as "LDR" und "Full". I want to see ASTC-"Full" now. ;)

http://blogs.arm.com/multimedia/643...m-pushes-the-envelope-in-graphics-technology/

http://blogs.arm.com/multimedia/754...texture-compression-at-hpg-conference-part-1/

http://blogs.arm.com/multimedia/755...texture-compression-at-hpg-conference-part-2/

http://blogs.arm.com/multimedia/771-arms-astc-adopted-by-khronos-group/
ASTC seems very promising against PVRTC and ETC2. I wonder how it compares against PVRTC2?
 
Storing so much/many extra information/values with their bounded interger sequence encoding and being able to balance between them is seemingly clever, though the characterization of the cost in silicon implementation made in that article makes me suspect that hardware acceleration will be anything but a trivial design decision. Other promising texture compression schemes have been abandoned in the past due to hardware cost, though the hands of the hardware engineers would be forced if ASTC does progress toward standardization.

And it may very well be worth it for that kind of flexibility and quality in TC.
 
not quite sure what you are asking.....?

1. why does the T604 need 3.0?
- because support for new standard is just lovely

2. are you sure the T604 doesn't support 3.0?
- well the product page does not list support for 3.0, but i'd love to find out otherwise

oddly enough someone at Chronos obviously thought it would:

www.khronos.org/assets/uploads/deve...show/OpenGL-and-OpenGL-ES-Taiwan_Feb-2012.pdf

so can we get to the bottom of this:
a) does the T604 support 3.0?
b) if not, why not (given that the rest of the family does)?
 
Back
Top