Yes, I am on XP. IEGD does not support WDDM. I have the strong feeling that the 1005 driver is quite similar to the 1009 XP (e.g. there is no OpenGL, Shader Model 3.0 is supported).
IMG confirm that Intel is using SGX
- Thread starter tangey
- Start date
Yes, I am on XP. IEGD does not support WDDM. I have the strong feeling that the 1005 driver is quite similar to the 1009 XP (e.g. there is no OpenGL, Shader Model 3.0 is supported).
Hi There,
Interested to here about improved performance with the IEGD drivers. I'm registered and downloaded the drivers from Intel. From the docs it seems to refer to having to build a Video biso to use with these drivers. Is this true ?, or do you just install them as a normal driver installation. I have a Dell mini 12" with Intel Z atom, so I'm looking to improve the graphics and video performance.
One more interesting result using Humus's GL_EXT_Reme OpenGL benchmark. For IEGD10 the included OpenGL driver was used (written by Tungsten), for the official Intel driver Scitech's OpenGL->D3D wrapper was used. Results (IEGD --- Scitech):
Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 62.18 fps --- 110.60 fps
Overdraw factor 3, front to back: 62.51 fps --- 110.55 fps
Overdraw factor 3, random order: 62.55 fps --- 110.58 fps
Overdraw factor 8, back to front: 58.53 fps --- 97.39 fps
Overdraw factor 8, front to back: 58.83 fps --- 97.51 fps
Overdraw factor 8, random order: 58.67 fps --- 97.28 fps
Fillrate:
---------
Pixel fillrate: 54.97 MegaPixels / s --- 88.21 MegaPixels / s
Texel fillrate: 232.72 MegaTexels / s --- 131.83 MegaTexels / s
T&L/High polygon count static display list:
-------------------------------------------
Pure transform: 2195968 vertices / s --- 1621888 vertices / s
2 point lights: 690836 vertices / s --- 682604 vertices / s
8 point lights: 225655 vertices / s --- 263798 vertices / s
2 directional lights: 2172489 vertices / s --- 1415564 vertices / s
8 directional lights: 1560491 vertices / s --- 1064740 vertices / s
High memory bandwidth load/texture cache efficiency:
----------------------------------------------------
One 1024x1024x32 texture: 62.05 fps --- 94.30 fps
Four 1024x1024x32 textures: 61.85 fps --- 94.18 fps
So it seems that a wrapper over the not too mature D3D driver provides better results than the "real" OpenGL driver.... (Texel fillrate is lower probably because Scitech only supports 2 textures). The HSR numbers are also interesting, because they look like a TBDR result - what is in contrast with the PowerVR Fortune results posted earlier. I wouldn't say I really understand the reasons...
Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 62.18 fps --- 110.60 fps
Overdraw factor 3, front to back: 62.51 fps --- 110.55 fps
Overdraw factor 3, random order: 62.55 fps --- 110.58 fps
Overdraw factor 8, back to front: 58.53 fps --- 97.39 fps
Overdraw factor 8, front to back: 58.83 fps --- 97.51 fps
Overdraw factor 8, random order: 58.67 fps --- 97.28 fps
Fillrate:
---------
Pixel fillrate: 54.97 MegaPixels / s --- 88.21 MegaPixels / s
Texel fillrate: 232.72 MegaTexels / s --- 131.83 MegaTexels / s
T&L/High polygon count static display list:
-------------------------------------------
Pure transform: 2195968 vertices / s --- 1621888 vertices / s
2 point lights: 690836 vertices / s --- 682604 vertices / s
8 point lights: 225655 vertices / s --- 263798 vertices / s
2 directional lights: 2172489 vertices / s --- 1415564 vertices / s
8 directional lights: 1560491 vertices / s --- 1064740 vertices / s
High memory bandwidth load/texture cache efficiency:
----------------------------------------------------
One 1024x1024x32 texture: 62.05 fps --- 94.30 fps
Four 1024x1024x32 textures: 61.85 fps --- 94.18 fps
So it seems that a wrapper over the not too mature D3D driver provides better results than the "real" OpenGL driver.... (Texel fillrate is lower probably because Scitech only supports 2 textures). The HSR numbers are also interesting, because they look like a TBDR result - what is in contrast with the PowerVR Fortune results posted earlier. I wouldn't say I really understand the reasons...
thanks for the bechmarking, Tessier.
edit:
tests figures really make little sense. from what i recall, poulsbo's GMA is clocked at at least 100MHz, at 2 pixels/clock top fillrate (SGX535), the quoted 55-88MPix/s seem way too low (no effective HSR assumed). also, intel themselves quote the vertex pipeline as capable of doing a vertex/15 clocks. if we asume that as a maximal rate (ie. no pipelininig, etc), those 2.2MV/s of pure transform would translate to 33MHz shader engine clock - no way in hell that'd be the GMA's clock. smells like SW T&L to me. either that or a broken/inefficient VBO mechanism.
are we sure the fortune test does not alpha-blend?
edit:
tests figures really make little sense. from what i recall, poulsbo's GMA is clocked at at least 100MHz, at 2 pixels/clock top fillrate (SGX535), the quoted 55-88MPix/s seem way too low (no effective HSR assumed). also, intel themselves quote the vertex pipeline as capable of doing a vertex/15 clocks. if we asume that as a maximal rate (ie. no pipelininig, etc), those 2.2MV/s of pure transform would translate to 33MHz shader engine clock - no way in hell that'd be the GMA's clock. smells like SW T&L to me. either that or a broken/inefficient VBO mechanism.
Last edited by a moderator:
Only the smallest mid format devices use the 100Mhz variant of Poulsbo, the mainstream Poulsbo chipset clocks SGX at 200MHz
well, i went for the worst case scenario. otherwise i seem to remember working on a crown beach board clocked at 200MHz.
from the same article:
you'd think the article would go with piece of hw that was intel-based, no?
i mean, 'intel have been doing a great job with the miniaturisation of their tech. here's this TI board running our design' does not exactly drive a point home : )
Intel today launched the next SOC in their CE line, the CE4100. It implements SGX535, which the CE3100 also implemented. However its implementation results in two "first"s for SGX.
1) Its the first implementation of SGX at 45nm.
2) The CE4150 variant clocks 535 @ 400Mhz, which is nearly twice as fast as any previous SGX implementation.
http://www.intelconsumerelectronics.com/Download/Sodaville_Product_Brief_.pdf
1) Its the first implementation of SGX at 45nm.
2) The CE4150 variant clocks 535 @ 400Mhz, which is nearly twice as fast as any previous SGX implementation.
http://www.intelconsumerelectronics.com/Download/Sodaville_Product_Brief_.pdf
http://www.linuxfordevices.com/c/a/News/Pine-Trail-scheduled-for-fourth-quarter/?kc=rss
According to the link above we may well see both
Moorestown and Pinetrail join intel's CE4100 with a PowerVR SGX535 embedded as part of the SOC. Whilst plausible I am rather suprised given the availability of SGX540 which would have been my choice for Moorestown. Meanwhile there's alot of conjecture over the Pineview soc and whether it will be a shrunck 945GSE or a GMA500.
According to the link above we may well see both
Moorestown and Pinetrail join intel's CE4100 with a PowerVR SGX535 embedded as part of the SOC. Whilst plausible I am rather suprised given the availability of SGX540 which would have been my choice for Moorestown. Meanwhile there's alot of conjecture over the Pineview soc and whether it will be a shrunck 945GSE or a GMA500.
Back in post #56 of this thread, I conjectured that IMG tec might appear in either pineview or in the on-graphics versions of clarkdale/arrandale, given that IMG had stated that they saw their technology appear in the desktop space.
Well it is now apparent that IMG does not feature either in Pineview, nor in Clarksdale/Arrandale
Well it is now apparent that IMG does not feature either in Pineview, nor in Clarksdale/Arrandale
Intel have released the first datasheets on the various pineview/trail platforms:-
http://www.intel.com/products/processor/atom/techdocs.htm
http://www.intel.com/products/processor/atom/techdocs.htm
5 min video demo of LG prototype smartphone based on Moorestown. (SGX graphics and VXD video IP).
UI is pretty polished given its still 6 months away from production, OS is Moblin.
video shows 3 apps running concurrently on the screen, one of them being a 720p video.
http://ces.cnet.com/8301-31045_1-10430096-269.html?tag=mncol;txt
UI is pretty polished given its still 6 months away from production, OS is Moblin.
video shows 3 apps running concurrently on the screen, one of them being a 720p video.
http://ces.cnet.com/8301-31045_1-10430096-269.html?tag=mncol;txt
Intel says it will out-perform all ARM chips
Pankaj Kedia on Moorestown:
"We will surprise everyone," he said. "We will out-perform ARM chips hands-down, and we will have better graphics on Moorestown than anything else."
http://channel.hexus.net/content/item.php?item=22489
Looks like SGX in moorestown might be running faster than the 200Mhz in Poulsbo, (but probably not at the 400MHz as implemented in the CE4100 chip).
In which case given that it launches in Q2, with likely end product likely by end of year, his assesment of it having the best graphics might be on the money. I assume it also has IMG video encode and decode (VXD and VXE)
Pankaj Kedia on Moorestown:
"We will surprise everyone," he said. "We will out-perform ARM chips hands-down, and we will have better graphics on Moorestown than anything else."
http://channel.hexus.net/content/item.php?item=22489
Looks like SGX in moorestown might be running faster than the 200Mhz in Poulsbo, (but probably not at the 400MHz as implemented in the CE4100 chip).
In which case given that it launches in Q2, with likely end product likely by end of year, his assesment of it having the best graphics might be on the money. I assume it also has IMG video encode and decode (VXD and VXE)
Vendor side PR. doesn't count for anything.
Always worth considering, but given that they currently *do* have the fastest SOC graphics in production with the 400Mhz implementation of SGX535 in the 45nm CE4150, its not just PR speak.