Меню

Фреймбуфер видеокарты что это



Настройка фреймбуфера для видеокарты NVIDIA (linux framebuffer xfree86 video driver console)

Ключевые слова: linux, framebuffer, xfree86, video, driver, console, (найти похожие документы)

From: alex k
Newsgroups: forum.opennet.ru
Date: Mon, 17 Jun 2003 13:01:37 +0000 (UTC)
Subject: Настройка фреймбуфера для видеокарты NVIDIA

Настройка фреймбуфера для видеокарты NVIDIA

Сразу оговорюсь, что не буду писать о всех плюсах и минусах
использования framebuffer. Только о нескольких. Просто при
редактировании программ, конфигов, отладке и т.п. для меня самый
главный плюс, который перевешивает все — это большой размер консоли
(например: 100×37). Но, к сожалению, за удобство приходится платить. В
принципе, минусов при использовании rivafb всего несколько.
1. Вывод на экран существенно замедляется, но нам ведь не в игрушки
играть :), кроме того видео смотреть можно безо всяких тормозов.
2. Пока невозможно использовать совместно rivafb и nvidia drivers для
X — либо наглухо виснет, либо пропадает изображение. Не знаю как
сейчас обстоят дела, уже год как не проверял, но, судя по крикам
из форумов — все без изменений. Так что приходится выбирать — либо
rivafb в консоли, либо nvidia в иксах.
3. В ядрах 2.4 все работает на ок. В ветке 2.5 не так давно
заработало тоже, однако есть небольшие проблемы с кириллицей.

Вот, кажется, и все.

теперь, собственно, настройка.

Использовать framebuffer можно либо встроенным в ядро, либо
подгружая как модуль. Если включаете в ядро, то для достижения
необходимого разрешения и частоты экрана достаточно добавить в
lilo.conf строчку типа append=»video:rivafb. » например вот так:

# Linux bootable partition config begins
image = /boot/vmlinuz
append=»video=rivafb:xres:800,yres:600,pixclock:17761,
left_margin:152,right_margin:32,upper_margin:27,lower_margin:1,
hsync_len:64,vsync_len:3,bits_per_pixel:32″
root = /dev/hda2
label = Linux>
read-only
# Linux bootable partition config ends

Сразу оговорюсь, что вышеописанные значения расчитаны для режима
800×600, 85Гц и 32bit, проверены на видеокартах GeForce256, TNT2,
GeForce2 MX400 (GeForce4 — пока не поддерживается, во всяком случае —
у меня глючит). Рассчитать режимы каждый сам сможет под свои
разрешение и частоту, внимательно прочитав framebuffer.txt. Чтоб не
томить — вот выдержка из данного документа:

An XFree86 mode line consists of the following fields:
«800×600» 50 800 856 976 1040 600 637 643 666
DCF HR SH1 SH2 HFL VR SV1 SV2 VFL

The frame buffer device uses the following fields:

— pixclock: pixel clock in ps (pico seconds)
— left_margin: time from sync to picture
— right_margin: time from picture to sync
— upper_margin: time from sync to picture
— lower_margin: time from picture to sync
— hsync_len: length of horizontal sync
— vsync_len: length of vertical sync

1) Pixelclock:
xfree: in MHz
fb: in picoseconds (ps)

pixclock = 1000000 / DCF

2) horizontal timings:
left_margin = HFL — SH2
right_margin = SH1 — HR
hsync_len = SH2 — SH1

3) vertical timings:
upper_margin = VFL — SV2
lower_margin = SV1 — VR
vsync_len = SV2 — SV1

Good examples for VESA timings can be found in the XFree86 source tree,
under «xc/programs/Xserver/hw/xfree86/doc/modeDB.txt».

Если файла modeDB.txt у вас под рукой не найдется, можно заглянуть
в /etc/fb.modes, но если и там нет нужного вам режима, можно еще
сделать так: временно подредактировать XF86Config, чтобы в X получить
нужный вам режим; потом запускаете xvidinfo, и записываете текущие
значения HFL, HR, SH1 и т.д.; потом вычисляете. потом подставляете.
Еще есть специальные программы-калькуляторы, но я ими не пользовался.
Выбор за вами.

Наконец, специально для тех, кто будет использовать rivafb как
модуль. Вышеуказанная строка append=». » в lilo.conf уже не работает,
приходится действовать в лоб, а именно — перед сборкой ядра и после
наложения необходимых патчей подредактировать один файл в исходниках
ядра (в случае kernel-2.5.xx два файла):

