On 9/4/07, Patrick McNamara <[EMAIL PROTECTED]> wrote: > Obviously a concern. One of the problems to consider here is we don't > know how we are going to make VGA work. For example, how are we going > to handle reads from VGA memory?
We'll map part of the graphics memory into the lower address space. Note that this may require a slight mod to the PCI target so that we can alter the size of the aperture. And we'll have to store the original mapping somewhere so we can restore it later. Anyhow, so in text mode, there's no special hardware, so we'll just make reads and writes just pass through to the memory controller. In a VGA graphics mode that requires more smarts, the read or write raises an interrupt with the nanocontroller that then makes it own modified request to the memory system. > What about font bitmaps? Those are just stored in graphics memory. The text mode has a standard way to store those, and we'll just have the VGA controller use them to convert text to graphics. > There are a > lot of details surrounding the VGA pipeline that will need to be worked > out too. We don't want to get stuck in an architecture that can't > support our final needs either. I agree. But I suspect that rather than finding our architecture inadequate, we'll find it to be inefficient in some respects. We may add specialized instructions to make up for that. > > One thing about the BRAM. If we were to try to use it as the primary > > register file, I'm not sure we could double-pump it like we need to. > > Routing to/from the RAM may impose too much delay. One of the > > advantages of the current architecture is that it is effectively > > triple-ported. We can write one reg and read two at the same time. > > If we use the BRAM as you describe, we serialize it, making any > > instruction that requires access to three operands take 3 cycles. > > > That is definitely a concern. Allowing for only one read and write per > cycle would require addition of a second fetch stage in the pipeline. How would this help? I don't know what you mean. > > Did you mean DMA and VGA? We'd never be doing DMA at the same time as VGA. > > > > If you're referring to the fact that it has to handle VGA translation > > at the same time as intercepting PCI transactions so it can do the > > rest of the VGA stuff, then you're right. > > > Are you positive we won't be doing DMA at the same time as VGA > transactions? We won't be initiating DMA, but we may very well be the > target. But, yes, I was referring to PCI and VGA. I'm positive. Only the 3D GPU needs DMA. Upon starting X11, we'll have software load the DMA program. On exit from X11, we'll have it (or the kernel or whatever) reload the VGA program. We can only be in one graphics mode (well, one per head, but ignore that) at a time, so there's no issue with 640x480x16. And we also won't be in text mode and graphics mode at the same time. > My concern is that on interrupt or context switch, a multiply is needed > early on in the execution. Two independent threads of execution should > not have to know what the other was doing, especially since interrupts > cannot know what the other was doing. If the code has to check whether > a multiply is pending from another execution path before submitting its > own, this has a further impact on multiply performance. Only the interrupt needs to worry about this. That helps a bit. But as I say, if the multiplier is pipelined, then it's a non-issue. If it's not pipelined, then we will indeed have to query it before using it, unless we ensure that the ISR doesn't issue a multiply too early. -- 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)
