Beyond3D's GT200 GPU and Architecture Analysis

http://www.anandtech.com/weblog/showpost.aspx?i=453 but I'm honestly not sure whether that's G80 or G92... (as for the 1.2B transistor count, I have some reasons to believe that's likely GT200b)

I agree, 128-bit GDDR5 + embedded memory is a much better approach in the PS4/XBox720 generation. The only thing I'm worried is the burst size for the CPU (I'm skeptical separate DDR3 would make sense) but heh. Of course, if you used Rambus memory then you might not get pad limited fast enough to justify using embedded memory...

Yeah, I've said it many times already but I'll repeat it yet again: being able to do triangle setup in the shader core for small triangles would be a huge deal. During the shadow pass, the shader core is just idle most of the time; this is absurd and highly suboptimal. Yes, you do need to beef up the rasterization hardware in consequence (needs to be hierarchical) but that's honestly not such a big deal AFAIK. I fully stand by my comment in the GT200 article about triangle setup & texture filtering/pixel blending, just haven't had the time to properly defend it yet - guess it'd probably be worth a new thread too!

Hmmm, very good point; I guess that would hardly be impossible to do in fixed-function hardware with that level of precision. Whether it would truly be desirable and worth the silicon cost is another question though, of course.

 

I seem to remember reading some comparisons of bandwidth/pin where Rambus held a very substantial advantage with their next-generation technology (that I wouldn't expect to be eliminated completely via GDDR5). However, I could be remembering wrong or have miscalculated; definitely worth a recheck on my part!

I did, and I'll have to humbly disagree. A couple of points:
- Triangle Setup can already be done in the shader core in the ATTILA and the 'shader' they use for it is public in one of their papers; it's nothing extraordinary.
- Passing several position-only triangles around is very cheap and quite a bit of logic from other subsystems can be reused for this purposed.
- It's not like the entire shader core had to be able to handle triangle setup; even just one or two clusters (or one SM per cluster) would already be very fast.
- As for texture filtering, it's not really about making things faster as much as it is about improving programmability. It could even be half-speed for a given datasize and that'd more than good enough.
- Same for ROP blending, but of course I agree that making it programmable is more complex there (although the difficulty shouldn't be overestimated; some NVIDIA patents handle it in a rather efficient way IMO).

Yes, but the reason isn't fundamentally all that different from why geometry shaders cannot be infinitely parallelized. Simply extending GS logic a bit might be able to do the trick... (although I'd have to think more about it to be certain)

 

Duh. However, ATTILA is afaik what influenced Intel to implement triangle setup in their shader core for their current SM3/SM4 IGP architecture. The only reason why I was mentioning it, anyway, is that it's the only source I've ever seen for an arithmetic shader-like 'triangle setup' program.

I am rather skeptical that it doesn't loosely fit the framework of the geometry shader. Of course, the geometry shader's peak rate is rather... unimpressive right now, but you can't get away from the fact that in the future it will progressively have to go incrementally faster. That same hardware could be partly shared for the data flow & synchronization of triangle setup (in fact, the two could possibly be merged into the same program).

Getting full programmability for free would be absurd, yes. However, point sampling and/or fetch4 is so far from optimal it's pretty funny. Okay, let's look at this another way: what do you need to do texture filtering in the shader core?
- The texture colors and the weights for each bilinear operation, for every colour.
- The number of bilinear operations to perform and the n-1 weights between them.

For an INT8 texture, the colors & weights are likely all being transmitted in 16-bit format (and converted by a 'free' converter somewhere). Note that I am assuming this (rather than FP32 for everything) in order to be pessimistic for my own estimates. Therefore, it should be possible with proper packing (ugh, I know) to transmit the colors in 2 cycles and the weights in 1 cycle. So 3 cycles total for bilinear, 6 cycles for trilinear. This isn't fundamentally different from how the same paths are reused for a 4xINT8 texture or a 2xFP16 texture IMO...

I'm not saying no new scheduling or routing logic would be required. Duh, of course it would. However, I think you are overestimating its size, and underestimating the logic it could save by always running certain modes in And much more importantly, I think history will prove you wrong...

I think I have a much better handle on that than you think I do... Furthermore, you strangely put HiZ and scanline rasterization into the equation; yes, those are things that are also hard to parallelize, but unlike triangle setup their computational requirements are massively different from the shader core. It's all about a large number of very small operations; and obviously doing that in 'software' would be pure madness: there's nothing to gain there.

On the other hand, while triangle setup is indeed hard to parallelize, the operations are much higher precision (in fact, the best arguement I've heard so far for not doing it in hardware is the shader core is that FP32 just isn't enough! Although I do wonder if that doesn't depend on the algorithm given that Intel seems to be doing it just fine...) and it looks much more like a classic shader program. So yes, it's hard to do, but the reward may very well be worth the initial R&D cost and the slight die size cost.

My point is really this: it will be necessary in the future to be able to parallelize it; it's just not fast enough otherwise for a huge 500mm² 40nm chip, you can't get around it. And once you did find an acceptable way to parallelize it, then simply adding more fixed-function hardware for the job would be very expensive and inefficient because (unlike HiZ or rasterization) those aren't just small and cheap operations at all. So like it or not, I don't see how you can get around having to do this within the next 2 years...

Where did I say it was easy? However, creating an highly efficient unified shader core isn't easy either, nor is a good redundancy mechanism. That doesn't mean you should give yourself the luxury of avoiding them until you're really really forced to; otherwise you'll just turn out the way of 3dfx.

I would be very surprised if neither IHV considered it very seriously for the DX11 generation anyway given this: http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233

I could definitely still be wrong here, and if I ever change opinion I'll gladly admit so, but I certainly don't think the arguements are anywhere near as clearcut as you make them out to be; of course, I'll also gladly admit that they're not anywhere near as clearcut as *I* originally made them out to be!

 

I'm vying for a slightly faster bus from the TU to the shader and the capability to transmit not just the 4 neighboring point samples in it but also the weights which had to be calculated anyway. Yes, it would take time/bandwidth to transmit that, so I'm not expecting it to go full-speed, at least not initially.

The goal isn't to replace the texture filtering hardware completely, but to complement it (improving software flexibility) and be able to eventually streamline it. If every texture was DXT1, the latter wouldn't make any sense, but that's obviously not the case and the TMU hardware does need to support a variety of formats quite fast indeed. Down the road, I'd rather see the TMU focus on the most common formats and let the shader core handle the rest; however, whether that makes sense is a complex performance discussion that is hard to have objectively without more raw data.

My expectation is that it's likely undesirable unless the batch size is substantially smaller for the pixel shader, which obviously has problems of its own. What might be interesting is allowing the pixel shader to do pure bilinear or trilinear filtering during 'idle cycles' where the texture filtering unit is busy doing advanced anisotropic filtering; but I would actually be very surprised if that was worth the effort or scheduling overhead.

Oh, I want end-to-end doubling too, my point just was that it wouldn't make any real sense to do HiZ/Rasterization/Compression in SW just to be able to increase the peak throughput. I'd rather 'just' have that fixed-function hardware be able of, I don't know, 4 triangles/clock on an ultra-high-end chip. Yes, it's hard to make it work, but as I said you just can't get away from that complexity in the long run.

However, I do agree that there are much worse first steps than what you just proposed there!

The point isn't that triangle setup should be able to go as fast as the shader core would let it; the point is that triangle setup should be able to go faster than it does today, and once you've got the necessary complex infrastructure to parallelize it, it seems rather absurd to just implement four times as many fixed-function triangle setup units. It would seem much more sensible to just offload it by then...

As for texture filtering, I'm not sure. My theory here is that you're just picking on everything Larrabee does in software in order to later claim I said Larrabee would be a disaster! You seem to forget you can employ a similar rick to MMX: full-speed INT32, double-speed INT16, quadruple-speed INT8. Yes, it does require you to have 32x32 multipliers instead of 27x27 multipliers, but it seems like RV770 is handling that horrible inefficiency just fine! *grins* I am more worried about the dataflow, but if Larrabee's engineers can't even get that critical part of the design right, then they really are hopeless.

Realistically though, one problem with this theory is that you can't filter a INT8 texture with INT8 hardware; that's just not legal, you need a lot more precision than that in the DX10/DX11 spec. I still think double-speed INT16 would be worth the trouble though...