--- Rohit <[EMAIL PROTECTED]> wrote:
> > NO! All that the framebuffer offers is a linear
> > mapping to the Video RAM of the gfx card, which is
> one
> > of the salient features offered by VESA 2.0.
>
> Using your system RAM. Am I right? There is a series
> of questions to
> come now...
>
> 1. Does it map detected video RAM on to the system
> RAM?
> 2. In that case, total amount of video RAM would be
> limited to the RAM
> on board the graphics card?
>
(I dunno whether i should be moving this to the
linux-india-prog. list, but i'm kinda new around here,
and i dunno how far i can stretch things... :)
NO again! :) what basically VESA 2.0 gives u is a
pointer to Video RAM. In plain ol' real mode, its the
standard 0xA000. U can linearly access the pixels
depending on the bpp u are in. Like for 8-bit modes,
each pixel is represented by a single byte, and
whatever color u write to that byte is gonna be the
color on screen. In 16 bit modes, the color info for
each pixel is stored as 5:6:5 or some card dependant
config. where the nos. represent the no. of bits
allocated for R:G:B (red green blue). So there is NO
REAL RAM involved. FB means just that. The video RAM
of the Card is mapped on to a protected memory
address, to which u can refer as an array if u want,
and write pixels directly on to the screen, after
setting the required mode. the fb system also allows
for mode setting, as different cards have different
mode setting interfaces. If u've done some device
driver programming in Linux, u'll understand what
mapping device memory means. In case u have the kernel
source lying around, i think a bried explanation is
present in the Documentation/IO-mapping.txt or
something which sounds like that... :)
> > communication with the gfx card. It displays
> whatever
> > we write to it. This prevents us from using the
> > acceleration features that the card may provide -
> the
> > reason for it being slow.
>
> Right. You will tell me a couple of more things?
>
> What are the BURST transfer rates and if at all, how
> are these different
> from the sustained transfer rates when it comes to
> hardware
> communications?
> [It seems to me that burst rates are usually more
> than the sustained
> rates - my own third grade conclusion]
>
The transfer rates are as fast as the PCI/AGP/ISA bus
supports. The only optimisation possible here, is to
draw the current screen in a seperate mem buffer and
memcpy(using the system's ver. or u're own fancy ASM
routine, taking advantage of MMX, or SIMD, if
available) the screen on to the fb. This allows us to
take advantage of the burst transfer rates allowed by
the system. VRAM is generally considered slower than
normal RAM, thats why we first write to a buffer and
block transfer the whole thing. But i dunno if this is
implemented. I know XFree86 implements it in the
normal servers. They must be doing it in the fb code
too, i guess, or following the normal route, which is
writing a pixel at a time DIRECTLY to VRAM , becomes
tad slow. :)
> Infinite thanks Nikhil,
aw gee! 'nfinte welcomez! ;-)
Nikhil.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-----------------------------------------------------------------------
For more information on the LIH mailing list see:
http://lists.linux-india.org/lists/LIH
