Gabriele Svelto (gabriele.svelto@gmail.com) on 10/1/10 wrote:
>
>The real problem is that as of today the design of a
>graphics driver is a barrier to entry in the GPU market
>as high - if not higher - than the design of the GPU
>itself. Intel learned this lesson the hard way with
>Larrabee.

Actually, I think that a large portion of the Larrabee
fiasco (and arguably at least a small portion of the
traditional Intel IGP fiasco too) was not just that doing
a graphics driver is hard - but that doing it for hardware
that isn't really designed for it is really doubly hard!

The thing is, the "impedance mismatch" between Larrabee
and DirectX or OpenGL was absolutely immense. The argument
was always that "you can fix it up in software", but it
really boils down to the fact that fixing problems like
that in software is (a) hard and (b) expensive.

Now, Larrabee was pretty extreme in this regard, but I
think even the regular Intel integrated graphics always
took too much of a "we'll cut corners in the hardware and
try to fix it up in the driver" approach.

Trust me, that kind of approach doesn't work. Every time
you need to "fix up" something in software because your
hardware doesn't really match the interface you are trying
to do very well, you're always going to introduce big new
complexities, and you're going to have not just bugs, but
also unexpected slowdowns from the extra abstractions and
indirections that you now have to introduce in the software
layer you do.

Personally, I think the last thing a GPU maker
should do is to aim for a general-purpose environment. I
think the whole GPGPU hype has been horribly bad, and the
only case it made sense for was for the vendors who were
able to drive the interfaces to match their hardware. So
for a while, it made sense for nVidia (and then for DX11
for AMD).

But for somebody like Intel, who was playing catch-up and
had a history of horrible driver problems, it was entirely
the wrong approach. Rather than do Larrabee, Intel should
have tried to do something that made the driver layer
thinner rather than thicker.

That's one of the things that I like seeing about SB. When
Intel started talking about making it more "CISCy" and
matching the actual API 1-to-1 with the instructions, I
was going "finally".

If Intel ever gets rock-solid drivers that perform well,
then they should perhaps start looking at GPGPU's. And I
very much say "perhaps", because I think that not only is
the whole GPGPU almost all hype, but I think that keeping
things as fixed-function as possible is also the way to
save power.

Sure, you'll need vertex/pixel shader programmability,
but I think you should aim for making the hardware do the
minimal amount of programmability required for OpenGL and
DX. The last thing you want is try to emulate Fermi and
do 100W+ graphics.

Intel just can't afford to take risks in graphics. They
need to get their act together first. And SB looks like
it's going in that kind of rough direction. I'm not a
graphics pipeline guy, so I may be missing something, but
in general it looks like somebody finally realized that
they need to do some impedance matching between their
hardware and what they need to export to software.

Linus