On 05/30/2012 08:43 PM, [email protected] wrote:
On Wed, 30 May 2012 14:26:56 -0400, Timothy Normand Miller wrote:
Someone pointed out to me that integer ops don't have much utility in
GPUs. Memory may be in integer form, but ARGB in 8888 format, for
instance, would get converted to/from vec4 format (or our equivalent)
as part of the memory access. If we have no need for integer ops,
that would simplify the architecture. So can anyone make any
arguments as to why it would be strictly necessary to support integer
operations?
loop counters ?
compute array indices ?
helpful for crypto acceleration ?
(we're speaking about making an energy-efficient
system so if it means reusing it for other common
tasks, great)
just wondering.
When you introduce a programmable device, it won't be energy efficient
if it is used to task which it was not designed. Surely, I can emulate
an x86 on my 8bit AVR, but the efficiency is.... you know where :)
If you are trying to develop a new architecture, here is an idea:
- create specialized blocks for realizing tasks very effectively (in
means of time, power)
- allow these blocks to be connected in a user/programmer defined way
- allow to replicate blocks to increase performance
The realization of that might be a runtime reconfigurable FPGA like
structure.. OR if you are rather into hardware, the chip can bear a very
large number of these blocks of various complexity and computing power,
each of them be clock-gated so instead of dropping them out of the
design you just switch it off.
Beat the efficiency of that. (what none of these blocks could do is a
task for a processor core)
(Once I wanted to do an PhD in CS and such an architecture was a basis
of merging software and hardware together - whole apps would run in
hardware, having stdin/stdout piped from one to another, a | bash
operator would become a fifo and so..)
D.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
