Samsung Orion SoC - dual-core A9 + "5 times the 3D graphics performance"
- Thread starter Mike11
- Start date
D
Deleted member 13524
Guest
New Exynos 4212. According to slashgear:
Is it a good guess assuming that "designed for 3D gaming and graphics" means they upclocked the Mali400MP4, or it's not too soon to release a Mali T604?
slashgear said:
Is it a good guess assuming that "designed for 3D gaming and graphics" means they upclocked the Mali400MP4, or it's not too soon to release a Mali T604?
Nebuchadnezzar
Legend
They mention a 50% boost in performance, which coincides with a boost from the default 267MHz to 400MHz.
If anyone is interested in the performance ballpark at those frequencies here is one of the tests I did on my SGS2 overclocked at 1.6GHz and 400MHz GPU: http://i.imgur.com/t5Qfi.png
It varied from run to run a bit (the whole test takes way to long for just a casual user like me). Egypt offscreen went up to 60.5fps as top score and Pro to around 88fps.
As for power draw it got pretty hot and it was draining battery while connected to AC (750mA charging rate I think).
D
Deleted member 13524
Guest
So that puts the 32nm Exynos with approximately the same 3D performance as Tegra 3 (~6000 frames in Egipt Offline).
Assuming Tegra3 scores will remain the same when it'll ship it gained in Egypt offscreen 720p = 53.0 fps while the SGS2 is at the moment at 47,3 fps. Assuming a nearly linear scale with frequency the latter should end up with theoretical 400MHz at give or take 70fps.
I'm not even clear yet what the base requirements for win8 embedded will be. Mali400 has 24bit Z precision and it's TMUs are capable of up to 4096*4096 textures; the only other thing that would keep them from any theoretical compliance would be FP16 only in the PS ALUs. Does the latter really matter for win8? If yes then Mali400 won't be the only one with that problem since NV's ULP GF has FP20 only PS ALUs, 2048*2048 TMUs and 16bit only Z precision.
No idea. But I wouldn't suggest that we'll see any next generation GPU core or IP before 28nm the earliest (ie not before 2013) in final devices.
All I've heard is that microsoft has stated that win8 needs DX9 graphics (in fact I think its specifically DX9.3)
The recent BUILD conference had a guide
http://download.microsoft.com/downl.../Windows_Developer_Preview-Windows8_guide.pdf
which confirmed Dx9 as a fundamental system requirement for both ARM and X86 systems.(page 30/31)
D
Deleted member 13524
Guest
Dunno about the texture size and Z-precision, but afaik Win8's requirements are DX9, which probably means it won't require DX9c, so FP20 PS ALUs should be fine.
Mali400 doesn't support DXTC/S3TC, and that might be a bigger problem if it's constantly used in the Metro/Aero UI..
I was trying to remember where I saw the specific DX9.3 requirement.
This is were it was:-
http://www.pcsmax.com/windows-8-and-arm-directx-is-required-11869.html
I know that IMG specifically quote the SGX544 (TI Omap 4470) as being DX9.3 compliant.
ARM have never mentioned DX compliance for mali-400, only started to mention it for T-604.
This is were it was:-
http://www.pcsmax.com/windows-8-and-arm-directx-is-required-11869.html
I know that IMG specifically quote the SGX544 (TI Omap 4470) as being DX9.3 compliant.
ARM have never mentioned DX compliance for mali-400, only started to mention it for T-604.
Could be Microsoft simply closes one eye for PS precision, since even for DX9SM2.0 the minimum precision is FP24, not 20 and not 16.
As for texture compression, I wouldn't think that it would be much of a problem that ARM simply fetches a license and integrates an according algorithm.
Well some clarification if any insider can speak up would help. From the top of my head the most important L3 requirements are texturing related (but would like to stand corrected). In that regard 544 is amongst the cores that support 4k*4k textures and that's why I mentioned it above (amongst other things obviously).
DX 9_3 hardware requirements:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
Quick recap of important features:
- SM 2.0+ (VS 2.a, PS 2.b)
- Texture size 4096x4096
- 16x anisotropic filtering
- 4x MRT rendering (very useful for deferred rendering)
- Occlusion queries
- Instancing
Here's the texture format support table:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471324(v=vs.85).aspx
Recap on supported formats (for 9_3):
- 32 bit float (4d, 2d, 1d)*1 + 3d only for vertex input
- 16 bit float (4d, 2d, 1d)*1
- 16 bit int (4d, 2d, 1d)*1
- Depth buffer only supported as render target (no depth texture reading)
- BC1, BC2 and BC3 (DXT1, DXT3 and DXT5)
- R8G8B8A8_UINT is the only supported 8 bit per channel format for vertex input (1d and 2d are only supported in texture sampling)
- No support for 10 bit per channel formats (vertex or texture)
*1) When used as render target, alpha blending is required in: 4d 16 bit float, 2d 32 bit float and 8888 formats only. Texture filtering is required in: 4d, 2d and 1d 16 bit integer formats + 8888 formats and DXT formats. Float formats do not require filtering.
Four render target simultaneous MRT rendering likely requires changes to mobile hardware. So far only Tegra drivers expose this functionality on mobile devices (not sure if others support it by hardware, but not have required OpenGL ES extensions). Tegra is also the only one supporting DXT compression. 32 bit per channel (128 bits per pixel) floating point textures, 16 bit integer textures/rendertargets can also require hardware changes (blending is required for 16f and 32f render targets, and filtering for 16 bit integers). Otherwise there doesn't seem to be anything the current mobile hardware isn't capable of.
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
Quick recap of important features:
- SM 2.0+ (VS 2.a, PS 2.b)
- Texture size 4096x4096
- 16x anisotropic filtering
- 4x MRT rendering (very useful for deferred rendering)
- Occlusion queries
- Instancing
Here's the texture format support table:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471324(v=vs.85).aspx
Recap on supported formats (for 9_3):
- 32 bit float (4d, 2d, 1d)*1 + 3d only for vertex input
- 16 bit float (4d, 2d, 1d)*1
- 16 bit int (4d, 2d, 1d)*1
- Depth buffer only supported as render target (no depth texture reading)
- BC1, BC2 and BC3 (DXT1, DXT3 and DXT5)
- R8G8B8A8_UINT is the only supported 8 bit per channel format for vertex input (1d and 2d are only supported in texture sampling)
- No support for 10 bit per channel formats (vertex or texture)
*1) When used as render target, alpha blending is required in: 4d 16 bit float, 2d 32 bit float and 8888 formats only. Texture filtering is required in: 4d, 2d and 1d 16 bit integer formats + 8888 formats and DXT formats. Float formats do not require filtering.
Four render target simultaneous MRT rendering likely requires changes to mobile hardware. So far only Tegra drivers expose this functionality on mobile devices (not sure if others support it by hardware, but not have required OpenGL ES extensions). Tegra is also the only one supporting DXT compression. 32 bit per channel (128 bits per pixel) floating point textures, 16 bit integer textures/rendertargets can also require hardware changes (blending is required for 16f and 32f render targets, and filtering for 16 bit integers). Otherwise there doesn't seem to be anything the current mobile hardware isn't capable of.
Last edited by a moderator:
Samsung just took a 5XT licence from IMG. Given the big hoohaa Arm made of taking Samsung away from Img, this is a big hit for them.
Could it be that Samsung need that dx compliance and that T604 is too far away?
"Imagination Technologies Group plc (LSE: IMG; "Imagination"), a leader in System-on-Chip Intellectual Property ("SoC IP"), has signed a license agreement with Samsung Electronics Co., Ltd. ("Samsung") for IP from Imagination's PowerVR SGX MP multiprocessor graphics family."
Could it be that Samsung need that dx compliance and that T604 is too far away?
"Imagination Technologies Group plc (LSE: IMG; "Imagination"), a leader in System-on-Chip Intellectual Property ("SoC IP"), has signed a license agreement with Samsung Electronics Co., Ltd. ("Samsung") for IP from Imagination's PowerVR SGX MP multiprocessor graphics family."
D
Deleted member 13524
Guest
I think that's a fair assumption.
These latest slides claim that Mali T604 won't be ready until at least 2H 2012, and that should be when Windows 8 tablets start coming out. Samsung is probably avoiding staying behind the Win8 tablet race because of the lack of DirectX compliance in the current Mali GPUs.
according to graph, 4-Core ready 2nd half 2013. The 8-core isn't around until mid 2015.
Depending on how you interpret ARM's marketing, it appears that T658 isn't a major performance improvement over T604 on a per core basis. Most of the performance improvments are based on having more cores. Of course they are adding more compliance in as well.
i.e. T604 was "up to x5" Mali-400.
T658 is "up to x10" mali-400
so might we assume that T658 is "up to x2" T604 ?
I view this as similar to the step that IMG has from SGX544 to SGX554.
Be interesting when we eventually get to compare T658 V's Rogue, not only in performance, but also in terms of size.
One wonders will we sometime shortly get some actual data on Rogue, given that ARM has now shown their hand.
Similar threads
- Deleted member 13524
- Mobile Devices and SoCs