DirectDraw и видеопамять

Темка сугубо для заинтересованных и имевших(имеющих) опыт написания приложений под DirectDraw (и в принципе Direct3D).

Вот тут

http://www.old-games.ru/forum/threads/quake.20691/page-28

мы мемного поофтопили. Если коротко, уважаемый nop утверждал, что получаемая от DirectDraw память это видеопамять. У меня на этот счет возникли сомнения. Решил написать небольшое тестовое приложение.

Коротко - приложение инициализирует DirectDraw, эксклюзивно-полноэкранно (чтобы не было проблем с локом первичной поверхности), создает три DirectDraw 7 поверхности: первичную (с присоединенным к ней бэк поверхностью) и офскрин поверхность. После приложение лочит поверхности и считывает атрибуты полученного региона памяти. Весь вывод идет через OutputDebugString, для его перехвата можно воспользоваться Debug View от Руссиновича.

Цитата из предыдущего обсуждения:

На памяти действительно есть PAGE_WRITECOMBINE. Но вот PAGE_NOCACHE на них нет. Мне кажется это уже говорит о многом.

Приложение собрано под 64 разрядные ОС в Visual C 2013. Из командной строки. Кмд файл приложил. Собрать 32 разрядную версию не составит труда. Тестировал на 64 разрядной Windows 8.1.

Тут конечно не совсем честно выходит. Вполне возможно, что на 9X/ME действительно отдавалась видеопамять.

TODO: Пока приватно обсуждали с nop этот вопрос, возникла мысль профилировать обращение к этому региону памяти. Взаимодействие с этими регионами, если это действительно видеопамять, будет медленней, чем с обычной RAM. То есть написать небольшой сравнительный тест по чтению-записи из этих залоченных регионов и обычной памяти.

 

А ведь вначале у кое-кого были сомнения, что вообще можно Primary залочить Но да, выглядит не как видеопамять.

Но.
https://msdn.microsoft.com/pt-br/sqlserver/ff549599

http://www.falloutsoftware.com/tutorials/dd/dd6.htm

http://www.comscigate.com/tutorial/ajay/Part 1/java game programming tutorial/modena.intergate.ca/personal/iago/dirxtut/dd3.htm

http://www.hugi.scene.org/online/coding/hugi 16 - coddraw.htm

Кстати, можно попробовать для сравнения создавать только DDSCAPS_PRIMARYSURFACE без прочих флагов.

 

По поводу сомнений, было дело, да.

Сомневаться когда не совсем ясно назначение и профит свойственно. Я до сих пор не вижу большого смысла в этом. Зачем самостоятельно реализовывать функционал блиттинг функции и заморачиваться с конвертацией представления пикселей? Если действительно можно получить при локе видеопамять, то в полноэкранном приложении используя самостоятельный блиттинг мы бы банально потеряли возможность аппаратного флиппинга и аппаратной же конвертации пиксельных форматов. А еще флип быстрее в разы, чем самостоятельный даже супер оптимизированный non temporal блиттинг. А потом все те же сомнения, что механизм - свой бэкбуфер в RAM + лок на праймари + плюс свой блиттинг будет быстрее, чем бэкбуфер на стороне DDraw (не суть где) + лок на бэкбуфер (например write only) + блит (который вполне возможно аппаратный)/флип средствами рантайма. Да еще и в первом случае заморачиваться с VSync... Бррр...
Я все таки исхожу из того, что разработчики рантайма и драйверов лучше знают, как работает их рантайм и оборудование. Это их работа. Я понимаю, что может быть всякое. Но создание собственных велосипедов-костылей обычно до добра не доводит

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

А что конкретно по ссылкам посмотреть? Три последних это какие-то туторы. У меня у самого есть несколько статеек по DDraw за моим авторством
Первая ссылка, это явно реализация DDI. Проблема только в том, что нынче у нас WDDM. Если говорить о внутренней реализации DDraw и DDI то проще взять исходные тексты проекта OpenNT http://opennt.net/. Код у этих ребят базируется на "утекших" исходниках ядра NT и ее подсистем. Там есть исходный код DDraw и некоторых драйверов.

Кстати, возможно именно из-за того, что у нас WDDM при локе поверхности мы получаем RAM. Было бы интересно запустить это приложение на Win9X (или даже например в XP) и посмотреть на результаты. И конечно это должны быть не виртуальные машины. Другое дело, что тогда его нужно пересобрать 32 разрядную версию и соответствующим тулсетом.

