some more info about NVIDIA AR10 ("GoForce3D")

ram

Newcomer
ftp://download.nvidia.com/developer/Handheld_SDK/PO_GoForce_3D.pdf
&&
http://developer.nvidia.com/object/hhsdk_home.html

Looks like the AR10 hasn't a vertex shader, but just an Int/FP transformation engine. The "programmable" shading core is capable of six layer multitexturing, but seems to lack advanced features such as dot3 for bump mapping.

bubble_preview_thumb.jpg
 
IMHO raises a question :

The transform unit takes vertex information (X, Y, Z, W plus color
and/or texture attributes), applies a user defined transform to
calculate screen space coordinates for each triangle which is then
sent to the rasterizer unit to draw the given triangle.

Geometry transform engine (floating point and fixed point)

Now I wonder why do they mention transform but not lighting ?

Downloading SDK to see if it has more info...

K-
 
Can someone kindly explain how you can get acceptable results with 6-layer multitexturing and 16bpp colour depth, however high the quality of the dithering method will be?
 
Multitexturing could be kept on the chip, instead of doing a read-modify-write you actually do all the 6 multi-texture blends on the chip and then do a single dithered write. This is probably why they mention 40 bits internal (probably 10 bits per channel). Hence the combine of the 6 layers is done with full accuracy and then on the final write out the dithering is done once... now this does raise the cache efficiency question when you need to keep 6 different textures around.

The real issue is with alpha-blending, multiple alpha-blended layers cause trouble since each layer adds dithering. So a smoke trial effect as seen in Quake will go ugly... but 6 multi-textured layers will not since there is only one dither operation.

Most likely they support 6 layers since it saves bandwidth, no need to do multipass which introduces read-modify-write ops and also dithering.

A Tile based architecture does not suffer from any of this since everything is on chip at high quality (tile buffer) and only 1 single write out with dithering is done, ever.

K-
 
:!:
Kristof, please reassure me... You guys are gonna take over that market with the MBX so much NVIDIA won't even get any contract for this chip? Right? Right?
I really, really don't want to see this POS in anything, or I'd probably cry... :(

Uttar
 
They claim support for OpenGL ES 1.1, a standard that is still under development. Dunno what to make of this one.

The power management part seems to be a bit beyond what you can do within a soft IP core; if this implies that the chip is a hard IP, that by itself may turn people away from Nvidia on this offering as it severely limits what manufacturing processes you can run it on (AFAIK, at least MBX and probably AcceleonG30 are soft-IP).

It doesn't support 32-bit texturing, which makes 40-bit internal precision look like a massive waste of transistors.

The anti-aliasing apepars to be the same kind of super-sampling as seen in Geforce1/2, which is both slow and bandwidth hungry (BIG no-no on handheld devices :!: )

Other than many-layer multitexturing of unknown quality, I don't see this core having any advantages over either MBX/MBX lite or Acceleon G30.

Unfortunately, Nvidia has marketing power most of the other players in this market can only dream about, so we most likely WILL end up somewhere.
 
I think if you look into the ATI QUALCOMM deal it sounds as though we are beginning to see the 3dfx (early years) of the mobile market.
 
The first couple of handheld chips, even 2D, in the PDA market sucked rocks. We are definately seeing the Virge/Verite/3dfx "stage" of the market. PDA's/Cellphones really haven't had any uptake in gaming market.

Reason #1 is (except for NGage), the controls they have were designed for phone/PIM apps, not gaming. Reason #2 is, slow graphics. PocketPC probably came closest to usability, but still pales compared to GameBoy.

MBX would be a waste in a PDA/Phone if it isn't put into something like an NGage or a device that has some kind of adapter to use a gamepad.

Of course, the new standard to beat will be PSP. :)
 
I wonder why they haven't used any Gigapixel tech in their mobile stuff. Seems to me that they are sitting on a goldmine that they don't want to explore.
 
arjan de lumens said:
It doesn't support 32-bit texturing, which makes 40-bit internal precision look like a massive waste of transistors.
Notice the line:
40-bit color pipeline with signed non-integer color (over bright)
Apparently it's not 40-bit color for precision reasons only. Additionally, palletized textures are supported, which will give 8 bits per channel for a limited number of colors. DXT compression is also supported.

In other words, there may be a decent reason for 40-bit color throughout the pipeline.

Regardless, I don't see why this architecture is bad for handhelds. The performance and power consumption numbers will be the most important, though, and those are as yet unknown.
 
Chalnoth said:
Regardless, I don't see why this architecture is bad for handhelds. The performance and power consumption numbers will be the most important, though, and those are as yet unknown.
For the handheld market, cost is often critical as well, both in terms of IP licensing costs and production costs (large IP -> large chip -> less chip per wafer -> higher production cost). It is hard to make any meaningful guesses about the relative cost of AR10 vs MBX or G30 without any official information available, though.

I would expect it to be much worse than MBX in terms of power consumption per pixel - it is immediate-mode, forcing several off-chip memory accesses per pixel that the MBX nicely avoids - and off-chip memory accesses are expensive from a power consumption point of view.

