ARM Midgard Architecture
- Thread starter arjan de lumens
- Start date
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
It sure seems likely that NVIDIA will use this.
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 ?
Does this new compression algorithm require an arm license for the hardware implementation ?
http://www.khronos.org/news/press/k...-generation-texture-compression-specification
In addition to ARM and NVIDIA, there are also endorsements from Imagination and AMD.
In addition to ARM and NVIDIA, there are also endorsements from Imagination and AMD.
D
Deleted member 13524
Guest
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?
I see both the T-628 and T-658 as "8-core" GPUs, so what's the difference? Clocks and power budget?
ltcommander.data
Regular
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.
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/
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.
ltcommander.data
Regular
ASTC seems very promising against PVRTC and ETC2. I wonder how it compares against PVRTC2?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/
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.
And it may very well be worth it for that kind of flexibility and quality in TC.
codedivine
Regular
OpenCL conformance achieved
Khronos website now lists T604 as OpenCL 1.1 conformant: http://www.khronos.org/conformance/adopters/conformant-products
Khronos website now lists T604 as OpenCL 1.1 conformant: http://www.khronos.org/conformance/adopters/conformant-products
jedibeeftrix
Newcomer
nice, but shame it doesn't get OpenGL ES 3.0 compliance.
Honest question: why shouldn't it?
jedibeeftrix
Newcomer
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)?
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)?