1. kernel-2.4.xx
/usr/src/linux-2.4.xx/drivers/video/riva/fbdev.c
ищем такие строки:

static struct fb_var_screeninfo rivafb_default_var = <
xres: 640,
yres: 480,
xres_virtual: 640,
yres_virtual: 480,
xoffset: 0,
yoffset: 0,
bits_per_pixel: 8,
grayscale: 0,
red: <0, 6, 0>,
green: <0, 6, 0>,
blue: <0, 6, 0>,
transp: <0, 0, 0>,
nonstd: 0,
activate: 0,
height: -1,
width: -1,
accel_flags: 0,
pixclock: 39721,
left_margin: 40,
right_margin: 24,
upper_margin: 32,
lower_margin: 11,
hsync_len: 96,
vsync_len: 2,
sync: 0,
vmode: FB_VMODE_NONINTERLACED
>;

и меняем значения переменных на нужные:

static struct fb_var_screeninfo rivafb_default_var = <
xres: 800,
yres: 600,
xres_virtual: 800,
yres_virtual: 600,
xoffset: 0,
yoffset: 0,
bits_per_pixel: 32,
grayscale: 0,
red: <0, 6, 0>,
green: <0, 6, 0>,
blue: <0, 6, 0>,
transp: <0, 0, 0>,
nonstd: 0,
activate: 0,
height: -1,
width: -1,
accel_flags: 0,
pixclock: 17761,
left_margin: 152,
right_margin: 32,
upper_margin: 27,
lower_margin: 1,
hsync_len: 64,
vsync_len: 3,
sync: 0,
vmode: FB_VMODE_NONINTERLACED
>;

2. в kernel 2.5.xx аналогично правим этот же и еще один файл:

/usr/src/linux-2.5.xx/drivers/video/vfb.c
static struct fb_var_screeninfo vfb_default __initdata = <
.xres = 800,
.yres = 600,
.xres_virtual = 800,
.yres_virtual = 600,
.bits_per_pixel = 32,
.red = < 0, 8, 0 >,
.green = < 0, 8, 0 >,
.blue = < 0, 8, 0 >,
.activate = FB_ACTIVATE_TEST,
.height = -1,
.width = -1,
.pixclock = 17761,
.left_margin = 152,
.right_margin = 32,
.upper_margin = 27,
.lower_margin = 1,
.hsync_len = 64,
.vsync_len = 3,
.vmode = FB_VMODE_NONINTERLACED,
>;

Источник

Зачем нужен framebuffer?

Читал всякие статьи и наткнулся на framebuffer. Зачем он нужен не понятно. Будет ли комп работать быстрее, если включить поддержку framebuffer’a? Это что-то типа DirectDraw?

Зачем нужен framebuffer?

Отображать графику без иксов.

Зачем нужен framebuffer?

Для Х он без разницы. Это в стародавние времена, когда Х ставить не хотелось, вот через него работали.

Зачем нужен framebuffer?

И все? А я где-то видел что можно иксы заставить работать через этот framebuffer. Оно быстрее в таком случае будет работать?

Зачем нужен framebuffer?

Все ясно. Спасибо.

Зачем нужен framebuffer?

И ещё вот www.directfb.org выглядит интересно gtk портировали итп., вроде китайцы какой то смартфон делали там был directfb вместо иксов.

Читайте также:  Обновил драйвера видеокарты выдает ошибку

Зачем нужен framebuffer?

Нет, Х не работает через него. Но для фреймбуфера есть, например, библиотеко пользовательского интерфейса Gtk+. Хотя я не пробовал такое ее использование.

Зачем нужен framebuffer?

А фильмы? Будет ли какой-нить профит при просмотре фильмов? У меня вот проблема — я когда смотрю кино, через некоторое время мой ноутбук уходит в ребут. Я так думаю что это камень нагревается и срабатывает защита. Как мне можно узнать из-за чего это происходит? И как это можно починить? На ноутбуке ATI. Я поставил fglrx, и все равно такая фигня происходит. Что делать?

Зачем нужен framebuffer?

> У меня вот проблема — я когда смотрю кино, через некоторое время мой ноутбук уходит в ребут. Я так думаю что это камень нагревается и срабатывает защита. Как мне можно узнать из-за чего это происходит? И как это можно починить? На ноутбуке ATI. Я поставил fglrx, и все равно такая фигня происходит. Что делать?

