Timothy Normand Miller wrote: > On 9/4/07, Patrick McNamara <[EMAIL PROTECTED]> wrote: > >> How big a penalty are we going to take for memory reads and writes? >> Well, reads anyway? Are we still looking at perhaps a 20 clock delay in >> the 200Mhz domain for a read to return data? >> > > Much worse than that. The requests have to cross the bridge from the > XP10 to the 3S4000, through some other processing logic, through the > memory controller, and back. >
How much worse? My concern is that since we don't have a whole lot of scratch RAM to play with in the XP10, we are going to do a pretty sizable number of reads from main card memory. > >> You have to be able to look up the colors as you can change the color >> palette for text. Still limited to 16 colors of course, but just like >> 16 color graphics modes, you can adjust what those colors map to. >> > > Isn't that palette configured through I/O space? That's another thing > the nanocontroller is responsible for: storing those registers in > scratch space or whereever. > Yes, it is. The palette is 768 bytes (256 three byte entries). > >> From a memory access perspective would it be more efficient to draw one >> vertical row of each glyph in a row? If writes don't impose a real >> penalty or less of a penalty than reads, then probably not. But it is >> something to think about. >> > > Yes and no. There's so much other overhead, it probably doesn't matter much. > > Something occurs to me. We have these asynchronous things going on > here, where we make requests for reads and then get the data later. > The PCI controller causes this to happen when the host accesses > graphics memory. If someone were to make a request, through the same > set of fifos that the nanocontroller used, there'd be a race > condition. > > I think we don't need interrupts. I think we need to put subroutine > calls at appropriate places in the nanocontroller code to a routine > that polls for an outstanding PCI transaction and handles it. Is it a > problem that we'd impose significant delays (and may retries on the > PCI bus)? No more than already happens if you try to read the > framebuffer at the same time the video controller is reading a chunk. > > This would kill PCI bus throughput and/or really kill our update rate. The card has 16 bus clock cycles to be ready to handle data from the time the PCI master initiates a transfer. Assuming the nanocontroller does poll to see the transaction waiting in time then the card has to issue a retry and the PCI master has to give up the bus and wait for its next time slice. In this case, the card will be required to memorize the transaction and be ready to respond promptly if the master retries. This means we effectively get one bus transaction every 25 or so PCI clock cycles at best. This drops our throughput to around 1.2M reads or writes per second. That sounds like a bunch but unfortunately every read and write to VGA memory is a separate PCI transaction. It also means that every time a read or write is done to to VGA memory the PCI bus is held busy (but idle) for at least 16 cycles. The solution is to of course call the PCI check frequently enough that we can claim every PCI transaction. But, we also have to be ready to accept or transfer data within that same 16 clock window. Assuming a 200Mhz nanocontroller clock and a 33Mhz PCI clock we would have a total of 96 nanocontroller clock cycles in which to claim the transaction and and have data ready to send or be ready to receive. We run into a further problem since the PCI spec requires that if a target generally can't respond in time to a request that it memorize that request so that it can respond in the necessary window on the next call. This means that if we miss a PCI read transaction, we still have to get the data if possible. This could cause problems if we have other queue memory requests unless we have separate memory pipelines for PCI and VGA nanocontroller memory requests. We have to be able to determine whether a data value coming from a memory read is for a prior request by the VGA code or by the PCI code. >> I still haven't figured out how to do blinking text without doing this >> in a continuous loop yet. *sigh* Do we have any ability for the >> nanocontroller to tell time? At least by counting clock cycles or some >> such thing. Best would be able to have an time based interrupt, but >> that may require more hardware than we want to allocate. >> > > I was thinking we could have it actually read a register in the video > controller. :) > > > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