--- добавлено 3 дек 2015, предыдущее сообщение размещено: 3 дек 2015 ---

Я тут еще подумал. У себя пример запускал на интегрированном интелловском видео. У него своей памяти нет. Нп досуге попробую еще запустить на дискретной карте.

 

Эх.. Ну а зачем я тогда как раз это объяснял еще в Квейковской теме?

Может, вы еще верите, что оптимизирующие компиляторы лучше вас знают, как работает ваш алгоритм?
А с какого, собственно, перепугу разработчикам писать идеальную реализацию а не ту, которая даст маркетологам повод поставить галочку на коробке?
Шина между видеокартой и остальной частью системы как бы одна и та же, независимо от того, по чьей инициативе по ней бегают байтики - процессора или железа видеокарты, при этом процессоров нужно протестировать 2-3 штуки и разброс в скорости у них тоже примерно такого же плана, в то время как разброс возможностей, скоростей, версий/багов драйверов видеокарт может быть где-то на порядок больше.

--- добавлено 3 дек 2015, предыдущее сообщение размещено: 3 дек 2015 ---

А также потеряли "возможность" писать N ветвей кода в зависимости от того, какая из этих конвертаций какой карточкой поддерживается, и "возможность" нарваться на супербыстрый софтовый блиттинг, написанный рандомным индусом с использованием абстракции "putpixel", либо хардварный, но на видеопроцессоре с частотой в 10 раз меньше чем у CPU, либо подвисающий при некоторых параметрах на некоторых материнках.
Одна карточка поддерживает ColorKey, другая нет. Одна фильтрует при ресайзе, другая нет..
А я еще пробовал оверлеи использовать, где ресайз и позиционирование у всех (вроде) аппаратные и бесплатные, что уже действительно привлекательно. Там просто ад. И цветовые пространства разные(у Cirrus Logic есть RGB, у остальных нет), и ограничения на размеры, и, конечно, наличие фильтрации..
Ну и кстати, софтово блитить в находящийся в той же видеопамяти бэкбуффер тоже никто не мешает.

 

Вы не поняли. То, что вы написали я прочел. Но это не значит, что я разделяю это мнение.
На мой взгляд это крайности и вы очень сильно утрируете. Исходить из того, что "все-индусы-один-я-дартаньян" по меньшей мере недальновидно и излишне самоуверенно.

На счет компиляторов и оптимизации я придерживаюсь принципа классиков - preemptive optimization is evil. Не очень понимаю связь алгоритма с реализациями вспомогательных библиотек. Исходя из этой логики можно вообще все переписать. И Direct3d. И OpenGL. И саму ОС. Потому, что компиляторы ничего не знают, библиотеки пишут индусы, а железо виснет Вообще все.
Кроме того, компилятор лучше среднестатистического программиста умеет спаривать код под конкретный процессор. Если вы сторонник религии ассемблера, то это вам в царство KolibriOS
И это в общем то обычное дело, когда разное железо имеет разный функционал. Наличие нескольких кодпафов. Но отказываться от аппаратного ускорения только потому, что кто-то его умеет, а кто то нет не совсем правильно как по мне. Смиритесь или уходите писать на консоли Там все устаканено. Ну да ладно. С лирикой завязываю. Теперь о деле:

Это то, что я получил на NVidia 980gtx, Win 7 x64. PAGE_NOCACHE тоже нет. Но и WRITECOMBINE пропал. Надо будет собраться и дописать тест производительности, чтобы проверить окончательно, что это.

ps К слову. Указатель на регион памяти у меня режется. Не верный форматер.

 

Я устал объяснять, продолжайте пропускать в написанном мною всё, что вам не нравится. Я набил шишки на этом лет 15 назад, делая для себя 2D движки. Пришел к вполне конкретному выводу, что ничего, кроме багов и потраченного времени, DDraw "акселерация" не дает и написал всё в софте. Высвобожденное от возни с тестированием видеокарт время намного полезнее потратить на написание ассемблерного кода под MMX, который не подведет никогда. Я не тыкаю пальцем в небо, а пытаюсь пересказать давно забытый практический опыт. Но вам, конечно, в 2015-м виднее.
Да нет у вас сейчас скорее всего ни настоящей видеопамяти, ни 8-битных видеорежимов, всё эмулируется. С точки зрения security и cost savings это правильно.
Исходники смотрел. Заниматься нет времени, возможно через несколько недель появится хоть сколько-то. Но в любом случае нужно поднимать legacy систему, а у меня из кучи барахла ничего пока не удалось оживить.

 

