Hi Rohit,

Rohit (@.) on 2/2/11 wrote:
---------------------------
>Nicolas Capens (nicolas.capens@gmail.com) on 2/2/11 wrote:
>---------------------------
>>And I've tested 3DMark06 with SwiftShader while forcing the mipmap LOD down one
>>level (which is equivalent to reducing the texture bandwidth by a factor 4), and
>>the SM3.0 score went from 250 to 249. Yes, due to some statistical variance the
>>score was actually lower. If texture bandwidth was of great significance, you'd expect a much higher score.
>
>You do realize that 3DMark is a synthetic bench, and hence largely un-representative of real work loads?

The purpose of a benchmark application is to be as representative as possible of real workloads. It can miss the mark (pun unintended) but not by a lot. The techniques used in 3DMark have consistenly proven to be used in games released in the following years. 3DMark is used by pretty much every review site and if it was "largely un-representative" that would have had serious consequences for its credibility. It succeeds where other benchmark tools have failed.

Besides, you're not giving me any kind of indication what exactly would be un-representative. Don't just handwave. Be specific.

Or to get even more to the point, what kind of proof do you have that texture bandwidth for non-synthetic applications is significant enough that it would demand dedicated texture decompression hardware for software rendering to be viable?

>>And for applications that don't use it, any additional dedicated hardware is a waste
>>of silicon. To efficiently support micropolygons, ray-tracing, Reyes, a multitude
>>of GPGPU applications, etc. they need to make rasterization and texture sampling
>>programmable. Software developers don't want a fixed architecture that can only be used in one way.
>
>A modern rasterizer isn't much of a waste of silicon, even if you don't use it.

Rasterizers need to be able to compute as many sample coverage results per cycle as the ROPs can handle. This does take noticable die space: http://www.geeks3d.com/20080912/nvidias-gt200-inside-a-parallel-processor/

During GPGPU tasks it's worthless silicon, and when being shader limited it's underutilized. With tesselation, micropolygons, Reyes, ray-tracing etc. it would have to become more generic and bigger. So it's worth considering replacing it with shader cores to ensure that any workload results in high utilization.

>>aimed at serious gaming. As the CPU performance continues to increase exponentially,
>>and things like gather/scatter can make a drastic difference in graphics efficiency,
>>software rendering can satisfy more and more people's expectations, even if those
>>expectations themselves incease slowly.
>
>It won't. Games already use up a lot of CPU because they assume presence of a decent
>GPU. If you want to move rendering to pure sw, you have to cut into other things that make up a game's CPU time.

With an IGP every game is GPU limited. So you're better off replacing the IGP with CPU cores so the workload is balanced automatically.

>>800x600 at low detail. It's twice as fast as Microsoft WARP: http://msdn.microsoft.com/en-us/library/dd285359.aspx
>
>Pathetic.

Yet it outperforms the GMA X3500 and probably most other IGPs: http://www.reghardware.com/2007/12/05/review_asus_p5e_vm_hdmi/page3.html

>>It will. The only strengths the GPU has left are all components based on the ability
>>to load/store lots of data in parallel. The CPU cores already achieve higher GFLOPS
>>than the IGP, so gather/scatter unlocks that power for graphics applications. You
>>can either ditch the IGP to make things cheaper, or replace it with additional CPU
>>cores so you get a really powerful processor for any workload.
>>
>
>Texture filtering is still an OoM slower in sw, no matter how much scatter/gather you do.

You're forgetting one thing. With gather/scatter the entire CPU is capable of efficient texture sampling. So while it would still take several instructions to implement sampling, it's like having lots of samplers (but only when you need them), which operate at high frequency.

In comparison Intel's IGPs have a very low number of samplers, meaning you can easily get bottlenecked by them: http://www.techarp.com/showarticle.aspx?artno=98&pgno=10. Also note the limitations for anisotropic filtering and 64-bit and 128-bit sampling: http://software.intel.com/file/33239.

SwiftShader already outperforms the previous generations of IGPs and it's not even using AVX. So with AVX + FMA + gather/scatter it's going to outperform any IGP, even if they become more powerful too. Unlike the CPU they don't have anything to exceed Moore's Law.

Cheers,

Nicolas