On 5/14/06, Ray Heasman <[EMAIL PROTECTED]> wrote:
I like this idea. It's not flashy, but we'll always have something that could go out the door if a customer appeared. Just looking at the features you are talking about adding in layers, I'm trying to imagine the kinds of things people want to do. I'm thinking mostly custom GUIs, with some scrolling, buttons being "pushed" in an out, but not a whole lot in the way of moving windows around. I think scrolling is probably very important. Here is an idea that has been done multiple times over the years. Why not have a simple display description language so we can avoid copying data? The idea is that if we have spare bandwidth on the DRAM (enough to compensate for frequent non-sequential address changes), then some sort of simple structure could be used to represent the screen display, and the RAM could be read out nonlinearly at display time. So, instead of drawing a frame by reading a linear buffer, and competing with that when blitting, we make the display counter hop around to find the data. This would allow really cheap scrolling and could replace blitting a lot of the time.
Doing remapping is okay if you're full-screen, because you can remap by scanline, but if we're going to remap at arbitrary points in the display, the memory row miss overhead will kill us. I think we're better off just moving the data. If the chip has a blt engine, it can do that in parallel with the CPU, so it won't have much impact. I remember messing with display lists on old 8-bit computers, but I just don't think it's worth it.
The display language could be as simple as "address, count" repeated over and over, meaning fetch "count" pixels from "address". That would allow scrolling any part of the the screen in any direction with relatively few updates to the display list, or would allow replacing one bitmap or framebuffer with another by changing some pointers.
So, basically, we just have a video control program that skips the video data pointer around arbitrarily and specifies arbitrary numbers of pixels before the next command. For each jump, you'd need two words in memory. Naturally, you'd store the display list in graphics memory, because it could get huge. As we add windows and things get denser, the program will get larger and more complex, taking up a significant amount of bandwidth itself. It could easily get to the point where we'd have been better off with just doing the copies. Oh, and I'm not even counting the row misses here.
If someone wanted an 1024x768 linear framebuffer, they could just have one entry in the display structure saying "addr = x, count = 786432", and treat address x as a linear framebuffer. I haven't looked at DRAM for quite some time. Would the latency on address change kill us?
Horribly. With these RAM chips we're using, a row miss will cost us at least 55ns. That's 11 cycles on the command bus or 22 cycles on the data bus.
> I forget what the XP6 costs. A quick check on Arrow shows around $30 in very small quantities. > Perhaps someone here remembers. It's > not very expensive. But what would be the demand for a card buildable > on this? I'm not sure about desktop systems if it's just 2D and based on a $30 FPGA. I'm not sure how much the final card would cost. One "special" feature could be enough of a differentiator, if I knew what it was. :-P
As you say, that would be the critical factor.
Maybe as a PC104 module? Like this? : http://pc104.winsystems.com/products/pc104/pcmfpvga.html
Isn't PC104 really horribly slow? Still... useful for small embedded systems. On the other hand, the other gentleman made the point that we're talking about high-end embedded. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
