OSDev

для всех
Текущее время: 22 ноя 2017, 23:10

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 52 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 23 июн 2017, 19:40 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Пиши, на Ассемблере оно понятнее получается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 24 июн 2017, 03:02 

Зарегистрирован: 12 июн 2017, 01:09
Сообщения: 18
Himik писал(а):
Пиши, на Ассемблере оно понятнее получается.

Представляю небольшой туториал, в котором я попытаюсь простым рабоче-крестьянским языком описать что такое PAT и как его попользовать в свое удовольствие.

Итак PAT (Page Attribute Table), в моем вольном переводе означает "Таблица аттрибутов страниц(ы)".
Зачем это еще, а можно без этого?
Да можно, если писать ядро с текстовым интерфейсом ONLY или совсем уж ущербной графикой с низким разрешением и убогой цветовой гаммой.
А ежели хочется красивостей всяких, прозрачностей там или еще чего (3D Pipeline к примеру), хорошей графики стало быть, то без PAT все еще можно обойтись, но отрисовка пикселей будет очень медленной, что обязательно вызовет у юзера бесконечный поток нецензурной брани в адрес разраба ядра.
Что бы этого избежать, и не только этого, необходимо ускорить вывод графики одним из трех известных способов:
1. Аппаратное ускорение (Hardware acceleration) графики, то что надо, но есть некоторые ньюансы, а именно, как это программно реализовать в виде кода. Видеокарт миллионы, доков на абсолютное большинство нет и не предвидиться, а одного желания не достаточно.
2. Программное ускорение (Software acceleration) графики, на порядки хуже HW, но за неимение лучшего пойдет и так, срединный путь как говориться.
3. Взять цветные фломастеры и рисовать графику вручную прямо на экране монитора, только это очень медленно, а и не у всякого получиться, красиво что бы, да и в башню может прилететь, если моник чужой.

- Замутим?
- Ну пожалуй, а что надо делать?

Да сущие пустяки, для начала почитать, например, вот этот туториал: http://forum.osdev.org/viewtopic.php?p=257947&sid=70ea17364d329129a5a4cd029db18032#p257947,
равно как и многие другие, да собственно в самой спецификации VESA BIOS EXTENSION (VBE) "vbe3.pdf" (гуглиться за один клик), все разжевано до состояния бульона, не по нашему правда написано, но понять можно.
После того как станет понятным и родным словосочетание LFB (Linear Frame Buffer) можно и этот туториал прочитать, тут уже по нашему, для себя, что бы значит просто было и понятно.

Начнем.
PAT входит в состав так называемых MSR (Model-Specific Registers), это кусок памяти внутри камня, который не у всех камней есть, проверять надо, а как?
Проверить поддержку камнем MSR вообще и PAT в частности можно очень просто:
Код:
   mov eax, 0x01            ; EAX = 0x01
   cpuid
   
   bt edx, 5               ; бит №5 в регистре EDX должен быть возведен
   jnc @MSR_IS_NOT_SUPPORTED   ; если это не так, то MSR не поддерживается
   
   bt edx, 16               ; бит №16 в регистре EDX должен быть возведен
   jnc @PAT_IS_NOT_SUPPORTED   ; если это не так, то PAT не поддерживается

PAT нельзя включить или выключить, он активен всегда (даже если нам это не надо или мы вооще ничего о нем не знаем или не хотим знать), при условии, что включена страничная адресация памяти (в LONG MODE это без вариантов, стало быть обязательно ДА).
У PAT есть свой собственный регистр, он условно называется IA32_PAT, условно потому, что к нему нельзя обратиться по имени, а только по смещению 0x277 относительно памяти, которая называется MSR (Model-Specific Registers).
Прямого доступа к этой памяти разумеется нет, но мы можем запросить содержимое интересующнго нас регистра с помощью инструкции RDMSR (Read MSR), внести туда любые изменения (под нашу прямую ответственность) и записать обратно с помощью инструкции WRMSR (Write MSR).
Как уже было отмечено ранее, нас интересует исключительно регистр IA32_PAT расположенный по смещению 0x277. Давайте посмотрим что там:
Код:
   mov ecx, 0x277            ; в регистр ECX заносим смещение
   rdmsr                  ; читаем в RAX MSR по смещению ECX = 0x277

Интересующая нас информация находиться в регистре RAX, именно RAX, т.к. регистр IA32_PAT 64-битный, не смотря на цифру 32 в названии.
Для нашей цели (ускорение вывода пикселей в LFB (Linear Frame Buffer)), нам будет вполне достаточно регистра EAX.
Итак запрос сделан, каков же ответ. В моем случае, на эмуляторе QEMU, регистр EAX содержит число 0x00070406. Ну и что, а зачем это? Читаем дальше.

