IMR "Wall" Limits V PVR

PRman usually works with lots of polys per pixel, bucket rendering does not seem to be a problem for them.

 

Doom at one frame every 10 minutes wouldn't be too exciting.

 

Wether its realtime or not they still want it to be as fast as possible.

 

I dont want to use "if" but with a good 128bits 250MHz DDR (8GB/s) DR card we probably could have a excellent framerate without a big price. Probably something around $150. How much cost a Radeon 8500LE? Now imagine it using DR.

The HyperZ and other techniques will give probably no more than an aditional 20% of framerate.

 

Pacal,

here in the states we can get the OEM vers for a touch over $100. But is lower clocked mostly likey. At around $130 we get fully retial versions of LEs.

 

Heh, I know you don't want to use "If" but you basically did, "What IF we had a DR with ..." so really the question Tino asked hasn't been answered. We know about the great advantages DRs have but the question Tino asked is When?

 

Right, but wouldnt the overhead costs for a defered render become prohibative?
I mean the sorting of polys (for the sole purpose of not having to draw them later) is important NOW, because we have relatively low geometry and lots of texture layers. But with enough polys, you dont need textures - so then, theoretically, wouldnt a defrered renderer kinda suck?

 

Tiling is only meant to localize framebuffer access to the point where you can finish rendering a pixel without needing to store any intermediary values in the external framebuffer ... handy if you want to have lots of storage per pixel. As long as it doesnt inrease complexity and/or bandwith for other parts of the pipeline its a net win. Which at a high number of polygons per pixel basically boils down to the question wether you will be able to tile polygons without actually running them through the vertex shader. If you can then IMO with a big enough tile size its a net win, if not not.

 

I just found this thread accidentally while looking for something else, I realised its old but I just had to comment on this quote:

Wether DC was better looking then the best IMR system at that time (it was the best looking console, arguably even after PS2 was released) isn't really important here. The point is that developers are programing to IMR's and that is limiting how effective TBR can be. To see this simply look at some of the DC game, did you ever see anything even approaching Shenmue that could run at 30fps on a Neon 250 (basically the chip in Dreamcast)? Nope because it could only be acheived when the devs made the game with a TBR in mind instead of with a IMR in mind. We all talk about how TBR can have performance problems in some games because devs make their games as if IMR is the only rendering technique out there, well what sort of performance problems with a IMR have if all games were made as if TBR was the only method of rendering out their?.. big problems is the answer.

 

As said by many people in this thread, the popularity of TBR depends on people designing games for TBR, which is too high a barrier to entry if TBR is only moderately more cost-efficient than IMR. Thus, no matter how good it is, TBR will never become popular unless IMR hits the long-predicted "Wall". Judging by the Radeon9700's performance, this is not happening any time soon.

 

Blending Complexity

