Hi Xiaohan, 2012/5/28 Ma, Xiaohan <[email protected]>: > Hi, Andre, > > Thanks for your quick reply. > > Why I asked Energy-efficient GPU design since energy-aware architecture > might be what we want to pursue in the future.
I understand and since where I see our design going and be interesting would be the embedded market first(fpga first probably) > >>> Each step of the pipeline have it's own thread. For example for a >>> pipeline with a depth of 8 you would have more than 8 program running. > > But still some of the threads need to wait for other threads if there's data > dependency. Can't see the benefits here. > For shader program the data dependency is low. That's why there is also more than 8 thread, if one lock and wait for some data you can still use the pipeline at 100% efficiency. You don't have an empty time slot some other program use it. >>> The 32 thread could be controlled by 8 different program. > > How to handle control dependencies (or right now we just use ARM-like > conditional execution)? There's some capacity for control but the instruction set was tough to reduce the need for control. Not a lot of branch. There was some instruction defined to find the max or min between two value and store that value without a need for a register with flag in it. A few other stuff like that. It was mostly geared toward executing a program with no branch. > > Thanks, > Xiaohan > Not a problem ;) I do have to get that stuff out of my head André > > 2012/5/28 Andre Pouliot <[email protected]> >> >> Hi, >> it's more a traditional GPGPU design with some twist. The basic design >> is a scalar engine. Multiple scalar engine are controlled via an >> instruction decoder pipeline that control multiple scalar engine. Each >> step of the pipeline have it's own thread. For example for a pipeline >> with a depth of 8 you would have more than 8 program running. This >> prevent pipeline flush or stall because of data dependency. Each >> scalar engine is running it's own fragment. For 4 scalar engine with a >> pipeline depth of 8 you would run at the same time 32 thread and 4xN >> waiting, N being the program in queue waiting for a time slot in the >> round robin. The 32 thread could be controlled by 8 different program. >> >> If I remember right we were also talking about network on chip for >> scalability. >> >> Kenneth and me had some thing that are well spec out in a document. >> That doc need to be reorganized, it's was quite a mess at the time, I >> didn't know how to do a good spec document. Still learning how. Also >> some stuff was still in discussion. We did discuss during many hour >> some of the different option and breaking them. >> >> For energy efficiency I don't remember if we specified stuff for it, I >> would need to look at that document again. >> I'll try to try finding all the stuff again and make it accessible to >> people to look at. If someone want access to contribute, it will be a >> case by case basis. >> >> Regards, >> André >> >> 2012/5/28 Xiaohan Ma <[email protected]>: >> > Hi Tim >> > >> > Can you put more info about oga2 which Andre spec'd out? Is this a >> > traditional gpu design or energy-efficient ideas involved? >> > >> > Thanks >> > Xiaohan >> > >> > On May 27, 2012, at 2:19 PM, Timothy Normand Miller <[email protected]> >> > wrote: >> > >> >> I'm not trying to start an argument as to whether or not "intellectual >> >> property" is real. Maybe I'll blog about that some time. :) I >> >> nevertheless need to point out that being an employee of a State >> >> University of New York binds be in certain ways. >> >> >> >> http://research.binghamton.edu/Innovation/IntellectualProperty.php >> >> >> >> The bottom line for me is that I need to stay far away from any >> >> cash-flow that might occur. And regarding the IP owned by Traversal, >> >> Traversal is defunct, and the IP ownership fell back to me, Howard, >> >> and Andy. We're ready to transfer that, and some responsible >> >> facilitator(s) need(s) to take ownership (literal or figurative) and >> >> see where the project can leverage it. I think that there needs to >> >> still be some centralized entity who can relicense the IP without >> >> having to ask permission from 1000 contributors. >> >> >> >> So, on to what the OGP can do... >> >> >> >> ARM has cornered the market on energy-efficient CPUs. And ARM is >> >> entirely fabless. Maybe the OGP can corner the market on >> >> energy-efficient GPUs. The design would be dual-licensed GPL and >> >> commercial, where for production purposes, all GPL viral-like >> >> characteristics can be stripped in exchange for money, with the >> >> understanding that breaking binary compatibility with the open design >> >> (thereby potentially creating a closed architecture) will cost a LOT >> >> more to license. Our chosen facilitator would handle the money and >> >> fund whatever seems useful to fund. Mostly prototype hardware, >> >> reference designs, donations to other projects, etc. Linux Fund took >> >> over the Open Hardware Foundation, so we can use that. >> >> >> >> Of course, most companies that set out, a priori, to be fabless and >> >> license IP for profit tend to fail disastrously. But we're not trying >> >> to sustain a company on this. Indeed, the profit margin would have to >> >> be painfully small in order to be the least bit competitive anyhow. >> >> Our objective is to put a completely open GPU design out on the >> >> market, and that isn't necessarily profitable. >> >> >> >> So just for fun and science, let's see what we can design. André >> >> Pouliot and Kenneth Østby spec'd out a GPU shader engine design called >> >> OGA2. Let's start there. The first thing to do is my favorite part, >> >> which is to argue about architectural design decisions. Then we make >> >> a C-based prototype to determine functional efficiency, then we code >> >> it in Verilog and synthesize it for gate-level synthesis so we can >> >> judge energy efficiency. >> >> >> >> Think about leveraging the brainpower of the FOSS community to design >> >> a GPU that outperforms and is more energy-efficient than PowerVR. A >> >> compelling-enough design would get market penetration. Eventually, it >> >> would make its way from embedded systems into desktop systems and >> >> supercomputers (GPGPU, etc.), and we would all benefit from having an >> >> open architecture dominate in graphics. >> >> >> >> -- >> >> Timothy Normand Miller >> >> http://www.cse.ohio-state.edu/~millerti >> >> Open Graphics Project >> >> _______________________________________________ >> >> Open-graphics mailing list >> >> [email protected] >> >> http://lists.duskglow.com/mailman/listinfo/open-graphics >> >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >> > _______________________________________________ >> > Open-graphics mailing list >> > [email protected] >> > http://lists.duskglow.com/mailman/listinfo/open-graphics >> > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