Что же представляет из себя регистр IA32_PAT, рассмотрим для начала регистр RAX:
Код:
+--------+--------+--------+--------+--------+--------+--------+--------+
|                                  RAX                                  |
+--------+--------+--------+--------+--------+--------+--------+--------+
|                                   |                EAX                |
+--------+--------+--------+--------+--------+--------+--------+--------+
|                 |                 |                 |       AX        |
+--------+--------+--------+--------+--------+--------+--------+--------+
|        |        |        |        |        |        |   AH   |   AL   |
+--------+--------+--------+--------+--------+--------+--------+--------+

Как видно из рисунка, регистр RAX состоит ровно из 8 одинаковых однобайтовых (8 битовых) частей, к некоторым из них можно обратиться по имени, к большинству нельзя, но ведь это нас не останавливает, мы можем обратиться по смещению и получить значение любого байта или даже бита.
По аналогии с регистром RAX составим схему регистра IA32_PAT:
Код:
+--------+--------+--------+--------+--------+--------+--------+--------+
|        |        |        |        |        |        |   AH   |   AL   |
+--------+--------+--------+--------+--------+--------+--------+--------+
|  PAT7  |  PAT6  |  PAT5  |  PAT4  |  PAT3  |  PAT2  |  PAT1  |  PAT0  |
+--------+--------+--------+--------+--------+--------+--------+--------+
|00000bbb|00000bbb|00000bbb|00000bbb|00000bbb|00000bbb|00000bbb|00000bbb|
+--------+--------+--------+--------+--------+--------+--------+--------+

Где 00000bbb это двоичное представление данных (8 бит), из которых 00000 = 5 нулевых бит и bbb = 3 значащих бита, которые, в свою очередь, так же могут быть нулевыми, а могут и не быть.
Из рисунка-схемы видно, что регистр IA32_PAT так же как и RAX состоит из 8 одинаковых однобайтовых (8 битовых) частей, к которым нельзя обратиться по имени, а только по смещению, но мы то это умеем делать.

Напомню, что пять старших битов каждого байта PAT0 ... PAT7 ВСЕГДА равны нулю, значащими являются только 3 младших бита, с ними и будем работать.
А как же тогда понять в каких случаях младшие три бита не нулевые и что все это означает?
Как раз для такого случая Intel составила табличку, которую мы тиснем из "Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 3A, 11.12 PAGE ATTRIBUTE TABLE (PAT)",
я только чутка ее модифицировал, для простоты.
Код:
+-----------------------------------------------------------------------+
|  БИНАРНЫЙ КОД  |                     РАСШИФРОВКА                      |
+-----------------------------------------------------------------------+
|   000b = 0x00  |                   Uncacheable (UC)                   |
+-----------------------------------------------------------------------+
|   001b = 0x01  |                 Write Combining (WC)                 |
+-----------------------------------------------------------------------+
|   010b = 0x02  |                       Reserved                       |
+-----------------------------------------------------------------------+
|   011b = 0x03  |                  Write Through (WT)                  |
+-----------------------------------------------------------------------+
|   100b = 0x04  |                 Write Protected (WP)                 |
+-----------------------------------------------------------------------+
|   101b = 0x05  |                    Write Back (WB)                   |
+-----------------------------------------------------------------------+
|   110b = 0x06  |                    Uncached (UC-)                    |
+-----------------------------------------------------------------------+
|   111b = 0x07  |                       Reserved                       |
+-----------------------------------------------------------------------+

Как видно из таблицы, столбец "БИНАРНЫЙ КОД" аккурат представлен тремя значащими битами, а столбец "РАСШИФРОВКА" дает нам однозначное толкование этих самых трех битов.
Давайте припомним наш прошлый запрос, который мы так и не распарсили, EAX = 0x00070406 = 0x00 0x07 0x04 0x06
Смотрим на табличку и видим что:
PAT0 = 0x06 = Uncached (UC-)
PAT1 = 0x04 = Write Protected (WP)
PAT2 = 0x07 = Reserved
PAT3 = 0x00 = Uncacheable (UC)
Старшие PAT'ы (PAT4 ... PAT7) нам вообще не интересны.

Ну допустим, узнали мы, что код Write Combining (WC) = 0x01, а что с ним делать то, куда прописать и главное как?

Для начала следует определиться какой из PAT'ов тиснуть, они НЕ зависимы друг от друга и брать можно любой, мы же пишем ядро мы и решаем.
PAT0 мы трогать не будем, почему, станет понятно из дальнейшего текста.
А что там у нас следующее на очереди, так ведь PAT1, а можно? Нужно!
Решено замутим с PAT1 (он ПЕРВЫЙ справа, соответствует регистру AH, а PAT0 НУЛЕВОЙ справа, соответствует регистру AL):
Код:
   mov ecx, 0x277            ; в регистр ECX заносим смещение
   rdmsr                  ; читаем в RAX MSR по смещению ECX = 0x277
   
   mov ah, 0x01            ; Write Combining (WC) = 0x01
   wrmsr                  ; пишем RAX = IA32_PAT обратно в MSR

Ну что ты все? Почти, потерпи еще немного, я скоро.