The real advantage of a TBR may not be opaque depth complexity, like a early Z system can assist with, but blending complexity, that early z only eliminates some of ( let's say half of blended pixels are occluded ).

Blending complexity goes up as developers start to use more trees ( blend the leaves b/c alpha test & MSAA don't look good ), grass, particle systems ( waterfalls, explosions, weather effects, blood sprays ).

It also goes up as developers do lighting that can't be expressed in a single pass. For instance, stencil shadow volumes require each light to be its own pass. Color shadow volumes don't, but not many people are using these yet.

Of course, doing particle systems, trees and stencil volumes tend to be very simple pixel shaders ( or no shader at all ), and IMR vendors are beginning to accelerate simple cases by fill rate - ie r300 only does 8 pix/clock when only 1 texture or z/stencil only.

I think IMRs will continue to dominate, partially because of history, and partially because so far, people have used tilers as a way of making things cheaper, rather than the way to make things that much faster. I think Gigapixel would have changed this.

 

I don't think games need to be designed for TBR before TBR can become popular. All that's needed is a more upto date card then Kyro II was and the popoluarity will come. Certainly to get the most out of TBR games should be designed for it, but you certainly don't need to design games for TBR to already see a large performance advantage spec for spec. As for only moderately more cost efficient, well Kyro II was a cheaper chip to produce then Geforce 2 MX and outperformed it easily, that's more then moderately more cost efficient IMO. As for the "wall".. that's a tough one, it'll take allot of thought and possibly a crystal ball to even try to answer that.. we'll just have to wait and see.

 

Well, after only reading the first post in this thread (yeah, could be a mistake, I know), I have to put my own two cents in.

Quite simply, I believe that deferred renderers will hit a technological wall long before IMR's.

The reason should be obvious. For deferred rendering, the TBR needs to cache the entire scene before rasterization. This brings along with it a host of problems.

First among these is memory usage. The deferred renderer must set aside an amount of memory that is large enough for the most complex scene that is ever rendered. This means a large exepense in video memory that largely goes unused.

You also need double-buffering in the scene buffer for the sorting and rasterization to go on at the same time, making for even more memory usage.

Since buffer overruns are inevitable, those also present pretty major problems. I believe the Kyro series handles the issue by going ahead and writing a z-buffer in external video memory to combine two separately-rendered deferred frames. For optimal performance, this z-buffer must always be allocated, which results in more unused memory space.

And then comes bandwidth. As triangle counts increase and start approaching the micro polygon stage, not only will the Kyro need more memory size than a deffered renderer, it will also need quite a lot more memory bandwidth. The worst-case scenario here comes for long and thin polygons, such as those seen in highly-tesellated pillars or pipes.

Of course, you cannot forget pixel shader. While vertex shading is, more or less, trivial to implement on a TBR, pixel shading is not. In particular, those fragment programs need to be stored along with everything else in the scene buffer, as well as the increasing amounts of data that are being passed from the vertex shaders to the pixel shaders.

Another way to look at this is simply that while an IMR will only have to store many things once, or perhaps not at all (just send them over AGP every frame), the deferred renderer will need to store extra copies of many things.

Granted, this doesn't mean that the idea of deferred rendering is totally useless, it's just that it starts to lose its luster as polycounts increase. Limited implementations that don't even attempt to always render in a deferred manner may be useful.

 

No there is not ‘must’ it is optimal for it to be cached, but that doesn’t mean it ‘must’ store it all.

Not entirely you don’t.

 

But chalnoth, being as a DR does not need the high speed exotic ram that IMr's use, memory space on a DR is (or should be) quite cheap. So your argument about storage space is kinda moot.

 

No, it's not. Even though size becomes a problem before bandwidth, the scene buffer will suck up more bandwidth than the frame and z-buffers as polycounts continue to increase.

 

As I said, a design that does not attempt to always store the entire scene every frame wouldn't be bad. The main reason is simply because if you do attempt to store all scene data every frame, if a few frames come along that exceed that buffer (high-action scenes), fillrate will take a nosedive.

Why wouldn't you need double-buffering to ensure that both the binning/sorting portion of processing can be done at the same time as rasterization?

 

Scene storage is only as important as AGP (or whatever other interface there is) is fast. How much data can you send to a card 60 times a frame? Because if you aren't sending it you are saving it in the previous video memory. What can you puch accross an AGP bus right now, 2 GB/sec? that's only around 60 MB totally saturated at 30 fps. I'd be surprised if a game uses half of that in the next few years.

As far as the wall goes, we are hitting it now. Has anyone noticed the price of video cards lately? And the emphasis is starting to lean towards features. You can render to a hardware tile and still be a IMR, as we've seen in some recent product, but without scene capturing you can't realize all the benifits, the biggest of which being you only have to handle any given tile of memory once.

 

Not true in the least. There's a lot of scene data (pre-transform) that's already stored in video memory today, and more in the future. Not all data is transferred over AGP every frame. Additionally, data going into the transform pipeline is not necessarily the same as data coming out from it.

 

Yep.
For example N-patches can increase the data size considerably.