No new Power VR card until 2003.

[CMcK]

From EE Times, http://www.eet.com/semi/news/OEG20021003S0016

Metcalfe said that Series-5 architecture would be based on a primary processing pipeline and a series of hardware accelerators that can be optionally switched in and out to render graphics.

As well as class-leading functionality, there will be some unique features enabled by tile-based rendering, said Metcalfe.

Anyone care to speculate what he means in the first paragraph?
Are we talking a variety of cores based on Series 5 tech or switching of units on the core itself when they are not required? Possibly a power saving feature with the notebook market in mind?

 

[alexsok]

Possibly a power saving feature with the notebook market in mind?

Very likely. The Mobile 9000 has a similar system (in regards to power saving techniques).

 

[antlers]

With tile-based rendering, doesn't this mean you have to defer execution of the pixel shaders as well? Does the card store up all the pixel shaders sent to it the same way it stores up polygons? Does that cause (or solve) any problems with multi-pass shaders?

 

[KimB]

If it's a deferred renderer, it will need to store the pixel shader programs as well. Otherwise it would have to run in immediate mode with pixel shaders enabled (This, btw, adds another reason why I don't think deferred renderers will every truly make it...).

As for multipass, I can't see any advantages other than ones that might occur with auto-multipass. With automatic multipass (utterly transparent to the program) exposed via an HLSL, or just any multipass where the software doesn't send vertex data twice, a deferred renderer would be more efficient. That is, since the deferred renderer attempts to cache the whole scene anyway, there is little problem with doing only one pass at a time (whereas an immediate-mode renderer would need to run a few hundred triangles through on pass 1, then switch to pass 2, then move onto the next few hundred, and so on).

 

[arjan de lumens]

I don't see why pixel shaders would cause any special problems in a tile-based renderer - you would just send along the pixel shader programs the way you would with any other render-state - most TBRs (at least PowerVR and gigapixel designs) already have optimizations in place for fast render-state changes. And execution of a pixel shader program shouldn't give TBRs in particular any additional problems that they do not already run into with plain old multitexturing.

 

[Dave Baumann]

Effectively it gives you unlimted pixel shader program lengths since multipass would occur at the tile level. The advantage there of course is that it could be faster - if you are multipassing to float buffers there will be a bandwidth penalty for IMR's, whereas the tile on DX9 TBR hardware is likely to be float (although with an IMR the length of time it could take to render a long shader will offset the bandwidth penalty somewhat).