ARM Midgard Architecture

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/developers/library/2012-pan-pacific-road-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)?

Because it would be more than absurd for an as advanced GPU (in a relative sense for the small form factor space) like T604 to not support OGL_ES3.0. On one hand it supports advances stuff like atomic operations and FP64 and not ES3.0?
 
Because it would be more than absurd for an as advanced GPU (in a relative sense for the small form factor space) like T604 to not support OGL_ES3.0. On one hand it supports advances stuff like atomic operations and FP64 and not ES3.0?

i agree, it would be absurd, but colour me confused as to why ARM do not list support on the product page, whilst making a specific point of stating that the T628 does support 3.0 at the top of the same page.

even if its just a driver restriction designed to herd customers towards higher-margin SKU's it still does the consumer no good when he is looking at a device sporting the T604.......
 
i agree, it would be absurd, but colour me confused as to why ARM do not list support on the product page, whilst making a specific point of stating that the T628 does support 3.0 at the top of the same page.

even if its just a driver restriction designed to herd customers towards higher-margin SKU's it still does the consumer no good when he is looking at a device sporting the T604.......
The original OpenGL ES 3.0 announcement mentioned it'll take up to 6 months to release conformance tests. ARM may just be conservative in not claiming OpenGL ES 3.0 compliance until they have the certification to back it up. Does Khronos have any rules against claiming compliance without being subjected to testing?
 
Yep. I can't recount the specifics and how it works for Promoters, but it's against the Khronos agreement to do so in the main unless you've passed conformance.
 
ARM should just state that they expect, or are planning, to support the next version of OpenGL ES on the T-604. No issues with that wording.
 
Yep. I can't recount the specifics and how it works for Promoters, but it's against the Khronos agreement to do so in the main unless you've passed conformance.

Is opencl 1.1 embedded profile an official khronos standard ? I don't see anywhere on the khronos website for it, or indeed any entry to say some of the SGX cores have passed it ?
 
Is opencl 1.1 embedded profile an official khronos standard ? I don't see anywhere on the khronos website for it, or indeed any entry to say some of the SGX cores have passed it ?

For OpenCL, the "embedded profile" is provided in the main OpenCL specification text (chapter 10 in the case of the OpenCL 1.1 spec), rather than as a separate spec document.

While there doesn't seem to exist any SGX cores supporting OpenCL 1.1, either full or embedded, there exists at least two Vivante cores that have passed the conformance tests for OpenCL 1.1 embedded profile.
 
Did you look in section 10 of the OpenCL 1.1 spec?

I didn't read the spec at all :)

one assumes that as its a subset of the full profile, then any cores that have passed the embedded profile should appear in the opencl 1.1 list. Many SGX cores are quoted as supporting 1.1 embedded and Sgx545 core is quoted as supported 1.1 full profile, but I don't see them in the list. My interest was therefore raised when Rys mentioned that compliance shouldn't be referred to unless the appropriate core has been submitted and passed the test (albeit he does mention a possible caveat for promoters, which IMG of course are)
 
Last edited by a moderator:
We're only 1.0 Embedded compliant on the current driver. 1.1 Embedded is on the way for all USSE revs.
 
i agree, it would be absurd, but colour me confused as to why ARM do not list support on the product page, whilst making a specific point of stating that the T628 does support 3.0 at the top of the same page.

even if its just a driver restriction designed to herd customers towards higher-margin SKU's it still does the consumer no good when he is looking at a device sporting the T604.......

well, two months later, and now with a T604 product launched and the arm page still only lists the GPU as OpenGL ES 2.0 compliant.

getting pessimistic about ever seeing support, the driver conformance test idea would seem more likely were it not for the fact that their existing products (with actual drivers) don't list support, whereas they are happy to shout out about ES 3.0 for successor (as yet) vaporware products.
 
Last edited by a moderator:
Mali T760 and T720 announced.

The T760 seems to be an up-to 16-core version of the T678 plus some techs that decrease memory bandwidth needs.

I don't really get what the T720 is, but it seems to be the successor to Mali 450MP8, so I'd expect similar performance with OpenGL ES 3.0 compliance and lower power consumption.

Both seem to target 700MHz using TSMC 28HPM.

Lanch partners seem to be Mediatek, Rockchip and.. LG Electronics?
 
Among some of the new features of the Mali-760:
Other features of the ARM Mali-T760 GPU include YCrCb frame buffer output and hardware assisted global illumination.
http://community.arm.com/groups/arm-mali-graphics/blog

Seems like that could stand for some more explanation.

Nice to read about the frame buffer compression. The elimination of work on non-updated pixel blocks for output and within the pipeline is also mentioned as a couple of new technologies, but that raises a few questions. I'll have to see if more info has been provided.
 
Back
Top