Далее я буду излагать свое личное мнение на то как устоен этот мир, что правильно и что не правильно.
Итак, ось должна быть строго 64-битной, память внутри ядра должна быть расчехлена на 2-х мегабайтные страницы, я бы расчехлил на 1-гигабайтные, но не все камни это держат, печаль.
Тема расчехления памяти на страницы тянет на отдельный туториал, может кто его и напишет (подключайтесь), а может даже это буду я, посмотрим, а сейчас голый код со скромными коментами:
Код:
;-----------------------------------------------------------------------
;   Это мне так удобно, можно поменять адреса на свой вкус
;-----------------------------------------------------------------------
%define PML4T      0x2000      ; P4 = корневая директория х512 GB
%define PDPT      0x3000      ; P3 (4 страницы по 1 GB каждая)
%define PDT0      0x4000      ; P2.0 (512 страниц по 2 MB каждая)
%define PDT1      0x5000      ; P2.1 (512 страниц по 2 MB каждая)
%define PDT2      0x6000      ; P2.2 (512 страниц по 2 MB каждая)
%define PDT3      0x7000      ; P2.3 (512 страниц по 2 MB каждая)
;-----------------------------------------------------------------------
;   Сначала корневая директория PML4T - каждая запись это 512 Гигабайт
;-----------------------------------------------------------------------
   ; Set up PML4T (P4)         ; 0x2000
   mov dword eax, PDPT         ; адрес PDPT (P3)
   or dword eax, 11b         ; R/W / PML4E present
   mov dword [PML4T], eax
   mov dword [PML4T + 4], 0
;-----------------------------------------------------------------------
;   Следующая за корнем директория PDPT - каждая запись это 1 Гигабайт
;-----------------------------------------------------------------------
   ; Set up PDPT (P3)         ; 0x3000
   mov ecx, 4               ; 4 страницы по (2 * 512 = 1 GB) = 4 GB
   xor ebx, ebx
   
   mov edi, PDPT            ; P3
   mov eax, PDT            ; адрес PDT (P2) = 0x4000
   or al, 00000011b         ; R/W / PDPT present
   
@NEXT_P3:
   mov dword [edi], eax
   mov dword [edi+4], ebx
   
   add eax, 0x1000
   add edi, 8
   loop @NEXT_P3
;-----------------------------------------------------------------------
;   Собственно страницы - каждая запись (страница) это 2 мегабайта
;-----------------------------------------------------------------------
   ; Set up PDT            ; 0x4000
   mov edi, PDT
   mov eax, 10000011b         ; 2MiB / ... / R/W / PDT present
   mov ecx, 512*4            ; отжимаем 4GB: 4 PDT по 1GB (512 * 2MB)
   xor ebx, ebx
   
@NEXT_P2:
   mov dword [edi+0], eax
   mov dword [edi+4], ebx
   add eax, 0x200000         ; + 2 MiB
   add edi, 8
   loop @NEXT_P2
;-----------------------------------------------------------------------
;   Определим диапазон адресов занятых под LFB как Write Combining (WC)
;-----------------------------------------------------------------------
   mov eax, dword [param.lfb]   ; LFB
   shr eax, 21               ; количество 2М страниц   (0x480 = 1152)
   shl eax, 3               ; (количество 2М страниц) * 8 байт
   
   mov edi, PDT
   add edi, eax
   
   mov eax, dword [param.lfb]   ; LFB
   add eax, 10001011b         ; 2MiB / ... / PWT / ... / R/W / PDT present
   
   mov ecx, 8               ; 16M / 2M = 8
   xor ebx, ebx
   
@SET_WC:
   mov dword [edi+0], eax
   mov dword [edi+4], ebx
   add eax, 0x200000         ; + 2 MiB
   add edi, 8
   loop @SET_WC

Как память расчехлять на сраницы отдельный разговор, а вот слив LFB в WC рассмотрим подробнее.
Итак через VESA мы получили адрес LFB, я сохранил его в структуру 'param', можно назвать по своему, а разве может быть иначе.
Адрес LFB выровнен, уж не знаю насколько точно, но на 2 MB можно расчитывать, поэтому делим значение адреса LFB на 2 MB, что бы узнать смещение от НАЧАЛА памяти, т.е. от НУЛЯ в 2-х мегабайтных страницах.
Например, пусть адрес LFB = 0x90000000, тогда делим 0x90000000 на 0x200000 и получаем 0x480 = 1152 2-х мегабайтных страниц. Их трогать НЕЛЬЗЯ, пропускаем.
Код:
   mov eax, dword [param.lfb]   ; LFB
   shr eax, 21               ; количество 2М страниц   (0x480 = 1152)

Напомню, что каждая запись в таблице PDT занимает 8 байт, а у нас этих записей, как мы только что посчитали, 0x480 = 1152 и их трогать НЕЛЬЗЯ, а как узнать какие можно, так просто:

0 запись = 8 * 0 = 0
1 запись = 8 * 1 = 8
...
343 запись = 8 * 343 = 2744
...
1152 запись = 8 * 1152 = 9216 = 0x2400

