El Fri, 4 Aug 2006 10:04:12 -0400 "Timothy Miller" <[EMAIL PROTECTED]> escribio:
> On 8/3/06, Diego Sáenz <[EMAIL PROTECTED]> wrote:
> > El Thu, 3 Aug 2006 09:24:14 -0400
> > "Timothy Miller" <[EMAIL PROTECTED]> escribio:
[...]
> > 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.
It is usually a bitmap with a byte per row(8x8, 8x14 or 8x16 bits/pixels), but
we can convert to GPU pixel format in the set mode or load font call with the
OGC VGA ROM BIOS code
> 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.
I do not argue about the nanocontroller, i only suggest to reuse hardware
blocks and because that wait to the design of those blocks.
The nanocontroller can be used to program the rest of the hardware.
>
> > 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.
If the font change is a software one the screen regenerate can be in the font
change call, but surelly we will need that feature in a more hardware part.
>
> > 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.
I known. I only split it to not let the VGA part for the last.
> 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>.
> :)
pgp7KVybwScJa.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
