Hi Xiaohan, We were working on it on our free time during the 2009-2010 period. Also we were shooting to have working shader nothing fancy. Redoing it now we would probably change the design and the target. I haven't tough about it for quite some time.
Regards, André 2012/5/28 Ma, Xiaohan <[email protected]>: > HI, Andre, > > Right, for most of rendering work on shaders, the current architecture is > good enough. But we may keep refining it since currently the 3D graphics > applications become more powerful than ever (complex shading, lighting and > hug-textures). We may use some of the popular gfx benchmarks in embedded > market to evaluate our architecture later. > > Glad to see your prompt replies anyway. > > Thanks, > Xiaohan > > > 2012/5/28 Andre Pouliot <[email protected]> >> >> 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)