То есть нам нужно пропустить 1152 записи в таблице PDT, каждая запись это 8 байт, значит умножаем 1152 на 8 и получаем 9216 байт, это смещение от начала PDT в байтах.
Код:
   shl eax, 3               ; (количество 2М страниц) * 8 байт

Я знаю, что можно сразу сделать так:
Код:
   mov eax, dword [param.lfb]   ; LFB
   shr eax, 18               ; количество 2М страниц   (0x480 = 1152) * 8

Но как-нибудь потом лениво будет ломать голову, а почему я здесь написал 18, а как же так вышло ..., чем проще, тем лучше.
Далее EDI присваиваем адрес PDT в памяти и смещаемся на расчитанное количество байт:
Код:
   mov edi, PDT
   add edi, eax

Далее нам нужно расчитать "стартовое" значение, которым мы начнем перезаписывать атрибуты конкретно взятых страниц занятых под LFB.
По тупому берем еще раз адрес LFB из структуры 'param' и прибавляем к нему магическое число 10001011b в котором зарыта вся суть.

Распарсим эту магию:
самый младший бит №0 означает, что страница реально существует из нее можно читать и в нее можно писать
следующий бит №1 означает, как раз то, что страница R/W, т.е. и читаемая и писаемая
следующий бит №2 означает, посмотрите сами что он означает, или по тупому ставим ноль
следующий бит №3 означает, ОДИН ИЗ ТРЕХ значащих битов (PAT, PCD и PWT), в данном случае это PWT = 1
следующий бит №4 означает, ОДИН ИЗ ТРЕХ значащих битов (PAT, PCD и PWT), в данном случае это PCD = 0
самый старший бит №7 означает, что это 2-х мегабайтная страница, а если страницы 4-х килобайтные, то это и есть PAT (ОДИН ИЗ ТРЕХ значащих битов (PAT, PCD и PWT)) и он ДОЛЖЕН быть нулевым!
Но т.к. у нас страницы 2-мегабайтные, то 7 бит это НЕ PAT, а PAT это бит №12, и он у нас как раз нулевой.

Подитожим:
мы имеем следующее сочетание PAT|PCD|PWT = 001b, это НЕ ОЗНАЧАЕТ, что страница слита в WC, это означает, что аттрибут страницы берется из регистра PAT1, код которого = 001b = 0x01, а вот в него то мы как раз и записали атрибут WC, который тоже, по чистой случайности = 001b = 0x01.
Далее в цикле изменяем аттрибуты 8 страниц, а почему 8, да потому что у меня размер foreground+background буфера = 1920*1080*4*2 = 16 мегабайт, делим на 2 мегабайта (размер страницы) и получаем 8, количество страниц занятых под LFB.

Ну и напоследок, почему не рекомендуется трогать PAT0, потому что его код в формате PAT|PCD|PWT = 000b = 0x00 и именно этим кодом (все нули) мы по дефолту аттрибутим ВСЕ наши страницы и только потом переаттрибутиваем нужные на WC.
Т.е. ВСЕ наши страницы при инициации получают аттрибут 000b = 0x00 = PAT0, а в нем код 0x06 = Uncached (UC-), поэтому вывод пикселей так ужастно тупит.
Не вздумайте слить ВСЕ страницы в WC, это косяк!
На этом все, проще объяснить не могу, не имею такого таланта, надеюсь будет кому то полезно.


Последний раз редактировалось sabir 25 июн 2017, 20:21, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 24 июн 2017, 13:34 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1314
Откуда: Зеленоград
sabir писал(а):
PS: форматирование таблиц сбилось, лениво вручную подбирать, если кто подскажет как сохранить форматирование, исправлю, но и так вроде понятно.


Оформлять их как код, чтобы использовался моноширинный шрифт?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 25 июн 2017, 19:00 

Зарегистрирован: 12 июн 2017, 01:09
Сообщения: 18
Сработало, сам бы не додумался


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 25 июн 2017, 19:42 

Зарегистрирован: 10 окт 2013, 14:54
Сообщения: 80
sabir писал(а):
Совет тем, кто пойдет после меня, MTRR устаревшая технология и если камень поддерживает PAT, то не тратьте время и юзайте PAT. В частности MTRR сложнее настраивать, но главное то, что эта мулька может не выстрелить. Например, если памяти больше 4 гигабайт, то MTRR не работает, по крайней мере у меня не сработал, т.е. на ноуте с 4 гигами работает, а тот же самый код (уже записанный на флешку) на десктопе с 16 гигами не работает.
MTRR прекрасно работает при любом размере памяти - если всё правильно расписать.
Что довольно нетривиально для общего случая, да.

Для своей системы использовать лучше PAT - это на порядки проще, конечно.

Но если страничный режим активен не всегда или мы, например, грузим какой-ньть DOS - то MTRR - единственное средство поставить WC.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 25 июн 2017, 21:36 