Чистить ноутбук. Я таким образом доигрался до того, что спалил карточку (тоже АТИ). Теперь периодически чищу.. Проблемы прекратились.

Зачем нужен framebuffer?

Что значит «Чистить ноутбук»? Типа тряпочкой его протирать?

Re: Зачем нужен framebuffer?

>Как мне можно узнать из-за чего это происходит?

Зачем нужен framebuffer?

Типа снять клавиатуру и пинцетом, тряпочкой без ворса и сжатым воздухом..
Пыль забивает кулеры и воздуховоды.. Соответственно идет перегревание.
Мой ноутбук я брал б/у (со штатов привезли), у предыдущих хозяев то ли кошка линяла, то ли пледы какие-то облазили.. Все оказалось еже каким то ворсом забито.
Но у меня руки все не доходили, лень было — и влетел в замену карточки.

Зачем нужен framebuffer?

Я смотрел и ничего там не нашел. Он сначала зависает, а потом уходит в ребут. И звук так дергается. Симптомы такие — последние n секунд звука происзводятся постоянно, комп ни на что не реагирует, потом ресет. Продолжается это секунды 2-3. Логи смотрел и ничего там не нашел.

Зачем нужен framebuffer?

ОК, приду домой — почищу.

Зачем нужен framebuffer?

>Нет, Х не работает через него.

у меня в иксах свой фреймбуфер 🙂
Option «ShadowFB» «true»
Только через него нормально и работает.

Зачем нужен framebuffer?

А может это не видео? Может это звук? Если в Linux программы которыми можно нагрузить видео-карту по максимуму?

Зачем нужен framebuffer?

>Зачем он нужен не понятно.

Чтоб в консоли было 1280х1024.

Можно даже через aalib вполне так кино смотреть.

Re: Зачем нужен framebuffer?

В стародавние времена был svgatext, а уже потом framebuffer. Они позволяли выставить большее разрешение и получить больше текстовых символов на экране (уже на 17″ 80×25 символов выглядит страшно), а ещё поднять частоту, так как есть ЭЛТ-мониторы.

Не на всех платформах есть текстовый режим видеоадаптера, поэтому там framebuffer это единственный вариант текстовой консоли.

Вывод текста через framebuffer работает медленне, так как в видеопамять сиволы пишется в виде растра (много байт), а не кодом (один байт).

Источник

Framebuffer

A framebuffer (frame buffer, or sometimes framestore) is a portion of random-access memory (RAM) [1] containing a bitmap that drives a video display. It is a memory buffer containing data representing all the pixels in a complete video frame. [2] Modern video cards contain framebuffer circuitry in their cores. This circuitry converts an in-memory bitmap into a video signal that can be displayed on a computer monitor.

In computing, a screen buffer is a part of computer memory used by a computer application for the representation of the content to be shown on the computer display. [3] The screen buffer may also be called the video buffer, the regeneration buffer, or regen buffer for short. [4] Screen buffers should be distinguished from video memory. To this end, the term off-screen buffer is also used.

The information in the buffer typically consists of color values for every pixel to be shown on the display. Color values are commonly stored in 1-bit binary (monochrome), 4-bit palettized, 8-bit palettized, 16-bit high color and 24-bit true color formats. An additional alpha channel is sometimes used to retain information about pixel transparency. The total amount of memory required for the framebuffer depends on the resolution of the output signal, and on the color depth or palette size.

Contents

History [ edit ]

Computer researchers [ who? ] had long discussed the theoretical advantages of a framebuffer, but were unable to produce a machine with sufficient memory at an economically practicable cost. [ citation needed ] [5] In 1947, the Manchester Baby computer used a Williams tube, later the Williams-Kilburn tube, to store 1024 bits on a cathode-ray tube (CRT) memory and displayed on a second CRT. [6] [7] Other research labs were exploring these techniques with MIT Lincoln Laboratory achieving a 4096 display in 1950. [5]

A color scanned display was implemented in the late 1960s, called the Brookhaven RAster Display (BRAD), which used a drum memory and a television monitor. [8] In 1969, A. Michael Noll of Bell Labs implemented a scanned display with a frame buffer, using magnetic-core memory. [9] Later on, the Bell Labs system was expanded to display an image with a color depth of three bits on a standard color TV monitor.

