IMG confirm that Intel is using SGX

And there it is:

http://www.imgtec.com/corporate/newsdetail.asp?NewsID=473

I thought Apple would buy more, but better than nothing :)

They did buy a lot more, prior to yesterday they held 3%. They bought 2% via a share issue from IMG (in other words IMG got the money), and they bought a further 4.5% in the open market.

So they bought a further 6.5%. They now have 9.5%, Intel has 16%, between them, they now own 25% of IMG.

Thats what I call "Intel Inside"
 
intel have different departments providing support for different intel GPUs. for instance, their current (oss) support for the gma4500 line (g45 & co) is outstanding - it's among the poster drivers in the DRI2 tree. in contrast, last time i checked gma500, it was more-or-less left on auto-pilot (read: was using a premordial tungsten edge for the 3d part).

Current is the keyword here for 4500; how did it look like when the chipset was first introduced?

i'm glad to see intel being so committed to using the SGX architecture, but their left and right hands need to work toward the common goal before you call intel's SGX integrations a viable product.

My problem with Intel is that it takes an unexcusable amount of time for anything graphics up to date to get their drivers on a level they should be since day one. I'm afraid SGX535/Poulsbo might be even obsolete if and when any SGX gets decent driver attention.
 
You're right, the OEM they mention is probably Sony.

The latest news that's come my direction says that SEGA wants to keep costs down in regards to silicon and thus will probably use the Aurora SoC. The reason for this is because they plan on utilizing an expensive force feedback based touchscreen. Apparently it is so advanced that users shall perceive the sensation of pressing, depressing, releasing of actual physical buttons, keys etc.

They are going to test the technology in the arcades first, on the RINGWIDE hardware. With the first games appearing at the end of this year -

http://www.andriasang.com/e/blog/2009/06/19/sega_dual_screen_arcade/
 
Would have thought that Aurora "Dreamcast" on a chip is too old, and they'd perhaps look to an SGX variant?
IF "Aurora" is the SoC I think it is, then it's possibly the most powerful MBX system there is and also includes one Dreamcast feature that no contemporary hardware has - i.e. translucency sorting.
 
IF "Aurora" is the SoC I think it is, then it's possibly the most powerful MBX system there is and also includes one Dreamcast feature that no contemporary hardware has - i.e. translucency sorting.

From:-
http://www.system16.com/hardware.php?id=732

Hardware : System-on-a-chip 90nm solution with integrated CPU, Graphics and Sound Hardware.
CPU : Hitachi SH-4 32-bit RISC CPU @ 300MHz
GPU : Imagination Technologies Power VR MBX+VGP @ 150MHz
SPU : ADPCM Sound
Triangle Rendering : 10M Polygons/sec
Fill Rate : 150M Pixel/sec
Max Resolution : 1280x1024
Other Features : Ethernet and USB


The oldest game mentioned on that wepage is 2005, which makes the platform 4-5 years old.
 
You're right, the OEM they mention is probably Sony.

The latest news that's come my direction says that SEGA wants to keep costs down in regards to silicon and thus will probably use the Aurora SoC. The reason for this is because they plan on utilizing an expensive force feedback based touchscreen. Apparently it is so advanced that users shall perceive the sensation of pressing, depressing, releasing of actual physical buttons, keys etc.

They are going to test the technology in the arcades first, on the RINGWIDE hardware. With the first games appearing at the end of this year -

http://www.andriasang.com/e/blog/2009/06/19/sega_dual_screen_arcade/


I wonder if this new product requires some sort of video decode? Reason I ask is that SI electronics took a VXD370 licence "for use in devices targeting the amusement market".

SI electronics was part of the development team that designed the Aurora based system.
 
To get this thread back on topic, I've seen the first confirmation that Moorestown will use SGX graphics.

I've been doing some sniffing around for moorestown drivers, to confirm that it contains SGX. the open community is the best place to look, as its a collaborative environment.

If you look here:-
http://www.opensubscriber.com/message/dri-devel@lists.sourceforge.net/11716475.html
(warning its a BIG page),

You'll find "poulsbo/moorestown DRM driver"

There's a programming flag in there "IS_MRST" which is set when dealing with moorestown variation. In terms of graphics, the moorestown code is pretty much the same as the poulsbo (psb) code, with just some slight modifications and path variants. From that code I can confirm that Moorestown definitely has SGX in it, with the SGX registers in a different area of the memory map than in poulsbo, as this snippet of code reveals:-

if (IS_MRST(dev))
dev_priv->sgx_reg =
ioremap(resource_start + MRST_SGX_OFFSET,
PSB_SGX_SIZE);
else
dev_priv->sgx_reg =
ioremap(resource_start + PSB_SGX_OFFSET, PSB_SGX_SIZE);