Зарегистрирован: 12 июн 2017, 01:09
Сообщения: 18
А кто-нибудь имел дело с так называемыми ПЛИС (Программируемая логическая интегральная схема), а конкретнее FPGA (field-programmable gate array).
Меня все не оставляет желание замутить аппаратное ускорение графики и раз нет вменяемых доков на существующие видяхи, так может замутить свою, в которой я и только я буду решать какие будут регистры, как они будут называться, по какому адресу находятся и какова будет их разрядность.
Я читал об этом, есть даже примеры реализации VGA контроллеров и навроде как это не сильно сложно.
Однако насколько это реалистично, замутить свою видяху, при следущих условиях:
1. Деньги на покупку ПЛИС есть, потратить не жалко, даже если ничего не получиться, тем более что сумма в пределах 50-100 баксов, плевое дело.
2. Время и желание тоже есть, я упрямый как баран и если вцепился зубами, то уже не отпущу. Жалко только тратить время на линуксовые драйвера, там абстракция на абстракции и абстракцией погоняет, мерзость одним словом, я ненавижу абстракции, люблю когда все просто и понятно.
Вопрос только в том, сколько отдельных НЕ зависимых ядер можно замутить на среднем FPGA и какова будет их производительность.
Каждое ядро само по себе слабое это и коню ясно, но их должно быть очень много и ключевой момент, что работать они должны одновременно и не зависимо друг от друга, обрабатывая каждое свой собственный пиксель.
Сразу следует отметить, что реализация 3D пайплайна с шейдерами и числами с плавающей точкой пока только мечта, на сегодняшний день интересны только целые числа и простейшие математические действия: сложение, вычитание, умножение, деление, сдвиги и логические операции.
Это позволить быстро и качественно отрисовать 2D графику, включая прозрачность, красивый GUI одним словом.
На совместимось со стандартами, в том числе и VGA, универсальность и кроссплатформенность плевать в прямом смысле этого слова, камень только INTEL, если AMD потянет, возражать не стану, а на всякие ARM и прочее, ну вы поняли ...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 25 июн 2017, 22:29 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1314
Откуда: Зеленоград
Я с плисинами балюсь, например. Мелкую ПЛИС купить действительно не проблема, и стоить будет недорого. Но как Вы собираетесь её присобачивать к компу? Это надо делать свою плату (под PCI Express, естественно -- других шин для плат у более-менее современных матерей уже нет). Кроме того, надо обеспечить, чтоб ПЛИС работала с шиной в полном соответствии со стандартами -- а значит, нужно либо брать ПЛИС, где имеется соответствующий аппратный блок, либо самому реализовать его внутри ПЛИС. В обоих случаях плисина будет уже не такой дешёвой, как хотелось бы.

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

Программная поддержка. Написать драйвер даже простого устройства не всегда легко, ну а видюху к простым устройствам отнести тяжело. Чтобы функции ускорения реально работали, они должны соответствовать ожиданиям оси от таких функций, а драйвер эти ожидания должен поддерживать. Толку, например, в суперсовременной видюхе для Вынь-95? Все навороты железа там не будут использоваться, потому что нет программной поддержки, и видюха сможет работать лишь как VGA. С другой стороны, древнюю видюху с современной Виндой использовать нельзя, поскольку она не обладает требуемым минимумом функционала. Как дела в Линухе, я не знаю; подозреваю, что древность заставить там работать можно. Но в любом случае, под какую систему ни делай, а придётся с головой зарываться в её драйверную модель и писать кучу кода.

Ну а производительность... Даже на сверхкрутой плисине, стоящей многие тысячи или даже десятки тысяч баксов, она не будет дотягивать даже до современной виндюхи начального уровня. За универсальность ПЛИС приходится платить намного более низкой, чем у специализированных микросхем, производительностью. И смотреть на максимальные частоты ПЛИС здесь бессмысленно, потому что роль играет не то, с какой частотой сможет переключаться единичный триггер или какова задержка от входа до выхода LUT, а какова частота, на которой будет работать проект в целом.

Что же касается до типа опенсорцнутых разработок железа, то, насколько знаю, даже обычную VGA вроде бы не осилили, а про ускоритель и говорить нечего.

В общем, заставить ПЛИС выводить на дисплей буфер кадра -- это простая задача, а вот сделать видюху, пригодную для установки в ПК и работы с существующими осями (пускай даже с одной осью) -- это даже не на порядок более сложная, а... не знаю, в тысячу раз или в миллион.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 26 июн 2017, 02:31 

Зарегистрирован: 12 июн 2017, 01:09
Сообщения: 18
SII писал(а):
Это надо делать свою плату (под PCI Express, естественно -- других шин для плат у более-менее современных матерей уже нет).

Да здесь все так, но не думаю, что это сложнее, чем написать драйвер под закрытую энвидию, PCI Express открыта или нет, я просто не в курсе.
SII писал(а):
Видеопамять тоже никто не отменял. Работать с системной? Медленно и печально, а заодно сильно тормозит проц (потому что мешает ему обращаться к памяти).