In the early 1970s, the development of MOS memory (metal-oxide-semiconductor memory) integrated-circuit chips, particularly high-density DRAM (dynamic random-access memory) chips with at least 1 kb memory, made it practical to create, for the first time, a digital memory system with framebuffers capable of holding a standard video image. [10] [11] This led to the development of the SuperPaint system by Richard Shoup at Xerox PARC in 1972. [10] Shoup was able to use the SuperPaint framebuffer to create an early digital video-capture system. By synchronizing the output signal to the input signal, Shoup was able to overwrite each pixel of data as it shifted in. Shoup also experimented with modifying the output signal using color tables. These color tables allowed the SuperPaint system to produce a wide variety of colors outside the range of the limited 8-bit data it contained. This scheme would later become commonplace in computer framebuffers.

Читайте также:  Можно ли через hdmi подключить xbox к видеокарте компьютера

In 1974, Evans & Sutherland released the first commercial framebuffer, the Picture System, [12] costing about $15,000. It was capable of producing resolutions of up to 512 by 512 pixels in 8-bit grayscale, and became a boon for graphics researchers who did not have the resources to build their own framebuffer. The New York Institute of Technology would later create the first 24-bit color system using three of the Evans & Sutherland framebuffers. [13] Each framebuffer was connected to an RGB color output (one for red, one for green and one for blue), with a Digital Equipment Corporation PDP 11/04 minicomputer controlling the three devices as one.

In 1975, the UK company Quantel produced the first commercial full-color broadcast framebuffer, the Quantel DFS 3000. It was first used in TV coverage of the 1976 Montreal Olympics to generate a picture-in-picture inset of the Olympic flaming torch while the rest of the picture featured the runner entering the stadium.

The rapid improvement of integrated-circuit technology made it possible for many of the home computers of the late 1970s to contain low-color-depth framebuffers. Today, nearly all computers with graphical capabilities utilize a framebuffer for generating the video signal. Amiga computers, created in the 1980s, featured special design attention to graphics performance and included a unique Hold-And-Modify framebuffer capable of displaying 4096 colors.

Framebuffers also became popular in high-end workstations and arcade system boards throughout the 1980s. SGI, Sun Microsystems, HP, DEC and IBM all released framebuffers for their workstation computers in this period. These framebuffers were usually of a much higher quality than could be found in most home computers, and were regularly used in television, printing, computer modeling and 3D graphics. Framebuffers were also used by Sega for its high-end arcade boards, which were also of a higher quality than on home computers.

Display modes [ edit ]

Framebuffers used in personal and home computing often had sets of defined modes under which the framebuffer can operate. These modes reconfigure the hardware to output different resolutions, color depths, memory layouts and refresh rate timings.

In the world of Unix machines and operating systems, such conveniences were usually eschewed in favor of directly manipulating the hardware settings. This manipulation was far more flexible in that any resolution, color depth and refresh rate was attainable – limited only by the memory available to the framebuffer.

An unfortunate side-effect of this method was that the display device could be driven beyond its capabilities. In some cases this resulted in hardware damage to the display. [14] More commonly, it simply produced garbled and unusable output. Modern CRT monitors fix this problem through the introduction of protection circuitry. When the display mode is changed, the monitor attempts to obtain a signal lock on the new refresh frequency. If the monitor is unable to obtain a signal lock, or if the signal is outside the range of its design limitations, the monitor will ignore the framebuffer signal and possibly present the user with an error message.

LCD monitors tend to contain similar protection circuitry, but for different reasons. Since the LCD must digitally sample the display signal (thereby emulating an electron beam), any signal that is out of range cannot be physically displayed on the monitor.

Color palette [ edit ]

Framebuffers have traditionally supported a wide variety of color modes. Due to the expense of memory, most early framebuffers used 1-bit (2-color), 2-bit (4-color), 4-bit (16-color) or 8-bit (256-color) color depths. The problem with such small color depths is that a full range of colors cannot be produced. The solution to this problem was indexed color which adds a lookup table to the framebuffer. Each color stored in framebuffer memory acts as a color index. The lookup table serves as a palette with a limited number of different colors.

Here is a typical indexed 256-color image and its own palette (shown as a rectangle of swatches):

In some designs it was also possible to write data to the LUT (or switch between existing palettes) on the run, allowing dividing the picture into horizontal bars with their own palette and thus render an image that had a far wider palette. For example, viewing an outdoor shot photograph, the picture could be divided into four bars, the top one with emphasis on sky tones, the next with foliage tones, the next with skin and clothing tones, and the bottom one with ground colors. This required each palette to have overlapping colors, but carefully done, allowed great flexibility.

Memory access [ edit ]

