Timothy Normand Miller wrote: > On 9/4/07, Patrick McNamara <[EMAIL PROTECTED]> wrote: > > >>> Interesting. We only have 24 BRAMs on the device, and need some for >>> buffers, >>> but I think that this might work. >>> >> Also consider that the FPGA version only needs to be a proof of >> concept. If we only allow for two contexts, but get them working, then >> with the ASIC where we may not be as constrained on real estate then we >> can expand. >> > > This is dangerous thinking. Yes, when going to the ASIC, we'll have > to do a fair amount of retargetting, but we shouldn't change anything > higher-level. The main point of the FPGA is to fully test a design so > that we're vastly less likely to produce a terribly flawed ASIC. You > don't want to get something we can't sell. I've been through this > before, and it ain't pretty. > I wasn't suggesting shifts in architecture, that would definitely be bad. More I was suggesting something along the lines of replication of existing structures. For example, suppose in OGP we wanted 8 parallel fragment pipeline but only had room in the FPGA for four. If they are designed properly, we set up the control to support eight and then only put four in the FPGA. When we go to ASIC we add in the other four as duplicates of the originals. Obviously there is new logic that cannot be tested in the FPGA, but it should be minimal compared to something like going from a single pipeline to multiple. > >>> Hmm, that is a pretty big problem. Even just ignoring the context switch, >>> we are not going to ever need a multiply for PCI, right? >>> >> Not sure. I'm not even sure we have to have a multiply to do the VGA >> conversion routines, mainly because I haven't sat down to think real >> hard about what is necessary. The actual question is "Do we need >> variable multiplication?" If all the multiplication we need to do is by >> a fix amount, say the line number times screen width, then using a >> multiply instruction is probably slower than using shifts and adds. >> > > One of the advantages to our approach is that the physical resolution > can be different from what the VGA legacy stuff thinks it is. Since > we're translating from VGA text/pixels to pixels in our format (24-bit > TC), we can make the display whatever we want. But that means the > width is variable. > > I have been thinking about this as well. There are definitely advantages to going this route. We have to be careful though. We either need a nanocontroller capable of arbitrary scaling and bitblt or we need the graphics pipeline available to assist. Once you start talking about arbitrary scaling and stuff like that you get to the point where the nanocontroller isn't so "nano" anymore. > Note: Consider using look-up tables in the scratch memory for some of > the multiplies. > > > Look up tables are definitely you friend, but then we have to be able to store them somewhere and access them rapidly too.
Patrick M _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
