Hi Rohit,

Rohit (@.) on 2/4/11 wrote:
---------------------------
>>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?
>
>Every single gpu hw vandor has them. From nv to ati to intel - gma to intel -lrb to img to vivante .....
>May be you know something all of them put together don't...

This has been discussed before. Texture compression is critical to reduce the VRAM storage requirement. That doesn't mean it's critical to reduce bandwidth.

There's more system RAM available, and a software renderer can intelligently decompress only the textures needed by the scene (and cache them for a little while) so the storage requirement isn't that high anyway.

>My point is that, you need dedicated hw in quite a few places to do graphics efficiently,
>not regarding texture bw only.

You're just handwaving, based on preconceptions (certain things still use dedicated hardware so you conclude it's always going to be necessary).

The trends point in a different direction. Fixed-function vertex processing. Gone. Fixed-function pixel processing. Gone. Dedicated vertex and pixel shader units. Gone.

I'm not suggesting GPUs should get rid of all remaining dedicated hardware right away. That's not going to work because the software wouldn't make optimal use of such a generic architecture right away (which is the problem Larrabee is facing). So in the dedicated GPU market things need to evolve slowly.

But for the market which only requires adequate graphics support, a CPU with gather/scatter would be efficient enough at graphics to make the IGP redundant.

>>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/
>>
>
>No, they just need to be able to do one triangle per clock. Now increasing to a few.

You're not getting it. You need to know which pixel samples are covered by the triangle before you can start shader processing. It could be one sample or it could be the entire screen. Modern GPUs process pixels in tiles so they need to know the coverage mask for these tiles. Since you can't write more fragments than what the ROPs support, you need the rasterizer to compute the coverage for at most the same amount.

What you're talking about is gradient setup, which indeed recently started to become able to process more than one triangle in parallel. Note though that setup is also either a waste of silicon or a bottleneck. Shader Model 4.0 allows up to 128 scalar interpolants, so it would be a waste to have hardware for this worst case. Instead GPUs support a lower number and just take multiple cycles if the shader requires more. But this means it can be a bottleneck when using small triangles.

So as the triangle size decreases it becomes more attractive to do these things in the shader units so the workload is dynamically balanced and it's neither a waste of silicon nor a bottleneck.

>>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.
>
>Actually, if you want to get rid of rasterizer, I'd suggest adding hw to accelerate
>spatial binning. A lot of non-graphics algorithms could use it.

It looks like that's already efficient using shaders: http://sa08.idav.ucdavis.edu/oat-binning.pdf. I haven't looked at it in detail though.

Anyway, yes, I think there's some potential for new operations which are made available to all software by including them as shader instructions.

>IMO, there's no point in sacrificing throughput and/or efficiency at the altar
>of utilization needlessly. Of course, it makes sense to increase utilization when
>it leads to more throughput or more efficiency.

Certainly. CPUs also evolve in the direction of GPUs. Neither ILP, DLP or TLP offer an optimal increase in throughput. So it's going to remain a balancing act.

>>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.
>>
>
>With a crap IGP, all games are IGP limited. So you are better off replacing the
>crap IGP with a decent IGP so that you have a balanced system.

Not everyone is interested in serious gaming. So they don't want to spend extra money on a faster IGP just for the same of having a balanced system. A CPU with gather/scatter is very interesting for them as it costs less, makes the CPU faster overall, and can still offer adequate graphics when needed.

>>Yet it outperforms the GMA X3500 and probably most other IGPs:
>
>Outperforming GMA3500 (with a quad core nehalem?) is NOT an achievement. The comparison
>is even more absurd when you consider the power and cost of the cpu it will take
>to outperform it as well. I would be willing to wager it would lose to an amd fusion/ion class gpu.

It's an achievement because previously people thought it was impossible for the CPU to outperform *any* dedicated graphics hardware using software rendering. Also, it's not yet using AVX let alone gather/scatter. With it, it would outperform more recent IGPs as well, even at a modest clock rate to have an acceptable power consumption.

Cheers,

Nicolas