Prev: Larrabee delayed: anyone know what's happening?
Next: Xeon 3460 SMT power consumption and performance
From: Terje Mathisen on 13 Dec 2009 16:07
Andy "Krazy" Glew wrote:
> Terje, you're the master of lookup tables. Can you see a way to make
> texture units generally useful?

No, not really.

I _would_ use them for interpolated lookup tables, for things like
really fast but limited-precision math functions.

Most of the texture stuff is, as you say, very much dedicated to one
particular task.

An additional problem is that they only work well for throughput
computing, since typical latency can be rather bad.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
From: Robert Myers on 13 Dec 2009 16:16
On Dec 13, 4:07 pm, Terje Mathisen <Terje.Mathi...(a)tmsw.no> wrote:
> Andy "Krazy" Glew wrote:
> > Terje, you're the master of lookup tables. Can you see a way to make
> > texture units generally useful?
>
> No, not really.
>
> I _would_ use them for interpolated lookup tables, for things like
> really fast but limited-precision math functions.
>
> Most of the texture stuff is, as you say, very much dedicated to one
> particular task.
>
> An additional problem is that they only work well for throughput
> computing, since typical latency can be rather bad.

We went through this lengthy discussion of hyperthreading. One of the
conclusions was that there wasn't much savings because the execution
units that were being maximally utilized didn't take up all that much
space, anyway. Does it matter all that much if texture units are
nothing but dead weight for some applications (so long as you can turn
them off completely)?

Robert.
From: "Andy "Krazy" Glew" on 14 Dec 2009 10:15
Terje Mathisen wrote:
> Andy "Krazy" Glew wrote:
>> Terje, you're the master of lookup tables. Can you see a way to make
>> texture units generally useful?
>
> No, not really.
>
> I _would_ use them for interpolated lookup tables, for things like
> really fast but limited-precision math functions.
>
> Most of the texture stuff is, as you say, very much dedicated to one
> particular task.
>
> An additional problem is that they only work well for throughput
> computing, since typical latency can be rather bad.

That, I can improve, if there is motivation. There are several factors
that give the long latency:

a) the typical I/O interface - memory mapped, PCIe, whatever. This is
not necessary. We could easily create a fast interface, e.g. by binding
them into the ISA, with a fast connection if warranted. And a slow
implementation in terms of something like the existing interface if not
warranted.

Please note: there is nothing or little special about an ISA interface
per se. The main advantage is that an ISA binding allows you to have the
option of spending the money to implement a fast aggressive interface,
or a slow low cost interface, without changing the interface to
software. There also are few other potential ISA advantages, such as
knowing exactly what sort of serialization is required.

b) The latency induced by the size`of the texrure mapping unit. This has
two aspects: the compute, and the cache. If the two could be separated...
First  |  Prev  | 
Pages: 1 2
Prev: Larrabee delayed: anyone know what's happening?
Next: Xeon 3460 SMT power consumption and performance