Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Графика и видео » Что мы знаем и не знаем про графику


Что мы знаем и не знаем про графику

Сообщений 1 страница 7 из 7

1

Нуу, раньше, когда были кинескопы, надо было управлять развёрткой, а для этого нужны были высокочастотные детали, и это было проблемой.
Для формирования изображения нужна видеопамять и раньше её столько не было, сколько сейчас есть.

На текущий момент есть три типа видеосистем:
1) с видеоадаптером интегрированным на материнскую плату компьютера
2) с отдельной видеокартой
3) с видеопроцессором прямо на кристалле основного процессора

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

Основные производители - Intel, Amd, NVidia,
и с документированием у них у всех надо разбираться. Мне кажется, что
наиболее открыта документация на продукты Amd
а будущее за Intel (в связи с массовостью).
Учить не хочется ни то ни другое, а API для OS надо делать. VESA-то давно и полностью морально устарела.

Для меня, например, является загадкой как происходит синхронизация между основными ядрами ЦПУ и ядрами видеопроцессора.

Особенно весело, когда видеопроцессоров несколько, а монитор один, и рендерить в один буффер они могут параллельно
(т.е. надо синхронизировать не только несколько ядер CPU, но и несколько процессоров GPU, загрузку шейдеров и их работу)

2

на один монитор -сколько бы ядер не было хоть 300 хоть 500 внутри gpu разницы нету. это как обычные потоки.
работу они выполняют поралельно но писать в текущий момент времени может только один остальные ждут.
так в принцепе везде построена работа с ГИ

CUDA знатная разработка. руки не доходят опробовать.

3

Мы знаем всё.
http://ru.osdev.wikia.com/wiki/Видеоадаптеры

Для меня, например, является загадкой как происходит синхронизация между основными ядрами ЦПУ и ядрами видеопроцессора.

Да там просто - обычный кольцевой буфер. Драйвер OpenGL формирует список команд.  Указывает GPU где лежит новый буфер. Тот вытягивает их к себе в видео память.
Модель управления от главнокомандующего к подчиненным, тип синхронизации по времени.
Главнокомандующий то бишь в нашем случае CPU и видео-драйвер формирует команды, GPU с сопроцессорами беспрекословно выполняют. Главно командующий нарезает план по GPU.
Так как модель управления не предусматривает обратной связи, то проверка идёт не по прерываниям, а по системному секундомеру.
Обычная карусель со слотами задержки. Блок управления в драйвере решает когда, что проверить модель подстраиваемая. Работает через фильтр Кальмена.
GPU имеет DMA который сам подтягивает нужные ресурсы из системной памяти в видео память.
А как разные GPU не мешают друг другу? Так работают они с разными участками памяти. Достигается за счёт использования страниц.
За распределения страниц как в системной так и видео памяти отвечает видео-дрйвер.

Если говорить коротка то в видео под система представляет из себя ядро мини ОС, но с более сложными и экзотическими алгоритмами планирования и распределения ресурсов.

4

на один монитор -сколько бы ядер не было хоть 300 хоть 500 внутри gpu разницы нету. это как обычные потоки.
работу они выполняют поралельно но писать в текущий момент времени может только один остальные ждут.

Вот только не надо АЛУ обзывать ядрами как это делает ATI.
Вообще-то не ждут. У каждого ядра есть свой КЭШ. А каждый чип памяти на видеокарте имеет независимый канал. 
Но ресурсы железа ограничены. Поэтому одновременно все ядра писать не могут. Так что одновременная запись поддерживается только от 4 до 16 в топовых каратах.
И плюс сложности распараллеливания. Поэтому некоторые ядра работают по конвейерной схеме, без сохранения данных во внешнюю память а передовая данные от одного к другому.

5

Вообще-то не ждут. У каждого ядра есть свой КЭШ. А каждый чип памяти на видео карте имеет независимый канал

это спорный момент. в действительности просто смотря что понимать под пишут и синхронизируют и что под ждут.
если поставить вопрос ребром - могут ли одновременновсе ядра писать данные для отображения на монитор?
то ответ нет, потому что один будет рисовать зебру а второй тигра а получится тибра) значит все же ждут.
но если смотреть простаивают ли они?
то тоже ответ нет.

6

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

7

Вот пара статей с IXBT о архитектуре ещё были на 3D-news но искать лень.
http://www.ixbt.com/video3/r600-part1.shtml
http://www.ixbt.com/video3/rad.shtml
http://www.ixbt.com/video3/gf100.shtml
http://parse.ele.tue.nl/system/attachme … 1423137251
https://3dnews.ru/924460
Вот про эту страничку совсем забыл
https://code.msdn.microsoft.com/windows … e-45c11e6d


Вы здесь » Ремесло программиста » Графика и видео » Что мы знаем и не знаем про графику