later in the code, the offsets are defined as:-
PSB_SGX_OFFSET 0x40000
MRST_SGX_OFFSET 0x80000

The PCI_ID for moorestown is anything from 0x4100-0x4107, meaning they are allowing for the possibility of up to 8 sku variants. This could be simply different packages, clock rate, temp range etc.

#define psb_PCI_IDS \
{0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
{0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
{0x8086, 0x4100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4101, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4103, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4104, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4105, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \
{0x8086, 0x4107, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MRST_4100}, \

for comparision, the 8108 and 8109 ID's above for poulsbo are used to differentiate between the MID (L) and UMPC (W) versions of the existing SCH

Note that in general within the code, the moorestown variations seems to be dealt with in pretty much the same way as the poulsbo variation, with the clear suggestion thats its pretty much the same. There is nothing in the code that can be used to determine clock rates, so we dont' know if it operates at the same rate or quicker.

Some more interesting things are in the file.

First, Tungsten graphics are still involved. AS of Nov last year, they have been taken over by VMWARE and there is some VMWARE copyright headers in there.

Second, it appears from looking at the code, that the version of VXD that IMG supplied to Intel for poulsbo (and moorestown) is codenamed "topaz"

The above comments are my own personal interpretation of the code at that publicly accessible webpage. The file is dated March '09, so that must be borne in mind too
 
First, Tungsten graphics are still involved. AS of Nov last year, they have been taken over by VMWARE and there is some VMWARE copyright headers in there.

That doesn't sound either like bad or good news to me :rolleyes:
 
That doesn't sound either like bad or good news to me :rolleyes:

Quite...I just called it "interesting" :)


Also I've seen some follow up comments regarding those patches, and apparently some of them have been removed as there was some uncertainty regarding GPL licensing issues Vis-a-Vis closed portions of the 3D drivers.
 
Intel's GMA 500 drivers do not seem to be mature to say the least...

DXVA works both in XP (1009 driver) and Win7 (1005 driver) using the default renderer (Overlay/EVR). However, in Win7 I had a lot of frame dropping when using MPC or KMPlayer EVR Custom Renderer (which means no subtitles). In XP, KMPlayer's VMR7 Renderless renderer works correctly, but VMR9 Windowed or VMR9 Renderless causes frame droppping.

The Intel/notebook manufacturer drivers offers VS3.0/PS3.0 but no OpenGL at all. Drivers generated with IEGD 10 (Intel Embedded Graphics Driver, XP only) does not support VS and only PS2.0. Still, the performance is almost twice of the normal driver. I did not have any luck using custom video renderers with this driver, although the default Overlay works. Unfortunately I could not generate a driver which keeps the aspect ratio for lower resolutions.

So, for me, it is interesting that PowerVR demonstrated GMA 500 in Vista with concurrent H264 playback and Quake3. It would be interesting to get some performance results measured with their in-house drivers.
 
Hardware translucency sorting was re-enabled for the Aurora platform (full MBX+VGP @ 150MHz + SH-4 w/FPU @ 300MHz, aka SH3707)!?

Wow! Any possibility of doing that to an SGX platform or two?
 
The following quote is from IMG's annual report which was published today:-

"We are confident that we have the strategic relationships to be a major player in
mobile computing and to even see some of our technologies in the desktop space."

Thats the first time IMG have openly stated an expectation to be in the "desktop space".

For me that suggests either some pintrail/pineview variants will end up in entry level PCs, or there will be a nehalem variant with on-chip IMG graphics.
 
Maybe video cores as well?

I think Series 6 will be the evolutionary transition from graphics processor to a main processor best suited to parallelized, floating point intensive workloads.
 
Maybe video cores as well?

I think Series 6 will be the evolutionary transition from graphics processor to a main processor best suited to parallelized, floating point intensive workloads.

Hmmm remember for the last one that they always have to be extremely careful since their largest customers are large semicondunctor manufacturers. You wouldn't want too many colliding interests in such a case ;)
 
I did some benchmarks with the end-user (.1009) and IEGD10 drivers (end-user/IEGD).
PowerVR VillageMark: 13/57
PowerVR Fortune (50 cards): 4/42
3DMark fillrate: 190, 330/220, 330
MDolenc - Pure fillrate: 1002/1122
MDolenc - Z pixel rate: 68/1121
MDolenc - Single Texture: 1004/1121
MDolenc - Dual Texture: 1000/1121

PowerVR's Fortune draws several cards on top of each other. For tilers the achieved frame rate should be more or less the same irrespectively of the number of cards and the effective fill rate increases. This is the situation with the IEGD driver, however the end-user driver behaves like an IMR - the frame rate drops as the number of cards increases and the effective fill rate remains the same. VillageMark and MDolenc results also support the theory that there is someting screwed up with the HSR part when using the official drivers. Maybe there is hope for acceptable performance....
 
Back
Top