While framebuffers are commonly accessed via a memory mapping directly to the CPU memory space, this is not the only method by which they may be accessed. Framebuffers have varied widely in the methods used to access memory. Some of the most common are:

  • Mapping the entire framebuffer to a given memory range.
  • Port commands to set each pixel, range of pixels or palette entry.
  • Mapping a memory range smaller than the framebuffer memory, then bank switching as necessary.
Читайте также:  Новая видеокарта нет сигнала на мониторе

The framebuffer organization may be packed pixel or planar. The framebuffer may be all points addressable or have restrictions on how it can be updated.

RAM on the video card [ edit ]

Video cards always have a certain amount of RAM. This RAM is where the bitmap of image data is «buffered» for display. The term frame buffer is thus often used interchangeably when referring to this RAM.

The CPU sends image updates to the video card. The video processor on the card forms a picture of the screen image and stores it in the frame buffer as a large bitmap in RAM. The bitmap in RAM is used by the card to continually refresh the screen image. [15]

Virtual framebuffers [ edit ]

Many systems attempt to emulate the function of a framebuffer device, often for reasons of compatibility. The two most common virtual framebuffers are the Linux framebuffer device (fbdev) and the X Virtual Framebuffer (Xvfb). Xvfb was added to the X Window System distribution to provide a method for running X without a graphical framebuffer. The Linux framebuffer device was developed to abstract the physical method for accessing the underlying framebuffer into a guaranteed memory map that is easy for programs to access. This increases portability, as programs are not required to deal with systems that have disjointed memory maps or require bank switching.

Page flipping [ edit ]

A frame buffer may be designed with enough memory to store two frames worth of video data. In a technique known generally as double buffering or more specifically as page flipping, the framebuffer uses half of its memory to display the current frame. While that memory is being displayed, the other half of memory is filled with data for the next frame. Once the secondary buffer is filled, the framebuffer is instructed to display the secondary buffer instead. The primary buffer becomes the secondary buffer, and the secondary buffer becomes the primary. This switch is often done after the vertical blanking interval to avoid screen tearing where half the old frame and half the new frame is shown together.

Page flipping has become a standard technique used by PC game programmers.

Graphics accelerators [ edit ]

As the demand for better graphics increased, hardware manufacturers created a way to decrease the amount of CPU time required to fill the framebuffer. This is commonly called graphics acceleration. Common graphics drawing commands (many of them geometric) are sent to the graphics accelerator in their raw form. The accelerator then rasterizes the results of the command to the framebuffer. This method frees the CPU to do other work.

Early accelerators focused on improving the performance of 2D GUI systems. While retaining these 2D capabilities, most modern accelerators focus on producing 3D imagery in real time. A common design uses a graphics library such as OpenGL or Direct3D which interfaces with the graphics driver to translate received commands to instructions for the accelerator’s graphics processing unit (GPU). The GPU uses those instructions to compute the rasterized results and the results are bit blitted to the framebuffer. The framebuffer’s signal is then produced in combination with built-in video overlay devices (usually used to produce the mouse cursor without modifying the framebuffer’s data) and any final special effects that are produced by modifying the output signal. An example of such final special effects was the spatial anti-aliasing technique used by the 3dfx Voodoo cards. These cards add a slight blur to output signal that makes aliasing of the rasterized graphics much less obvious.

At one time there were many manufacturers of graphics accelerators, including: 3dfx Interactive; ATI; Hercules; Trident; Nvidia; Radius; S3 Graphics; SiS and Silicon Graphics. As of 2015 [update] the market for graphics accelerators for x86-based systems is dominated by Nvidia (acquired 3dfx in 2002), AMD (who acquired ATI in 2006), and Intel (which currently produces only integrated GPUs rather than discrete video cards).

Comparisons [ edit ]

With a framebuffer, the electron beam (if the display technology uses one) is commanded to perform a raster scan, the way a television renders a broadcast signal. The color information for each point thus displayed on the screen is pulled directly from the framebuffer during the scan, creating a set of discrete picture elements, i.e. pixels.

Framebuffers differ significantly from the vector displays that were common prior to the advent of raster graphics (and, consequently, to the concept of a framebuffer). With a vector display, only the vertices of the graphics primitives are stored. The electron beam of the output display is then commanded to move from vertex to vertex, tracing a line across the area between these points.

Likewise, framebuffers differ from the technology used in early text mode displays, where a buffer holds codes for characters, not individual pixels. The video display device performs the same raster scan as with a framebuffer, but generates the pixels of each character in the buffer as it directs the beam.

Источник