Так для этого же и существуют выделенные регионы памяти, закрепленные за конкретной железкой или это не то? А как же интеловские видюхи работают, у меня только они, нареканий вообще нет, и видео декодируют и GUI рисуют со свистом, помню даже в Far Cry 3 играл на Haswell во встроенной графикой, на низких настройках, но тем не менее. Я писал под Intel в юзерспейсе графические проги, под Linux разумеется, все летает, т.е. я прямо вручную писал batch и через ioctl() отправлял в ядро на исполнение, своено рода MESA вери-вери-лайт, обратно все летало, речть идет строго о 2D.
Что то вроде этого:
Код:
   ;ioctl(ctx->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuffer);
   mov rdx, execbuf
   mov rsi, DRM_IOCTL_I915_GEM_EXECBUFFER2
   mov rdi, [ctx.fd]
   mov eax, sys_ioctl
   syscall

К тому же мне нужна только 2D графика, отрисовать окна с учетом того, что они могут перекрываться и просвечиваться, а правило отрисовки гласит, что каждый пиксель должен быть отрисован один и только один раз, плюс быстрый и качественный композитинг пикселей, включая альфа-блендинг.
SII писал(а):
Написать драйвер даже простого устройства не всегда легко, ну а видюху к простым устройствам отнести тяжело.

Я как раз иного мнения на этот счет, вся "тяжесть" написания драйвера на 95% обязана закрытости железки. Производители предлагают некую абстракцию тесно связанную с бинарным firmware, на эту абстракцию печатают несколько тысяч страниц с непонятными таблицами и структурами, которые ее (абстракцию) описывают, шаг вправо или шаг влево, закрытая информация, досвидос. На изучение этой абстракции можно потратить полжизни, а в конечном итоге все сводиться к тупой операции запись в порт (MMIO) или чтение из порта (MMIO) и больше НИЧЕГО.
Как пример тот же интел, все доки есть, они открыты, https://01.org/linuxgraphics/documentation/hardware-specification-prms, бери да юзай, только это абстракция, где черт ногу сломит, мне же надо прямой доступ к исполняемым ядрам, возможность кодить на ядрах видюхи как на ядрах CPU (да я знаю это тоже абстракция, но хотя бы хорошо документированная).
Только у CPU 8 ядер (максимум), а у GPU, ну скажем 20 (как у Haswell), да плюс на каждом ядре можно запустить 7 потоков (гипертрейдинг), 20 * 7 = 140 условных ядер.
А что сложного в видеокарте, ее ядра на порядки проще CPU, просты как цигане на вокзале.
Предположим есть линейный кусок памяти, я туда с помощью CPU загружаю 140 бакграунд пикселей, есть второй, такой же кусок памяти, я в него загружаю 140 фореграунд пикселей, затем пишу в порт видюхи код, скажем 0x03. Она получает код и знает, что в таком случае нужно скомпозитить 140 пикселей по заранее известным фиксированным адресам, формула простая.
Например так, поток №0 композитит пару пикселей (бакграунд-фореграунд) по смещению 0, поток №1 ... по смещению 4, поток №139 ... по смещению 556. Сложность только в синхронизации ядер и их одновременности.
Потом я тупо копирую готовые пиксели на экран и загружаю следующую порцию. Как например регистры SSE и AVX, только они очень короткие, не тянут, т.е. медленно работают.
SII писал(а):
Ну а производительность... Даже на сверхкрутой плисине, стоящей многие тысячи или даже десятки тысяч баксов, она не будет дотягивать даже до современной виндюхи начального уровня.

А вот это уже грустно и практически рубит под корень порыв энтузиазма.
И все же, Вы работаете в ПЛИС, сколько независимых и очень простых ядер (add sub mul div shr shl rol ror and or neg not mov inc dec) можно реализовать на 100 долларовой плиске, чисто ради любопытства, я читал про FPGA которые прошиваются только один раз и логика работы уже не может быть изменена, но зато там уже не логические связи, а железные, типа что то там плавиться или как то так, я просто совсем не в теме.
SII писал(а):
В общем, заставить ПЛИС выводить на дисплей буфер кадра -- это простая задача, а вот сделать видюху, пригодную для установки в ПК и работы с существующими осями (пускай даже с одной осью) ...

Здесь как раз нет проблем, я пишу ядро и я же реализовываю логику работы плиски, я решаю, что в порт PCI 0x32 нужно писать код 1000100110001110b и какая реакция будет, что каждый бит значит и т.д.
А есть ли разница между ПЛИС и FPGA, или FPGA это разновидность ПЛИС, про FPGA я читал неплохие отзывы, что якобы они чуть ли не конкуренцию составляют микроконтроллерам с фиксированной логикой или это рекламная замануха, типа дай нам денег, не парься, просто дай денег.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 26 июн 2017, 13:30 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1314
Откуда: Зеленоград
sabir писал(а):
Так для этого же и существуют выделенные регионы памяти, закрепленные за конкретной железкой или это не то?


