PowerVR Series 5 to debut in 2003 using 0.13u
- Thread starter PC-Engine
- Start date
arjan de lumens
Veteran
Just wondering - what level of programmability will this thing have - DX8, DX9, OpenGL 2.0 or something else entirely?
If DX8, it's about 2 years too late to be cutting edge; it may have a chance only if it beats R9000 and Xabre soundly on price/performance ratio. If DX9+, it will be interesting to see if it handles features such as displacement mapping and multiple render targets (both of which would seem to me to be rather problematic to do efficiently in a tiler)
If DX8, it's about 2 years too late to be cutting edge; it may have a chance only if it beats R9000 and Xabre soundly on price/performance ratio. If DX9+, it will be interesting to see if it handles features such as displacement mapping and multiple render targets (both of which would seem to me to be rather problematic to do efficiently in a tiler)
arjan de lumens
Veteran
JohnH said:
OK.
The problem with N-patches, any other HOS, displacement mapping, is that they, from one input primitive (and a texture, in case of displacement mapping), produce lots and lots of small triangles. Now, hwo do you bin them?
- Directly as higher-order primitives? Then you need to find the set of tiles touched by each primitive and later on tessellate it once for each tile.
- Or as completed, tessellated triangles? Now you need the binning space for perhaps 20-1000 triangles for each incoming primitive, eating lots and lots of memory and bandwidth.
And for the multiple render targets, do you:
- keep 1 tile buffer on-chip for each render target (costs hardware)
- or run the pixel shader program with the multiple targets once for each render target (destroys efficiency)?
arjan de lumens said:
Either of these could be done, but probably for ease I'd guess on the latter. I don't think the bin size will be much of an issue.
Why not just divide the tile? If MRT aren't being used, if they are then dive the tile - this would increase the size of the pointer lists.
Wavey,
Is this in any way relevant?
http://appft1.uspto.gov/netacgi/nph....&OS=DN/20020039100&RS=DN/20020039100
edit: I give up the link is too big probably to show up properly....
Is this in any way relevant?
http://appft1.uspto.gov/netacgi/nph....&OS=DN/20020039100&RS=DN/20020039100
edit: I give up the link is too big probably to show up properly....
Think Dave just about summed it up on HOS. Basically the mistake every one keeps making is assuming that binning space is an issue.
For MRT's, well there's already an on onchip tile buffer, why wouldn't you use it ? Actually TBR is better suited to MRT's as its able do dish out longer bursts to targets that aren't necessarily local to each other, means fewer page breaks hence better performance. +...
John.
For MRT's, well there's already an on onchip tile buffer, why wouldn't you use it ? Actually TBR is better suited to MRT's as its able do dish out longer bursts to targets that aren't necessarily local to each other, means fewer page breaks hence better performance. +...
John.
I have no idea who you are, so everytime I see you post in a thread I feel.. absolutely nothing at all
If you really want to be sympathetic with me about something then why not pick something that actually matters to me a great deal, like maybe the fact that Newcastle are yet to win a game in the Champions League
Joe DeFuria
Legend
Lol...who wants to bet that (assuming Series5 DOES make it to the PC next year, which is a big assumption IMO), that it will NOT be DX 9.1. (Whatever that is, anyway.
)JohnH said:
IMHO it would help when IMG would explain binning and binning space to the users too ( I suppose You do this with developers already to lessen the reservation against TBR's there ). IMHO this would help IMG to overcome the impression that TBR have an big problem with high polygon-counts and the storage of polygons for binning. Without this explanation You will receive a lot of reservation when You introduce the next chip. See old threads in this forum for more info.