Ох. И снова вы делаете странные допущения. К чему это упоминание то о 15 годах прошлого? Обычно у взрослых людей желание "меряться" годами обратно пропорционально их возрасту...
Просто для информации. Только официально (с момента трудоустройства) я занимаюсь программированием 20 лет. DirectX, как вы наверное поняли, входит в резюме.
Не стоит видеть во всех индусов. Допускайте наличие альтернативного мнения. Тем более, что практика пока-что ваши утверждения не подтвердила. Но тем не менее мне интересно и я дествительно пытаюсь найти подтверждения. Тем более, что в определенной степени рационализм в ваших измышлениях таки присутствует.
А я просто сторонник тестирования и голых фактов

 

ddraw в каждой версии виндовс реализован по своему. Откуда собсно и имеем все проблемы и достижения. Это факт.
Видеопамять мапится в адресное пространство. Классический вариант с ней так и работает. Но тут есть тонкость, когда этой памяти у собственно видеокарты своей нет или её маловато. Так как принципиальной разницы в этом случае уже нет. Полагаю, что на этом в споре можно поставить точку по вопросу с чем и кто работает.

 

У меня нет на руках исходных текстов DDraw, только от NT4, потому о рассуждениях о реализациях я воздержусь.
То, что какое то объем памяти будет мапится на физические адреса это вне всякого сомнения. Это можно увидеть в том же диспетчере устройств, причем не зависимо от версии Windows. Вопрос изначально стоял в другом.
То, что поведение DirectDraw наверняка меняется это так же очевидно, хотя бы потому, что со временем меняется архитектура драйвера.
Точки есть смысл ставить только тогда, когда есть конкретные ссылки на документацию или результаты тестирования я полагаю. Или форум не для того существует, чтобы что-то обсуждать?
На счет враппера, можно ссылки на документацию?

 

@vedmysh, Сначала вы не знали, что видеопамять мэпится в системное адресное пространство(в том числе и для доступа в нее процессора), ни что можно залочить primary.

Вам объяснили и показали.
Теперь вы это признали, но все равно у вас выходит что почему-то правы были вы и еще доказательств противного недостаточно Давайте вы дальше уже сами закончите это увлекательное расследование очевидных для других вещей .
Если Win GDI уже дает возможность создавать битмэпки и блитить их на экран, с конверсией цвета и поддержкой 2D акселерации, то зачем столько шумихи вокруг DirectDraw? И что в его названии значит слово 'Direct'? Подсказка: англоязычная статья в википедии

 

По сути вы ничего не объясняли. А безаппелляционно заявили. Вижу, вас это так сильно обидело, что вы мало того, что упомянули какой вы молодец и писали 15 лет назад "2д движки для себя", так еще и припомнили мне мои вопросы.
Так я и не возражаю. Наоборот, я признателен, что вы на это акцентировали внимание и заставили меня проанализировать происходящее.
По поводу лока первичной поверхности я до сих пор считаю это нецелесообразным.
Причины я излагал выше. Кстати, на досуге обязательно загляну как поступает winquake и отпишусь. Дело в другом. Я ничего не утверждал, а задавал вопросы, в отличие от вас. Ну да ладно. Не суть. Вы уже взрослый товарищ. Надеюсь.
Слово Direct может значит что угодно. Это всего лишь маркетинг. А википедию по факту могут писать такие же опытные люди как и вы Решает официальная документация.

К сути. Я подправил тест. Мелкие исправления (вроде форматтера и юникод функций). Добавил простейший бенчмарк по работе с памятью. Код собирал без оптимизации во избежании помощи со стороны компилятора. Тесты исключительно сравнительные. Добавил так же для сравнения RAM регион.

Чтение из памяти поверхностей очень медленное. Запись сравнима с RAM. Это на интегрированном интеловском видео.

 

Я рад, что вы пришли к тому, о чем я вам уже "безапелляционно заявлял", написав несколько страниц технических деталей, при этом, как ни странно, "ничего не объясняя".
Вроде бы охотно делился информацией, пока вы не начали, с очевидным отсутствием собственного практического опыта конкретно в этой области, спорить с фактами.
Даже редакторы википедии против вас заговор устроили