I knew it wasn't our original idea, but I didn't remember the name of it. Basicly, current GPUs are nothing more than smart vector processors. I'm thinking that a design like the one I mentioned would allow the processor to be used for a GPU, or a CPU. Since we are dealing with embedded designs (like you mentioned) we don't have to worry about threading issues.
The think I love is that this design is extremely flexible. It would be very simple to allow a developer to modify it by adding or removing arithmetic units. Here is another weird plus. It seems to me, that a compiler could (if it knew enough about the underlying hardware) be created to translate from one revision of the processor to another. So, let's say that a driver for a revision of the chip that has two mov units would have optimized code. In the other example I gave, the code that was 15 instructions in length, could be split into a series of blocks, these blocks could then be resolved into the code that was 8 instructions in length. It's this idea of the modularization that I find so attractive. CPUs are too liner, and GPUs are not linear enough. If we could find the sweet spot in the middle we may be on to something. Timothy On 4/13/06, Timothy Miller <[EMAIL PROTECTED]> wrote: > On 4/13/06, Timothy Baldridge <[EMAIL PROTECTED]> wrote: > > On the discussion about GPUs for OGP: > > > > Here is an off the wall idea a friend and I were talking about a while > > back. I think that it would be of great use in a GPU. The idea is to > > create a "modularized" RISC processor. Here is a basic rundown: > > > > The CPU accepts 3 instructions: > > load > > store > > mov > > > > This reminds me of a design someone was calling "MISC". (Minimal > Instruction Set Computer) Basically, the only instructions were > "moves". If you want to perform some computation, you move the source > operands into special purpose registers and then move the result out > of its special purpose register. Results queue up, so you can pop > them out any time you like. I didn't go anywhere with this idea > because it makes context switches hell, but for an embedded design > with no interrupts, it would work fine. > > Before we get into implementation details, however, we really need to > figure out what our requirements are. Based on what little I know > about shaders, I don't know enough to decide between what you > describe, a stack architecture, a 3-operand load/store machine, a > 2-operand load/store, etc. > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
