On 8/3/06, Diego Sáenz <[EMAIL PROTECTED]> wrote:
El Thu, 3 Aug 2006 09:24:14 -0400
"Timothy Miller" <[EMAIL PROTECTED]> escribio:
> On 8/3/06, Nicolas Boulay <[EMAIL PROTECTED]> wrote:
> > That's the first step. After you have to deal with the fact : is it
> > more important to have a dedicated controler that could be tricky to
> > use, or general processing unit less specialised but more versatil so
> > easier to programm ?
> >
> > For example, you could use the coprocesseur interface of the LEON to
> > add some specific instruction. If a 32 cpu is to big, 8 bits one could
> > do the job. Some ASM programm still exist for it.
>
> What I think we need is something very small and not fancy that fits
> into the 3S4000 and takes up about as much space as the VGA controller
> would have anyhow. We could try to imitate an existing instruction
> set, but I think that might be a handicap.
>
> Also, as I learned in the Advanced Computer Architecture course I just
> took last quarter, it's bad to design around an instruction set.
> Let's design an architecture, and then make an instruction set that
> implements it most trivially.
I think that vga controler must wait before other parts so it can use that
parts.
For example:
It can use bitblt to copy font characters and emulate text modes at boot.
This may or may not be helpful. The font will natively be in a format
that the GPU can't understand, so we'd have to convert that too.
There might be some advantages to using the GPU to stretch, but we
could just as well do that in the nanocontroller. Remember that for
VGA, performance is a non-issue. If we get 10Hz on the text console,
we'll consider ourselves spoiled.
The set mode BIOS rutine must load font on mem and prepare other things(mem
zones for char cache 4kb, real framebuffer, etc), every time a char is writed
to the card a bitblt copy the right char bitmap to the real framebuffer(it can
be easy if we chose the right address for the mem zones)
We need to be able to handle font changes that cause every instance of
the glyphs on the screen to change. I anticipate no problem with the
nanocontroller just dumbly regenerating the whole framebuffer every
loop.
My "logic" roadmap of OGC developement over OGD1(even before OGD1)
1 Basic framebuffer, not botable, usable only as 2nd(test/auxiliar) card
(video controler[DONE], mem controler, pci minimal controler, basic driver)
2 Accelerated framebuffer, not botable
(Basic 3D part for 2D aceleration bit blit ... basic accelerated driver)
3 Accelerated framebuffer, VGA cappable, botable
(VGA controller using implemmented fearures, BIOS, ...)
I was thinking that VGA might come before acceleration. In part
because it's simpler.
4 Accelerated, 3D, video, botable, ...
("avanced" 3D, Video features(scale, yuv ...)do we have that?, others)
There's really very little advantage to separating 2D and 3D as
separate things to be done. Our engine is designed primarily to do
3D, with some additional features to support 2D. Being optimized,
therefore, for 3D, there are some 2D operations that will be somewhat
less efficient, at least to set up. For instance, a bitblt is a
special case of a texture operation, meaning that a number of "extra"
registers need to be configured properly to get the right behavior.
This has me thinking. The nanocontroller idea becomes more appealing
if we can find other uses for it. For instance, I had anticipated
doing the high-level control of the DMA engine in Verilog. If we were
to use this same nanocontroller for both VGA and DMA, it starts to
really justify its existence.
For VGA, it spins on converting the framebuffer (and handles VGA reg
accesses via interrupts).
For DMA, it sends "read/write N words starting at address X in host
memory into a fifo" and also manages filling/emptying that fifo. This
way, we could add some 2D accelerators that compute the extra register
data, saving bus bandwidth. The huge question, then, is if we can get
the controller to be fast enough. If not, it's not worth it.
5 More test, more test, more test
I think too that the diferent plataform drivers must be based in a reference
driver library, so we can reuse a lot of code.
Definitely. Andy and I will be supplying a lot of this code. We can
provide C macros and functions that implement basic operations that
others can just drop into place. No messing with a spec if you don't
want to read it; just call the function. Then the spec is useful more
for finding ways to optimize.
And i have doubts about the size of all the things we must put in BIOS ROM.
Some of it will have to be programmatic. That is, we will not have
separate pre-compiled video programs for every mode; the BIOS code
will contain the algorithm to compute that. Also, we can have a
bigger PROM.
This is like i see it so may be i am fully wrong
You make some good points.
Diego.
PD:Excuse my bad english
I guarantee that your English is much better than my <insert any language>. :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