Это всего лишь указание, что данная часть физического адресного пространства отведена такому-то устройству. Есть по этим адресам что-нибудь, нету ли -- без разницы. Настраивается всё сие динамически по большей части (PnP), лишь для унаследованного (legacy) старья есть жёсткие адреса (вроде отображения BIOS на вершину первого мегабайта и т.п.), да и те частично конфигурируются БИОСом через чипсет (например, содержимое ПЗУ с БИОСом переписывается в ОЗУ, после чего используется именно оттуда, что во много раз быстрей).

Цитата:
А как же интеловские видюхи работают


Интеловские графические процессоры интегрированы с центральными и подключены напрямую к контроллеру памяти. А устройства, висящие на PCI Express, должны пройти через как минимум один, а то и несколько мостов-коммутаторов, чтобы добраться до этой самой памяти. Плюс ширина доступа немного разная. А посему латентность памяти при обращении со стороны PCI Express существенно выше, а пропускная способность -- существенно ниже. Именно по этой причине у всех дискретных видюх на борту стоит своя видеопамять.

Цитата:
К тому же мне нужна только 2D графика, отрисовать окна с учетом того, что они могут перекрываться и просвечиваться, а правило отрисовки гласит, что каждый пиксель должен быть отрисован один и только один раз, плюс быстрый и качественный композитинг пикселей, включая альфа-блендинг.


Честно говоря, я подозреваю, что эту работу быстрей будет делать современный ЦП без всяких ускорителей на плисине, чем плисина, если под ЦП писать прямыми руками и кривыми извилинами, а не наоборот. Во всяком случае, если сравнивать с дешёвыми плисинами начального уровня, так сказать, куда много логики просто не влезет, а значит, не получится сильно распараллелить задачу (и, опять-таки, можно упереться в пропускную способность памяти).

Цитата:
Я как раз иного мнения на этот счет, вся "тяжесть" написания драйвера на 95% обязана закрытости железки


Ну, попробуйте написать драйвер OHCI, например. Документация имеется, сам он не особо сложный. Однако эффективный драйвер сделать не так просто, особенно если нет привычки мыслить "асинхронно".

Цитата:
И все же, Вы работаете в ПЛИС, сколько независимых и очень простых ядер (add sub mul div shr shl rol ror and or neg not mov inc dec) можно реализовать на 100 долларовой плиске


