On 9/6/07, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> * Looking at the inner loop of draw_glyph, it doesn't clearly favour
> register-like IO over memory-like IO. I ended up translating the
> write_io statements to simple move instructions (rather than
> computed values), except if we unroll the loop, in which case the
> address writes can be combined with addition of constants 0 to 7.
It's true. If we were to unroll the loop, we would probably AND with
constants (1, 2, 4, 8...), and for each, there would be a branch based
on whether or not the target register is zero. Something like:
andi #1, r3, r4
bnz l1
store r5,[write_data] ; in delay slot, push foreground color
store r6,[write_data] ; get background color
l1: ....
Actually, if the store is the trigger, that wouldn't work, so we'd use
a reg-to-reg move instruction and then write that to the I/O port.
You get the idea.
>
> * I think it's worth considering if we can do context switching
> without too much overhead. From the discussion between Patrick and
> Tim, I understand interrupts are not strictly needed, but they may
> reduce PCI bus traffic.
I'm just worried about the race conditions. In fact, I know they'll
be a problem. We really don't want to give the nanocontroller a
separate pipe to memory. So if we have pending reads, then data will
come back out of order.
>
> (One last observation: VGA code is embarrassingly parallel, unless
> memory access is the real bottleneck. If we were to add an interrupt
> context, then I think we could almost as easily have 2 or 4 symmetric
> contexts (threads) instead. I'm just pointing it out for now, since
> dealing with resource sharing may however prevent us from exploiting the
> parallelism, and I don't know if this is any useful in 3D mode.)
I had considered that idea but then rejected it when I considered
certain cases of the nanocontroller processing DMA command packets.
There, we're only doing one thing (decoding commands), and we need the
throughput to be efficient.
--
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)