Is there any mobile API, current or planned, that actually exposes the 'overbright' color support of AR10? In particular, OpenGL ES 1.0 doesn't.
 
I think it's all too early right now. These are baby steps. Handheld gaming will continue to be dominated by custom made handheld game machines for the forseeable future (e.g. GBA, PSP) Most of these mobile chips are slated to go into PDAs and Phones. They make nice demos, but I don't expect a gaming revolution on NGage or PocketPC anytime soon. The devices are far too expensive, battery draining, and bulky compared to their "made for gaming only" console-like cousins.

Average PDA or PDA+Phone costs more than a PS2/Xbox.
 
DemoCoder,

Of course, the new standard to beat will be PSP.

Due to real superiority what the design concerns or better marketing/distribution? So far the only other advantage I could see what the PSP concerns, was dx8x type of HOS support, yet after the recent "Curves" announcement from IMG I'm not so sure that particular advantage still exists.

MBX would be a waste in a PDA/Phone if it isn't put into something like an NGage or a device that has some kind of adapter to use a gamepad.

MBX doesn't come in one variation only.

http://www.powervr.com/Products/Graphics/MBXLite/index.asp
http://www.powervr.com/Products/Graphics/MBX/index.asp
http://www.powervr.com/Products/Graphics/MBXPro/index.asp

With or w/o VGP, depending on needs.



arjan,

Is there any mobile API, current or planned, that actually exposes the 'overbright' color support of AR10? In particular, OpenGL ES 1.0 doesn't.

For OGL ES at least they could use proprietary extensions or not?

Uttar,

Say I haven't told you so :p

Chalnoth,

Regardless, I don't see why this architecture is bad for handhelds. The performance and power consumption numbers will be the most important, though, and those are as yet unknown.

It's far from being something exeptional either and that regardless from power consumption and performance (which inevitably is going to be lower than the competition). Especially if I look back at the "programmability" and "photorealistic" claims of early marketing claims.
 
By the way, look at this pdf for the GoForce 3000/4000:
http://www.nvidia.com/object/IO_11295.html

Notice the 640kb of embedded memory (320kb for the 3000).

Since the GDC document doesn't appear to touch on any of the hardware specifications, it seems reasonably likely that the GoForce3D will also include embedded memory (which would make the limited framebuffer and texture support make sense). This could make a significant difference in power consumption and performance.
 
This could make a significant difference in power consumption and performance.

Yes it could, yet not to the degree you'd be hoping for. Especially considering the few aces that the competition hasn't unveiled yet.
 
Ailuros said:
DemoCoder,

Of course, the new standard to beat will be PSP.

Due to real superiority what the design concerns or better marketing/distribution? So far the only other advantage I could see what the PSP concerns, was dx8x type of HOS support, yet after the recent "Curves" announcement from IMG I'm not so sure that particular advantage still exists.

No, due to the fact that the PSP, like the GBA, is ergnomically engineered to be a handheld game device, but the majority of these mobile 3D chips are going into cell phones and PDAs. Stick an MBX into a device custom made like a GBA or PSP in terms of "controller" and ergomomics, and I'd agree. On the other front, the content available for the PSP is likely to be alot better. We all saw how Ngage turned out.
 
Stick an MBX into a device custom made like a GBA or PSP in terms of "controller" and ergomomics, and I'd agree.

Well it depends on what semis want to do actually with a high end MBX variation. What I meant to say is that it doesn't seem to lackluster in capabilities against PSP.

On the other front, the content available for the PSP is likely to be alot better.

Didn't I just ask if your claim about PSP being the new standard to beat is based on better marketing/distribution? Better content is in my book part of a better marketing strategy and part of why SONY in general always had such a high level of success in the console market.

We all saw how Ngage turned out.

Was the flop of the NGage purely due to content? Funny only half a year ago there had been serious doubts that for PDA/mobile devices 3D acceleration is actually necessary. No I don't mean you, just the general feeling I got from various conversation here and elsewhere. I know what could come next in reply, but isn't content actually directly related to a devices actual abilities?

Colour me biased but the few demonstration demos for PSP didn't exactly knock me out of my socks either, yet I am confident that SONY will have the better content after all.
 
Kristof said:
IMHO raises a question :

The transform unit takes vertex information (X, Y, Z, W plus color
and/or texture attributes), applies a user defined transform to
calculate screen space coordinates for each triangle which is then
sent to the rasterizer unit to draw the given triangle.

Geometry transform engine (floating point and fixed point)

Now I wonder why do they mention transform but not lighting ?

Downloading SDK to see if it has more info...

K-

have you found anything yet on that matter? a transform to screen space could mean lots of things, nevertheless your question stands valid - if they did lighting as well they couldn't do with just a to-screen-space transform (illumination in screen space is plainly incorrect for some types of lightsources, and IIRC is against the openGL (es?) canon). one could ponder on the possibilities of illumination in clip space, but that'd be tricky in itself (i.e. thanks but no)
 
Nope, no more info at the moment but I think its odd for a Marketing document to not specify if it can do lighting ...
 
Back
Top