Ну, тут ещё как минимум разрядность требуется знать. Например, в самой жирной плисине семейства Spartan-6 (например, вот она в продаже: https://www.terraelectronica.ru/catalog_info.php?CODE=1069498) имеется 180 специальных аппаратных блоков, включающих преварительный сумматор, 18-разрядный умножитель и выходной сумматор -- как раз для быстрой реализации операций умножения с накоплением и т.п. вещей, часто используемых в цифровой обработке сигналов. Соответственно, можно считать, что имеется 180 быстрых умножителей-сумматоров (вход -- 18 бит, выход -- 36). На собствено "рассыпной" логике у той же плиски можно слепить до ~11500 4-разрядных сумматоров. В общем, ресурсов довольно много, на первый взгляд, но очень значительная часть из них уйдёт на всякие вспомогательные вещи, а не на собственно вычислительные ядра.


Цитата:
я читал про FPGA которые прошиваются только один раз и логика работы уже не может быть изменена, но зато там уже не логические связи, а железные, типа что то там плавиться или как то так, я просто совсем не в теме.


Не слышал про такие плисины, скорей, речь шла о ПЛМ, а это -- совсем другая опера. Существуют плисины со встроенной флэш-памятью, которым не нужно загружать прошивку при включении питания, но принципиально они ничем не отличаются от плисин с внешней загрузкой. И, естественно, никаких перемычек там нет -- 100500 мультиплексоров и мелких блоков статического ОЗУ (по 16-64 бита в зависимости от плисины), на которых реализуются произвольные логические функции.

Цитата:
А есть ли разница между ПЛИС и FPGA, или FPGA это разновидность ПЛИС, про FPGA я читал неплохие отзывы, что якобы они чуть ли не конкуренцию составляют микроконтроллерам с фиксированной логикой или это рекламная замануха, типа дай нам денег, не парься, просто дай денег.


ПЛИС и FPGA -- это одно и то же, только наше и буржуйское название. На определённых задачах они, естественно, обгонят не только микроконтроллеры, но и самые мощные процессоры, но всегда безнадёжно сольют любым специализированным микросхемам, решающим ту же задачу. Собственно, их и используют там, где надо более-менее быстро решить некую задачу, плохо решаемую на имеющихся микропроцессорах, но не настолько распространённую, чтобы оправдать разработку и заказ специализированной микросхемы. Поэтому видюху делать на ПЛИС можно для освоения самого процесса разработки подобного рода устройств и т.п., но не для конкуренции с существующими.

И да, если Вы думаете, что, взяв плисину за 100 баксов, разработка готовой платы будет не сильно дороже, Вы сильно ошибаетесь. Если у Вас нет опыта в разработке сколько-нибудь серьёзной электронике, Вы потратите несколько лет и, думаю, не меньше 10 000 баксов до получения более-менее работающей платы. Вот если Вы собаку съели на разводке всех этих DDR3 и прочих скоростных интерфейсов, тогда другое дело -- в тыщу баксов и 3-6 месяцев уложиться реально. Но в любом случае проще взять готовую плату, что-то вроде такой, например: https://www.xilinx.com/products/boards-and-kits/ek-a7-ac701-g.html. Это одна из самых дешёвых плат, имеющих мощную плисину (мощней той, которую я приводил в пример выше -- у неё примерно на 30% больше ресурсов, хотя изрядную их часть отожрёт контроллер памяти), достаточно большой объём ОЗУ на борту, видеовыход и PCI Express (ну и приличное число всякой прочей дребедени). Понятно, что 1300 баксов -- это цена "у них", у нас добавляете как минимум 30 процентов, а скорей, все 50 или даже больше (и таможенные пошлины, и наценка продавца, и проблемы с ввозом: поставка нам плисин, особенно жирных, американцами запрещена из-за санкций, и это как-то обходят -- и наверняка не бесплатно). Но зато покупаешь -- и оно сразу работает, а не глючит незнамо где и почему.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: driver VGA
СообщениеДобавлено: 26 июн 2017, 13:33 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
sabir писал(а):
PCI Express открыта или нет, я просто не в курсе.

Формально, спеки предоставляются только организациям-членам группы PCI-SIG (членство платное), но, как обычно, полно утекших спек. Спецификации не сильно помогут, вы не представляете себе уровень сложности шины PCIe на всех уровнях. Даже развести плату будет непросто, там накладываются требования не только на ширину проводников и зазоры между ними, но и требуется выравнивание длин между ними в жёстких пределах. Корпуса для работы с этой шиной только BGA, что практически исключает ручную пайку и печатные платы на коленках. Я не говорю, что это всё невозможно (мы разрабатывали устройства на шине PCIe), но это занятие дорогостоящее, трудно отлаживаемое, требует много времени и сил.

sabir писал(а):
Я как раз иного мнения на этот счет, вся "тяжесть" написания драйвера на 95% обязана закрытости железки.

В случае видеокарт это совсем не так. В них уровень сложности железа запредельный.

sabir писал(а):
А что сложного в видеокарте, ее ядра на порядки проще CPU, просты как цигане на вокзале.

Во-первых, сложна их организация. Это не просто линейный массив ядер. Попробуйте попрограммировать на CUDA, вы быстро убедитесь в этом. Во-вторых, сложно взаимодействие CPU и GPU, если речь идёт об аппаратном ускорении, то в данном случае помимо массива ядер присутствует сложная аппаратная прослойка между CPU и ядрами GPU, которая представляет специфичную для графики информацию, например, шейдеры.

sabir писал(а):
И все же, Вы работаете в ПЛИС, сколько независимых и очень простых ядер (add sub mul div shr shl rol ror and or neg not mov inc dec) можно реализовать на 100 долларовой плиске

Всё зависит от сложности отдельного ядра. Например, Удо Мёллер на плате DE0-Nano (стоимостью около 70$) реализовал 32-битный микропроцессор NS32532 (назвав свою реализацию следующим поколением – NS32632). Ядер сложностью с микроконтроллер сери PIC (без периферии), полагаю, можно разместить до десятка. Другое дело, что все эти ядра будут работать на частотах максимум в несколько десятков мегагерц, что дискредитирует всю затею по ускорению и переводит всё в область хобби.

sabir писал(а):
чисто ради любопытства, я читал про FPGA которые прошиваются только один раз и логика работы уже не может быть изменена, но зато там уже не логические связи, а железные, типа что то там плавиться или как то так, я просто совсем не в теме.

Между ними нет принципиальной разницы в быстродействии. В перепрограммируемых ПЛИС связи тоже аппаратные, хоть и логические. Однократно программируемых ПЛИС большой сложности не делают.

sabir писал(а):
А есть ли разница между ПЛИС и FPGA, или FPGA это разновидность ПЛИС

Если абстрагироваться от тонкостей, то как правило, ПЛИС – это просто русский эквивалент аббревиатуры FPGA.

sabir писал(а):
про FPGA я читал неплохие отзывы, что якобы они чуть ли не конкуренцию составляют микроконтроллерам с фиксированной логикой или это рекламная замануха, типа дай нам денег, не парься, просто дай денег.

Микроконтроллерам – да, т.к. микроконтроллеры сами работают на небольших частотах, и если требуется какая-то сложная работа (например, перестановка бит в реальном времени), то микроконтроллер с ней может не справиться, а для ПЛИС это вообще не проблема. Всё зависит от характера задач, которые необходимо решать и от требуемой скорости.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 52 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB