On 5/14/06, Ray Heasman <lists@mythral.org> wrote:

quoted text
> 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.

quoted text
>
> 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.

quoted text
> 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.

quoted text
> > I forget what the XP6 costs.
>
> A quick check on Arrow shows around  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 
> 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.

quoted text
> 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
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)