Совместимость с DirectX
Jurgis Armanavichius
Почитал я тут всяческие новости на предмет дальнейшего развития системы
Windows и подумал, что существует опасность изъятия или существенного
ухудшения характеристик OpenGL под Виндой в будущем. Паниковать я, в
общем-то, пока не собираюсь, но "соломку подстелить" хотелось бы :-)
Поэтому возникла парочка вопросов. (Мне актуальны вопросы рисования
только 2D, плоская картинка.)
1. Мне нужно рисовать "ленту самописца". Т.е. прямоугольник, данные
в который поступают в виде вертикальной линии справа, а предыдущее
содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
сдвига картинки в окне, верно?
Вопрос: имеется ли аналогичная быстрая функция в DirectX? Т.е. не
читать окно в системную память, а затем писать обратно на пиксель
Уже и на пиксель левее, а сдвигать данные прямо в графической
видеопамяти (фрэймбуфере).
2. Для другого режима рисования я применяю метод с двумя списками:
список координат вершин цепочки трапеций и список цветов этих вершин.
Координаты у меня не меняются (раз вывел при установке текущего режима
и все), а цвета - меняются. Тут я получаю экономию в виде пересылки на
рендеринг только списка цветов, который по размерам гораздо меньше, чем
полный список координат вершин с цветами.
Вопрос: имеется ли аналогичная возможность в DirectX? Т.е. один раз
задать список координат вершин, а потом на каждом кадре задавать только
список цветов этих вершин.
Юргис
Serguey Zefirov
JA> в который поступают в виде вертикальной линии справа, а предыдущее
JA> содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
JA> это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
JA> сдвига картинки в окне, верно?
Это уж как реализуют. ;)
JA> Вопрос: имеется ли аналогичная быстрая функция в DirectX? Т.е. не
JA> читать окно в системную память, а затем писать обратно на пиксель
JA> Уже и на пиксель левее, а сдвигать данные прямо в графической
JA> видеопамяти (фрэймбуфере).
Пропускная способность памяти ATI Radeon X1900 примерно 50GB в секунду.
Даже если реализовывать копированием в одну текстуру, а затем сдвиг в другую,
все равно будет очень быстро.
JA> Вопрос: имеется ли аналогичная возможность в DirectX? Т.е. один раз
JA> задать список координат вершин, а потом на каждом кадре задавать только
JA> список цветов этих вершин.
Да.
VertexBuffer можно побить на две части, в одной будут вершины, в другой -
цвета.
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Jurgis Armanavichius
Thu Aug 24 2006 13:11, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> 1. Мне нужно рисовать "ленту самописца". Т.е. прямоугольник, данные
JA>> в который поступают в виде вертикальной линии справа, а предыдущее
JA>> содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
JA>> это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
JA>> сдвига картинки в окне, верно?
SZ> Это уж как реализуют. ;)
Да, логично :-)
JA>> Вопрос: имеется ли аналогичная быстрая функция в DirectX? Т.е. не
JA>> читать окно в системную память, а затем писать обратно на пиксель
JA>> Уже и на пиксель левее, а сдвигать данные прямо в графической
JA>> видеопамяти (фрэймбуфере).
SZ> Пропускная способность памяти ATI Radeon X1900 примерно 50GB в секунду.
SZ> Даже если реализовывать копированием в одну текстуру, а затем сдвиг в
SZ> другую, все равно будет очень быстро.
Хм... Это как? Создать текстуру-заглушку, скопировать в нее текущий
кадр из фрэймбуфера, а потом скопировать из этой текстуры прямоугольник
на один пиксель Уже обратно во фрэймбуфер? Интересная мысль! Я как-то
не догадался :-) Большое тебе спасибо за совет!
JA>> Вопрос: имеется ли аналогичная возможность в DirectX? Т.е. один
JA>> раз задать список координат вершин, а потом на каждом кадре задавать
JA>> только список цветов этих вершин.
SZ> Да.
Отлично!
SZ> VertexBuffer можно побить на две части, в одной будут вершины,
SZ> в другой - цвета.
Еще раз большое тебе спасибо! Попробую разобраться с этим моментом.
Hаверное, можно почитать про это дело в MSDN-е? Вот пойму-ли?... ;-)
Юргис
Jurgis Armanavichius
Попробовал. Чё-то не пашет... Я взял за основу пример Vertices.cpp из
тутора N2 DirectX 9. Создаю два буфера вершин: один формата D3DFVF_XYZ,
другой - D3DFVF_DIFFUSE.
struct CUSTOMVERTEX_1
{
FLOAT x, y, z; // The transformed position for the vertex
};
struct CUSTOMVERTEX_2
{
DWORD color; // The vertex color
};
#define D3DFVF_CUSTOMVERTEX_1 D3DFVF_XYZ
#define D3DFVF_CUSTOMVERTEX_2 D3DFVF_DIFFUSE
Далее в функции InitVBs() делаю
g_pd3dDevice->CreateVertexBuffer( 3*sizeof(CUSTOMVERTEX_1),
0, D3DFVF_CUSTOMVERTEX_1,
D3DPOOL_DEFAULT, &g_pVB1, NULL )
g_pd3dDevice->CreateVertexBuffer( 3*sizeof(CUSTOMVERTEX_2),
0, D3DFVF_CUSTOMVERTEX_2,
D3DPOOL_DEFAULT, &g_pVB2, NULL )
Я тут убрал проверку ошибок, чтобы не загромождать текст, но она есть.
Затем заполняю их двумя массивами структур: массивом x,y,z с плавающей
точкой и массивом color типа DWORD. Затем в рендеринге делаю:
g_pd3dDevice->BeginScene()
g_pd3dDevice->SetStreamSource( 0, g_pVB1, 0, sizeof(CUSTOMVERTEX_1) );
g_pd3dDevice->SetStreamSource( 1, g_pVB2, 0, sizeof(CUSTOMVERTEX_2) );
g_pd3dDevice->SetFVF( D3DFVF_CUSTOMVERTEX_1 | D3DFVF_CUSTOMVERTEX_2 );
g_pd3dDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, 1 );
g_pd3dDevice->EndScene();
Запускаю - ничего не рисуется... А в исходном примере рисуется цветной
треугольник. В чем могут быть грабли? Может нужно как-то задать число
этих самых StreamSource'ов?
(Я попробовал добавить в первую структуру компонент rhw и ее тип поменять
на D3DFVF_XYZRHW. Тогда треугольник каким-то непонятным темным цветом уже
рисуется, но нормальных цветов R,G,B все-равно не воспринимает. Т.е. первый
буфер в рендеринге точно учавствует, а второй, видимо, нет.)
Юргис
Serguey Zefirov
JA> From: "Jurgis Armanavichius" <jur...@medelkom.com>
JA> Привет!
JA> Попробовал. Чё-то не пашет... Я взял за основу пример Vertices.cpp из
JA> тутора N2 DirectX 9. Создаю два буфера вершин: один формата D3DFVF_XYZ,
JA> другой - D3DFVF_DIFFUSE.
JA> struct CUSTOMVERTEX_1
JA> {
JA> FLOAT x, y, z; // The transformed position for the vertex
JA> };
JA> struct CUSTOMVERTEX_2
JA> {
JA> DWORD color; // The vertex color
JA> };
IDirect3DDevice9->CreateVertexDeclaration, SetVertexDeclaration - посмотри.
JA> #define D3DFVF_CUSTOMVERTEX_1 D3DFVF_XYZ
JA> #define D3DFVF_CUSTOMVERTEX_2 D3DFVF_DIFFUSE
FVF слегка устарел. Кстати, мои знания тоже. ;)
А зачем ты вообще переписываешь хорошую вещь на DirectX?
Andrew Aksyonoff
[ 24 Aug 06, 10:06 ] Jurgis Armanavichius -> All:
JA> Вопрос: имеется ли аналогичная быстрая функция в DirectX? Т.е. не
StretchRect
JA> задать список координат вершин, а потом на каждом кадре задавать
JA> только список цветов этих вершин.
vertex streams
--
shodan
Jurgis Armanavichius
Thu Aug 24 2006 20:21, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> Вопрос: имеется ли аналогичная быстрая функция в DirectX?
AA> StretchRect
Увы... Вот что говорит SDK: "Stretching is not supported between source
and destination rectangles on the same surface." Пока наблюдается только
вариант, который предложил коллега Serguey Zefirov, т.е. копировать в
какую-то другую структуру и потом - обратно. Думаю, что эта его идея
вполне хороша, т.к. если создать вспомогательную поверхность (или еще
что-нибудь подобное), то копирование в нее должно быть быстрее, чем
копирование "вручную" моим приложением.
JA>> задать список координат вершин, а потом на каждом кадре задавать
JA>> только список цветов этих вершин.
AA> vertex streams
Я сейчас как раз с этим воюю. Пока не побеждаю... :-) Hе получается
задействовать второй буфер. После добавления SetStreamSource второго
буфера - никакой реакции, рисуется только первый...
Юргис
Jurgis Armanavichius
Thu Aug 24 2006 22:29, Serguey Zefirov wrote to Jurgis Armanavichius:
SZ> IDirect3DDevice9->CreateVertexDeclaration, SetVertexDeclaration -
SZ> посмотри.
Большое спасибо! Посмотрю. Если чего не пойму - можно я еще тебя
помытарю?
JA>> #define D3DFVF_CUSTOMVERTEX_1 D3DFVF_XYZ
JA>> #define D3DFVF_CUSTOMVERTEX_2 D3DFVF_DIFFUSE
SZ> FVF слегка устарел. Кстати, мои знания тоже. ;)
SZ> А зачем ты вообще переписываешь хорошую вещь на DirectX?
Коротко не получится, расскажу подробно.
Работай я на PC-шке - не парился бы! Hо дело в том, что я разработчик,
электронщик-программист (мои творения можно посмотреть по адресу: www
плюс домен моей почты). Hедавно мы применили PC-совместимую материнскую
плату, довольно компактную, ориентированную на встроенные применения. Hа
этой плате крутится Windows XP, под которым работает наше полнооконное
приложение. Такое решение сразу позволило нам решить множество проблем
(слабость простых микроконтроллеров, применявшихся до этого, разработка
интерфейса пользователя, которую теперь можно сделать человеческими
средствами, простая и лёгкая поддержка USB 2.0, возможность перехода
на Линукс и т.д.).
Снаружи наш прибор выглядит как типичный медицинский прибор для УЗИ:
экран, окно для вывода ультразвуковой картинки, различные дополнительные
надписи, кнопки управления и т.п. Вывод самой картинки пока производится
DirectX, но очень примитивно, "в лоб". Сейчас я разрабатываю новую систему
вывода графики посредством OpenGL. Делать эту работу на таком качественном
инструменте - одно удовольствие :-) Тем более, что ничего сложного мне и
не нужно. Единственное серьезное требование - быстродействие при довольно
слабеньком процессоре (третий Пентиум).
Hо мне хотелось бы сохранить возможность безболезненного портирования моей
системы визуализации ультразвука на DirectX. Просто на всякий случай, т.е.
"соломку подстелить" :-)
Вот примерно так.
Юргис
Serguey Zefirov
JA> моей системы визуализации ультразвука на DirectX. Просто на всякий
JA> случай, т.е.
JA> "соломку подстелить" :-)
Hо зачем тебе стелить соломку - мне непонятно.
DirectX не для белых людей, он исключительно для game programmers.
Я совершенно серъезен.
Jurgis Armanavichius
Fri Aug 25 2006 14:02, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> Hо мне хотелось бы сохранить возможность безболезненного портирования
JA>> моей системы визуализации ультразвука на DirectX. Просто на всякий
JA>> случай, т.е. "соломку подстелить" :-)
SZ> Hо зачем тебе стелить соломку - мне непонятно.
Тут такая заковыка... Понимаешь, сейчас моя приборная плата вполне прилично
поддерживает OpenGL, не все расширения, конечно, но спецификации 1.1 и 1.2
она поддерживает на 100%, а 1.3 и 1.4 - примерно наполовину. Таким образом,
я могу спокойно разрабатывать свои приложения.
Однако, я не могу чувствовать себя вполне комфортно потому, что у меня
не стандартная PC-шная плата, а компактная, ориентированная на встроенные
применения. Вполне может случиться так, что эту плату снимут с производства
и мне придется подбирать другую. В этой области положение с выбором плат
достаточно тяжелое, очень может быть, что другая плата будет поддерживать
только DirectX, а OpenGL - кое-как или совсем не будет поддерживать.
Вот в этой ситуации ( тьфу-тьфу-тьфу! ) мне и пригодится "соломка" :-)
Поэтому сейчас я разрабатываю отдельную DLL-ку визуализации, которая
работает через OpenGL. В случае неблагоприятных обстоятельств я смогу
заменить ее на DLL-ку, работающую через DirectX.
Кстати, еще хотел спросить, вывод прямоугольной BMP-шки на экран (без
всяких эффектов, просто копирование) быстрее всего делать посредством
обновления текстуры или применять что-то другое (копированием блока
пикселов, например)?
SZ> DirectX не для белых людей, он исключительно для game programmers.
SZ> Я совершенно серъезен.
Черт его знает... Штука, вроде, мощная, но, как почти все у M$, что-то
там все через ж..у :-) Сложно, неудобно, не интуитивно понятно... Хотя,
вполне может быть, что потратив серьезные усилия, ее можно освоить на
уровне гораздо выше среднего. Только мне на это времени нет :-)
Юргис
Serguey Zefirov
JA> не стандартная PC-шная плата, а компактная, ориентированная на встроенные
JA> применения. Вполне может случиться так, что эту плату снимут с
JA> производства
JA> и мне придется подбирать другую. В этой области положение с выбором плат
JA> достаточно тяжелое, очень может быть, что другая плата будет поддерживать
JA> только DirectX, а OpenGL - кое-как или совсем не будет поддерживать.
JA> Вот в этой ситуации ( тьфу-тьфу-тьфу! ) мне и пригодится "соломка" :-)
Я тбя спрошу прямо и честно - тот WinXP, который ты ставишь на свою плату, он
полностью лицензионный?
Так вот, это гораздо большая беда, чем проблемы с видеоплатой. За нее тебя
могут ударить уже сейчас и тебе придется переносить приложение на Linux. DX на
Linux нет.
Поедем дальше.
Ты, скорее всего, используешь встроенный в материнскую плату видеоконтроллер.
Он скорее всего, интеловский (40% ВСЕХ видеоконтроллеров). Видеоконтроллеры от
Intel имеют открытые исходники и не потеряют поддержки OpenGL уже никогда.
JA> Поэтому сейчас я разрабатываю отдельную DLL-ку визуализации, которая
JA> работает через OpenGL. В случае неблагоприятных обстоятельств я смогу
JA> заменить ее на DLL-ку, работающую через DirectX.
Умеренно настоятельно рекомендую пересмотреть риски. ;)
JA> Кстати, еще хотел спросить, вывод прямоугольной BMP-шки на экран (без
JA> всяких эффектов, просто копирование) быстрее всего делать посредством
JA> обновления текстуры или применять что-то другое (копированием блока
JA> пикселов, например)?
Увы, не знаю. DX я изучил на уровне
SetTexture/SetVertexBuffer/SetIndexBuffer/SetVertexShader/SetPixelShader/Draw(I
ndexed)Primitive во время работы в геймпрограмминге.
Если какой эффект на шейдерах сделать - это я запросто. ;)
Jurgis Armanavichius
Fri Aug 25 2006 18:30, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> Вот в этой ситуации ( тьфу-тьфу-тьфу! ) мне и пригодится "соломка" :-)
SZ> Я тбя спрошу прямо и честно - тот WinXP, который ты ставишь на свою
SZ> плату, он полностью лицензионный?
Отвечу не менее прямо :-) Каждый отгруженный прибор имеет индивидуальную,
честно купленную копию Win XP. У нас на производстве специально проводят
процедуру активации установленной Винды, чтобы у заказчика не возникало
проблем.
SZ> Так вот, это гораздо большая беда, чем проблемы с видеоплатой. За нее
SZ> тебя могут ударить уже сейчас и тебе придется переносить приложение на
SZ> Linux. DX на Linux нет.
Графика интегрированная, производства VIA/S3 Graphics, работает на удивление
хорошо. Шустренько так под OpenGL трёхмерный мир рисует :-)
А про Линукс я думаю неустанно :-) Только опыта у меня в нем ноль...
Причем, вопрос даже не в том, чтобы полностью сделать на Линуксе наш
прибор (это я как-нибудь освоил бы, нам очень немного от системы нужно).
Hо дело еще в том, чтобы в дальнейшем расширять систему, добавлять
различные вспомогательные приложения пользователя. А вот тут я уже
в полном ауте...
SZ> Поедем дальше.
SZ> Ты, скорее всего, используешь встроенный в материнскую плату
SZ> видеоконтроллер.
Да, конечно.
SZ> Он скорее всего, интеловский (40% ВСЕХ видеоконтроллеров).
SZ> Видеоконтроллеры от Intel имеют открытые исходники и не потеряют
SZ> поддержки OpenGL уже никогда.
Сейчас с поддержкой OpenGL проблем нет, дал бы Бог, чтобы и дальше мы
могли применять это железо :-)
Hо на будущее... Вдруг эту плату снимут с производства? Вот придет завтра
письмо с Тайваня, что, мол, звиняйте, больше не могем... Катастрофа...
JA>> Поэтому сейчас я разрабатываю отдельную DLL-ку визуализации, которая
JA>> работает через OpenGL. В случае неблагоприятных обстоятельств я смогу
JA>> заменить ее на DLL-ку, работающую через DirectX.
SZ> Умеренно настоятельно рекомендую пересмотреть риски. ;)
В глубине души я чувствую, что ты абсолютно прав и я напрасно боюсь :-)
Hо все-равно неспокойно как-то... Без соломки-то... ;-)
JA>> Кстати, еще хотел спросить, вывод прямоугольной BMP-шки на экран (без
JA>> всяких эффектов, просто копирование) быстрее всего делать посредством
JA>> обновления текстуры или применять что-то другое (копированием блока
JA>> пикселов, например)?
SZ> Увы, не знаю. DX я изучил на уровне
SZ>SetTexture/SetVertexBuffer/SetIndexBuffer/SetVertexShader/SetPixelShader/
SZ> Draw(I ndexed)Primitive во время работы в геймпрограмминге.
Ой, нижайше прошу прощения! Лоханулся я чуток... Я совершенно забыл указать,
что этот вопрос касался OpenGL! Т.е. у меня остался последний туманный вопрос
про эту самую BMP-шку под OpenGL. Подскажи, пожалуйста!
Юргис
Slava Bogdanov
JA>> портирования моей системы визуализации ультразвука на DirectX.
JA>> Просто на всякий случай, т.е. "соломку подстелить" :-)
SZ> Hо зачем тебе стелить соломку - мне непонятно.
SZ> DirectX не для белых людей, он исключительно для game programmers.
Да ладно. Его интерфейсы удобны и в других применениях.
Andrew Aksyonoff
[ 25 Aug 06, 18:16 ] Jurgis Armanavichius -> Serguey Zefirov:
JA> Черт его знает... Штука, вроде, мощная, но, как почти все у M$, что-то
JA> там все через ж..у :-) Сложно, неудобно, не интуитивно понятно...
о как!
а мужики и не знают.
--
shodan
Andrew Aksyonoff
[ 25 Aug 06, 00:36 ] Jurgis Armanavichius -> Andrew Aksyonoff:
JA> т.е. копировать в какую-то другую структуру и потом - обратно. Думаю,
обратно не надо. двойную буферизацию сделай.
JA> задействовать второй буфер. После добавления SetStreamSource второго
про декларации правильно сказали. см. п. "Streams, Using"
--
shodan
Jurgis Armanavichius
Fri Aug 25 2006 20:33, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> т.е. копировать в какую-то другую структуру и потом - обратно. Думаю,
AA> обратно не надо. двойную буферизацию сделай.
Ааа... Ты хочешь сказать, скопировать прежний кадр со сдвигом на один
пиксель влево во внеэкранную поверхность, добавить в ней справа мою
вертикальную линию, и переключить буфера? Здорово! Большое тебе
спасибо за гениальную подсказку! Точно! (Почему я не догадался?... ;-)
JA>> задействовать второй буфер. После добавления SetStreamSource второго
AA> про декларации правильно сказали. см. п. "Streams, Using"
Да, спасибо вам за подсказку! Обязательно попытаюсь разобраться в этом
вопросе (уже на следующей неделе). Ведь должно же работать, блин! :-)
Юргис
Jurgis Armanavichius
Fri Aug 25 2006 20:35, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> Черт его знает... Штука, вроде, мощная, но, как почти все у M$, что-то
JA>> там все через ж..у :-) Сложно, неудобно, не интуитивно понятно...
AA> о как!
AA> а мужики и не знают.
Так это те не знают, которые знают! А которые не знают, те наоборот,
знают, что они ни черта не знают ;-)
"Сложно, неудобно, ..." - это я писал исключительно про себя :-)
Hе, я с этой штуковиной работаю, но как те мыши, что с кактусом...
Когда недавно я познакомился с OpenGL - очень проникся. Изучая эту
интересную систему, я постоянно ловлю себя на мысли: "Во черт! А я
столько трахался, чтобы научиться в DX это делать!" ;-)
Юргис
Serguey Zefirov
JA> указать, что этот вопрос касался OpenGL! Т.е. у меня остался последний
JA> туманный вопрос про эту самую BMP-шку под OpenGL. Подскажи, пожалуйста!
BindTexture + glBegin(GL_QUAD/GL_TRIANGLES), ничего другого в голову не идет.
Serguey Zefirov
JA>>> Просто на всякий случай, т.е. "соломку подстелить" :-)
SZ>> Hо зачем тебе стелить соломку - мне непонятно.
SZ>> DirectX не для белых людей, он исключительно для game programmers.
В каких? И столь же удобны, как OpenGL?
Hе смешите меня.
Serguey Zefirov
JA>> там все через ж..у :-) Сложно, неудобно, не интуитивно понятно...
AA> а мужики и не знают.
Мужики все давно всё знают. Hе преувеличивай. С момента опубликования Кармаком
своего сравнения ничего не изменилось.
Andrew Aksyonoff
[ 25 Aug 06, 21:48 ] Jurgis Armanavichius -> Andrew Aksyonoff:
AA>> обратно не надо. двойную буферизацию сделай.
JA> Ааа... Ты хочешь сказать, скопировать прежний кадр со сдвигом на один
JA> пиксель влево во внеэкранную поверхность, добавить в ней справа мою
ну в общем да - держать два одинаковых буфера, из одного другого
со сдвигом копировать, при отрисовке использовать правильный "текущий".
--
shodan
Andrew Aksyonoff
[ 26 Aug 06, 13:34 ] Serguey Zefirov -> Andrew Aksyonoff:
AA>> а мужики и не знают.
SZ> Мужики все давно всё знают.
тебе виднее, не вопрос.
SZ> Hе преувеличивай. С момента опубликования Кармаком своего сравнения
SZ> ничего не изменилось.
специалиста (по MS bashing) видать за версту.
к несчастью, можно позаниматься и GL bashing - вспомнить поддержку
vertex-buffers, например, опоздавшую в GL где-то на год, что ли.
--
shodan
Andrew Aksyonoff
[ 25 Aug 06, 21:48 ] Jurgis Armanavichius -> Andrew Aksyonoff:
AA>> а мужики и не знают.
JA> Так это те не знают, которые знают!
мне в свое время на разбирательства с D3D8 понадобилось дня 3.
в документации все написано, конвейер вполне разумный.
JA> интересную систему, я постоянно ловлю себя на мысли: "Во черт! А я
JA> столько трахался, чтобы научиться в DX это делать!" ;-)
D3D не версии где-нибудь эдак 5, случаем? :)
--
shodan
Serguey Zefirov
SZ>> Мужики все давно всё знают.
А то ж.
SZ>> Hе преувеличивай. С момента опубликования Кармаком своего сравнения
SZ>> ничего не изменилось.
AA> специалиста (по MS bashing) видать за версту.
AA> к несчастью, можно позаниматься и GL bashing - вспомнить поддержку
AA> vertex-buffers, например, опоздавшую в GL где-то на год, что ли.
К удобству и интуитивности это имеет... какое отношение?
Andrew Aksyonoff
[ 26 Aug 06, 21:58 ] Serguey Zefirov -> Andrew Aksyonoff:
SZ>>> Мужики все давно всё знают.
AA>> тебе виднее, не вопрос.
SZ> А то ж.
из погреба всегда виднее.
AA>> к несчастью, можно позаниматься и GL bashing - вспомнить поддержку
AA>> vertex-buffers, например, опоздавшую в GL где-то на год, что ли.
SZ> К удобству и интуитивности это имеет... какое отношение?
да никакого.
твои "удобство" и "интутитивность" - в чистом виде субъективщина.
а я тупо по-быдляцки вспомнил - про объективно отсутствовавший важный
функционал.
и тем перевел, стало быть, дискуссию из плоскости "лично мне GL удобнее"
в плоскость объективных недостатков и преимуществ каждого.
так значительно менее интересно спорить - так что это я не подумав - извини!!!
--
shodan
Serguey Zefirov
AA>>> тебе виднее, не вопрос.
SZ>> А то ж.
Это в каком погребе ты такое разглядел?
AA>>> к несчастью, можно позаниматься и GL bashing - вспомнить поддержку
AA>>> vertex-buffers, например, опоздавшую в GL где-то на год, что ли.
SZ>> К удобству и интуитивности это имеет... какое отношение?
AA> да никакого.
AA> твои "удобство" и "интутитивность" - в чистом виде субъективщина.
Разве? Удобство и интуитивность меряются количеством строк кода.
К библиотекам это относится ровно так же, как и к языкам программирования.
О чем и был спич Кармака.
Ты его читал?
AA> а я тупо по-быдляцки вспомнил - про объективно отсутствовавший важный
AA> функционал.
AA> и тем перевел, стало быть, дискуссию из плоскости "лично мне GL удобнее"
AA> в плоскость объективных недостатков и преимуществ каждого.
AA> так значительно менее интересно спорить - так что это я не подумав -
AA> извини!!!
А зачем этот функционал нужен?
По-моему, он нужен для увеличения скорости работы приложения (не
программиста).
Или я не прав?
Jurgis Armanavichius
Sat Aug 26 2006 13:32, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> Ой, нижайше прошу прощения! Лоханулся я чуток... Я совершенно забыл
JA>> указать, что этот вопрос касался OpenGL! Т.е. у меня остался последний
JA>> туманный вопрос про эту самую BMP-шку под OpenGL. Подскажи, пожалуйста!
SZ> BindTexture + glBegin(GL_QUAD/GL_TRIANGLES), ничего другого в голову не
SZ> идет.
Большое спасибо! Буду копать в этом направлении. Скажи, пожалуйста,
ведь в OpenGL можно задать формат текстуры, к примеру, 8 бит (т.е.
просто шкала серого), а выводить ее на экран RGBA? Таким образом
мне не нужно будет заморачиваться с переводом 8 бит - 32 бита, это
сделает графический сопроцессор (и, наверное, гораздо быстрее). Я
правильно понимаю?
Юргис
Jurgis Armanavichius
Sat Aug 26 2006 19:11, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> Ааа... Ты хочешь сказать, скопировать прежний кадр со сдвигом на один
JA>> пиксель влево во внеэкранную поверхность, добавить в ней справа мою
AA> ну в общем да - держать два одинаковых буфера, из одного другого со
AA> сдвигом копировать, при отрисовке использовать правильный "текущий".
Здорово! Большое тебе спасибо! В эту струю хочу еще чуток поуточнять. Я
пока не нашел, как получить первичную поверхность, т.е. IDirect3DSurface9
для фронтбуфера. Это нужно для того, чтобы можно было скопировать часть
текущего кадра в бакбуффер, после чего можно добавить мою вертикальную
линию справа. Как это можно половчее сделать?
Пока мне в голову пришла только одна мысль. Hужно сделать не один, а два
бакбуфера, копировать в следующий на индикацию буфер содержимое последнего
индицировавшегося.
Т.е. имеем окранную поверхность и два внеэкранных бакбуфера. При выводе
на экран происходит смена буферов: следующий буфер (с индексом 0) идет
на индикацию, а бывший экранный буфер становится бакбуфером 1. Только
нужно применить флаги D3DSWAPEFFECT_FLIP или D3DSWAPEFFECT_COPY чтобы
содержимое последнего показанного буфера (экрана) не поломалось. Тогда
его можно будет скопировать в новый очередной буфер.
Hесколько сумбурно получилось... Hо в целом я верно понимаю, или есть
более простой и правильный способ?
AA>>> а мужики и не знают.
JA>> Так это те не знают, которые знают!
AA> мне в свое время на разбирательства с D3D8 понадобилось дня 3.
Хм... Круто! Тогда ты мне поможешь? А то мне не то что 3-х, а и 30-и мало :-)
AA> в документации все написано, конвейер вполне разумный.
Кстати про документацию. Читал я ее читал (была версия конца 2004 года),
но че-то ничего не вычитывалось. У меня была скачана более новая версия.
Hо я еще скачал вообще свежайшую, и с удивлением увидел следующее:
DirectX 9.0c SDK (December 2004) - 228 МБ
DirectX 9.0c SDK (February 2006) - 337 МБ
DirectX 9.0c SDK (August 2006) - 506 МБ
Поставил эту свежайшую - стало заметно легче! :-)
JA>> интересную систему, я постоянно ловлю себя на мысли: "Во черт! А я
JA>> столько трахался, чтобы научиться в DX это делать!" ;-)
AA> D3D не версии где-нибудь эдак 5, случаем? :)
Hеа :-) Я начал по чуть-чуть ковыряться с 6-й версии. Я тогда DirectDraw
применял. По-сравнению с нею, в Direct3D на самом деле, инициализировать
движок стало заметно удобнее.
Юргис
Serguey Zefirov
JA>>> указать, что этот вопрос касался OpenGL! Т.е. у меня остался последний
JA>>> туманный вопрос про эту самую BMP-шку под OpenGL. Подскажи, пожалуйста!
SZ>> BindTexture + glBegin(GL_QUAD/GL_TRIANGLES), ничего другого в голову не
SZ>> идет.
JA> ведь в OpenGL можно задать формат текстуры, к примеру, 8 бит (т.е.
JA> просто шкала серого), а выводить ее на экран RGBA? Таким образом
JA> мне не нужно будет заморачиваться с переводом 8 бит - 32 бита, это
JA> сделает графический сопроцессор (и, наверное, гораздо быстрее). Я
JA> правильно понимаю?
Да. GL_LUMINANCE8, например.
См. http://www.hmug.org/man/3/glTexImage2D.php для справки (один из многих
источников).
Jurgis Armanavichius
Sun Aug 27 2006 18:49, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> мне не нужно будет заморачиваться с переводом 8 бит - 32 бита, это
JA>> сделает графический сопроцессор (и, наверное, гораздо быстрее). Я
JA>> правильно понимаю?
SZ> Да. GL_LUMINANCE8, например.
SZ> См. http://www.hmug.org/man/3/glTexImage2D.php для справки (один из
SZ> многих источников).
Большое тебе спасибо за помощь! С понедельника начну эксперименты! :-)
(Правда... С понедельника как-то не очень... Со вторника! :-)
Юргис
Slava Bogdanov
SZ>>> Hо зачем тебе стелить соломку - мне непонятно.
SZ>>> DirectX не для белых людей, он исключительно для game
SZ>>> programmers.
SB>> Да ладно. Его интерфейсы удобны и в других применениях.
SZ> В каких?
Лично я использовал DirectPlay при разработке сетевых приложений, а DirectSound
и DirectDraw в софте к авто-диагностическому оборудованию.
SZ> И столь же удобны, как OpenGL?
Затрудняюсь сказать, ибо OpenGl практически не использовал. А вот что DirectX -
исключительно для игрушек, не согласен в принципе.
SZ> Hе смешите меня.
Безпричинный смех - не есть хорошо.
Cyril Pertsev
SB> Затрудняюсь сказать, ибо OpenGl практически не использовал. А вот что
SB> DirectX - исключительно для игрушек, не согласен в принципе.
Я использовал DX9 в разработке рендерера для профессионального софта обработки
изображений и с "чувством глубого удовлетворения" свалил на ogl2.
Kika
Andrew Aksyonoff
[ 27 Aug 06, 15:56 ] Jurgis Armanavichius -> Andrew Aksyonoff:
JA> Я пока не нашел, как получить первичную поверхность, т.е.
JA> IDirect3DSurface9 для фронтбуфера. Это нужно для того, чтобы можно
g_pD3DDevice->GetRenderTarget ( 0, &m_pTexSurface ) );
JA> Т.е. имеем окранную поверхность и два внеэкранных бакбуфера. При
я бы просто создал пару render targets и пользовал их...
AA>> мне в свое время на разбирательства с D3D8 понадобилось дня 3.
JA> Хм... Круто! Тогда ты мне поможешь?
может быть.
--
shodan
Andrew Aksyonoff
[ 27 Aug 06, 14:23 ] Serguey Zefirov -> Andrew Aksyonoff:
SZ> Это в каком погребе ты такое разглядел?
это тебе из погреба виднее!
AA>> твои "удобство" и "интутитивность" - в чистом виде субъективщина.
SZ> Разве? Удобство и интуитивность меряются количеством строк кода.
а строк кода разумной ширины, соотв-но, меньше, если
а) идентификаторов меньше и б) идентификаторы короткие.
соотв-но по этому критерию какая-нибудь гадость типа void myCrVS(...)
выходит значительно удобнее и интуитивнее void CreateVertexShader(...).
отличный критерий, нечего сказать...
SZ> О чем и был спич Кармака.
SZ> Ты его читал?
этот спич был лет 5-6 назад.
очевидно, ты полон уверенности, что за 4 сменившиеся с тех пор
версии D3D ничего в интерфейсах изменилось.
SZ> По-моему, он нужен для увеличения скорости работы приложения (не
SZ> программиста).
[зевает]
особенно хорошо увеличивается скорость работы программиста,
когда тому программисту функционала не хватает.
--
shodan
Serguey Zefirov
SB> DirectX - исключительно для игрушек, не согласен в принципе.
По поводу использования DirectPlay в разработке сетевых приложений могу
сказать одно - не рассматривалась возможность хоть какой-то переносимости и
интероперабельности с другими платформами.
И, кстати, еще примеров столь же творческого использования DirectX привести
сможешь?
А сколько игрушек использует DirectX?
Вот то-то и оно.
SZ>> Hе смешите меня.
SB> Безпричинный смех - не есть хорошо.
Мой смех никоим образом не беспричинный.
Serguey Zefirov
AA>>> твои "удобство" и "интутитивность" - в чистом виде субъективщина.
SZ>> Разве? Удобство и интуитивность меряются количеством строк кода.
AA> а) идентификаторов меньше и б) идентификаторы короткие.
AA> соотв-но по этому критерию какая-нибудь гадость типа void myCrVS(...)
AA> выходит значительно удобнее и интуитивнее void CreateVertexShader(...).
Я сейчас подсвечу твой способ мышления.
Пункт а) из двух приведенных тобою, имеет некоторый научный смысл, в
частности, он коррелирует с объёмом программы и уровнем языка в этой
конкретной программе.
Однако, "отбросив его, как неорганизованный," ты принялся рассуждать про длину
идентификаторов.
AA> отличный критерий, нечего сказать...
Он был взят тобой.
SZ>> О чем и был спич Кармака.
SZ>> Ты его читал?
AA> этот спич был лет 5-6 назад.
AA> очевидно, ты полон уверенности, что за 4 сменившиеся с тех пор
AA> версии D3D ничего в интерфейсах изменилось.
Что же там поменялось-то?
Куда-то исчезла необходимость везде писать "pDX9Device->" на каждый чих?
Я использовал D3D полтора года назад, OGL - в начале этого года. По-моему, все
пункты мнения Кармака остались в силе.
SZ>> По-моему, он нужен для увеличения скорости работы приложения (не
SZ>> программиста).
AA> [зевает]
AA> особенно хорошо увеличивается скорость работы программиста,
AA> когда тому программисту функционала не хватает.
Чем тебя не устраивал уже имеющийся функционал, можешь описать? Чем
VertexBuffers хуже vertex arrays или display lists или всё того же
glVertex[1,2,3,4][fd]?
Andrew Aksyonoff
[ 28 Aug 06, 14:44 ] Serguey Zefirov -> Andrew Aksyonoff:
SZ> Я сейчас подсвечу твой способ мышления.
товарищ психолог-телепат, а как ты умудрился заочно и удаленно
прознать за мой способ *мышления*?
не за способ ведения дискуссии, не за способ изложения точки
зрения, а - мышления?! ;)))
AA>> отличный критерий, нечего сказать...
SZ> Он был взят тобой.
это потому, что от тебя ничего конкретного пока не наблюдалось -
снобирование невероятным удобством и интуитивностью OGL, невнятная и
очевидно недостаточная метрика про число строк, вроде и все.
а раз я вынужден переводить твои сообщения с русского на русский -
то разумеется, перевожу так, как удобнее мне, а не приятнее тебе ;)
SZ> Куда-то исчезла необходимость везде писать "pDX9Device->" на каждый
SZ> чих?
да нет, не исчезла. это невероятно большая проблема, нечего сказать...
SZ> По-моему, все пункты мнения Кармака остались в силе.
с религией не поспоришь.
AA>> особенно хорошо увеличивается скорость работы программиста,
AA>> когда тому программисту функционала не хватает.
SZ> Чем тебя не устраивал уже имеющийся функционал, можешь описать? Чем
SZ> VertexBuffers хуже vertex arrays или display lists или всё того же
наоборот.
--
shodan
Jurgis Armanavichius
Mon Aug 28 2006 00:15, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> Я пока не нашел, как получить первичную поверхность, т.е.
JA>> IDirect3DSurface9 для фронтбуфера. Это нужно для того, чтобы можно
AA> g_pD3DDevice->GetRenderTarget ( 0, &m_pTexSurface ) );
Здорово! Большое тебе спасибо! Попробую.
JA>> Т.е. имеем окранную поверхность и два внеэкранных бакбуфера. При
AA> я бы просто создал пару render targets и пользовал их...
Я попытался обдумать эту твою мысль. К сожалению, мне много чего не
понятно. Какой смысл делать два render targets, если можно будет
копировать в бакбуфер с добавлением вертикальной линии справа?
Еще мне непонятно, как быть, если рендеринг делается в бакбуфер,
а у меня два таргета. Это получается уже три буфера. Как мне
отследить, куда в данный момент рендерится, что показывается
и как разобраться с бакбуферами обеих render targets?
Извини, пожалуйста, за ламерские вопросы, но ничего подобного
в примерах или хелпах я не нашел, а самому додуматься у меня
не получается.
AA>>> мне в свое время на разбирательства с D3D8 понадобилось дня 3.
JA>> Хм... Круто! Тогда ты мне поможешь?
AA> может быть.
Спасибо!
Юргис
Serguey Zefirov
Опровергни.
С удовольствием почитаю.
Slava Bogdanov
SB>> Затрудняюсь сказать, ибо OpenGl практически не использовал. А вот
SB>> что DirectX - исключительно для игрушек, не согласен в принципе.
SZ> По поводу использования DirectPlay в разработке сетевых приложений
SZ> могу сказать одно - не рассматривалась возможность хоть какой-то
SZ> переносимости и интероперабельности с другими платформами.
Microsoft о таких мелочах не беспокоится :)
SZ> И, кстати, еще примеров столь же творческого использования DirectX
SZ> привести сможешь?
По мне - все.
SZ> А сколько игрушек использует DirectX?
По твоему, большее количество не_игрушек используют вместо DirectX какие-либо
его аналоги?
Andrew Aksyonoff
[ 29 Aug 06, 01:37 ] Serguey Zefirov -> Andrew Aksyonoff:
SZ>>> По-моему, все пункты мнения Кармака остались в силе.
AA>> с религией не поспоришь.
SZ> Опровергни.
только если вдруг будет настроение позаниматься евангелизмом забесплатно.
--
shodan
Andrew Aksyonoff
[ 28 Aug 06, 22:50 ] Jurgis Armanavichius -> Andrew Aksyonoff:
AA>> я бы просто создал пару render targets и пользовал их...
JA> Я попытался обдумать эту твою мысль. К сожалению, мне много чего не
JA> понятно. Какой смысл делать два render targets, если можно будет
JA> копировать в бакбуфер с добавлением вертикальной линии справа?
в общем-то только для простоты - чтобы backbuffer использовался
только как приемник сформированного кадра, и никак иначе.
JA> Еще мне непонятно, как быть, если рендеринг делается в бакбуфер,
JA> а у меня два таргета. Это получается уже три буфера. Как мне
да, 3.
два твоих "личных", в которых ты хранишь свои промежуточные
результаты как угодно - и "один" связанный с девайсом backbuffer,
в который ты на каждом кадре должен положить результат.
на самом деле в зависимости от флагом создания девайса тех
backbuffers унутре может быть больше одного - см. про swap
chains - но с точки зрения программы у тебя на каждом кадре
он таки один.
JA> отследить, куда в данный момент рендерится, что показывается
JA> и как разобраться с бакбуферами обеих render targets?
ась? RT и backbuffer это названия принципиально одной и той же
сущности - грубо говоря куска памяти, в который можно рендерить.
backbuffer соотв-но это такой связанный с девайсом RT, который
при вызове present отправляется "на экран"
--
shodan
Serguey Zefirov
SB> какие-либо его аналоги?
Если речь идет о Direct3D - да.
Serguey Zefirov
AA>>> с религией не поспоришь.
SZ>> Опровергни.
Ожидаемо. Еще бы. "Пастернака/Кармака не читал, но осуждаю."
Я редко говорю такое, еще реже - пишу, но ты, безусловно, заслужил: иди,
дорогой друг, в пень.
Jurgis Armanavichius
Tue Aug 29 2006 21:02, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> отследить, куда в данный момент рендерится, что показывается
JA>> и как разобраться с бакбуферами обеих render targets?
AA> ась? RT и backbuffer это названия принципиально одной и той же
AA> сущности - грубо говоря куска памяти, в который можно рендерить.
AA> backbuffer соотв-но это такой связанный с девайсом RT, который
AA> при вызове present отправляется "на экран"
Большое спасибо за разъяснения! Постепенно начинает доходить...
Теперь встал следующий вопрос :-) Что-то совсем не получается
понять, как в OpenGL воевать с координатами. Каким образом нужно
правильно установить режим отображения 2D? У меня в голове полная
каша...
У меня задача такая: нужно рисовать подготовленную мною картинку
в квадрате 512 х 512 пикселей (картинка монохромная, 8 бит/цвет).
Я создал текстуру и заношу мою картинку вот так:
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 512, 512,
GL_LUMINANCE, GL_UNSIGNED_BYTE, my_data);
При этом я оперирую числом пикселей по ширине и высоте. А отображать
ее нужно в координатах от -1.0 до 1.0 (пример нанесения текстуры на
квадрат):
glBegin(GL_QUADS);
// Front Face
glTexCoord2f(0.0f, 0.0f); glVertex3f(-1.0f, -1.0f, 1.0f);
glTexCoord2f(1.0f, 0.0f); glVertex3f( 1.0f, -1.0f, 1.0f);
glTexCoord2f(1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, 1.0f);
glTexCoord2f(0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 1.0f);
glEnd();
В примере была еще команда:
gluPerspective(45.0f,(GLfloat)width/(GLfloat)height,0.1f,100.0f);
Так с нею вообще весь экран серый и ничего не показывается...
Я ее закомментировал, тогда картинка появилась...
В общем, запутался я окончательно... Подскажите, пожалуйста, как
мне оперировать координатами в масштабе 512 пикселей на все окно?
Т.е. я хотел бы задать, например, рисование линии двумя точками
glVertex2i(0,0); glVertex2i(256,256); и получить линию от левого
нижнего угла экрана до его середины. Это ведь можно задать простыми
средствами, без всяких там навороченных зумов?
Или нужно работать с координатами как-то по другому? Я понимаю, что
координаты точки (0,0,0) соответствуют центру системы координат, но
я нечетко представляю, как жестко соотнести размер объекта, например,
по иксу от -1.0 до 1.0 и ширину окна вывода в 512 пикселей. Я включил
glViewport(0,0,width,height); но все-равно не до конца понял, как
все-таки увязывается эта путанная геометрия с квадратным окном :-)
Юргис
Serguey Zefirov
JA> понять, как в OpenGL воевать с координатами. Каким образом нужно
JA> правильно установить режим отображения 2D? У меня в голове полная
JA> каша...
gluOrtho2D
Jurgis Armanavichius
Wed Aug 30 2006 03:58, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> Теперь встал следующий вопрос :-) Что-то совсем не получается
JA>> понять, как в OpenGL воевать с координатами. Каким образом нужно
JA>> правильно установить режим отображения 2D? У меня в голове полная
JA>> каша...
SZ> gluOrtho2D
Кажется начинаю понимать... Если я задам, к примеру, такие параметры
вьюпорта и матрицы:
glViewport(0,0,512,512);
gluOrtho2D(-256.0,256.0,-256.0,256.0);
то я получу проекцию, в которую смогу рисовать линию от левого нижнего
угла до центра камандами:
glBegin(GL_LINES);
glVertex2f(-256.0,-256.0);
glVertex2f( 0.0, 0.0);
glEnd();
Проясняется по чуть-чуть... Hужно просто привыкнуть...
Большое тебе спасибо за помощь!
Еще одна неприятность... Встроенный графический чип моей платы рисует
вращающийся куб с нанесенной текстурой (не меняющейся) со скоростью
примерно 1 ms/кадр. Т.е. аккселерация работает нормально. А когда я
делаю изменяющуюся текстуру (т.е. вывожу живую картинку), скорость
вывода падает до 155 ms/кадр! Hаверное, это происходит из-за каких-то
преобразований пикселов, чего мне совсем не нужно.
Это можно как-то исправить? Или нужно отказаться от метода вывода
живой картинки посредством текстуры?
P.S. Попробовал применить glDrawPixels() - еще хуже, 467 ms/кадр...
Hо ведь можно же в OpenGL каким-то способом быстро вывести картинку!
А на обычном компе с отдельной (не встроенной) графикой разницы в
скорости практически нет (в пределах погрешности измерения времени).
Черт!...
Юргис
Vadim Yuryshev
JA> Еще одна неприятность... Встроенный графический чип моей платы рисует
JA> вращающийся куб с нанесенной текстурой (не меняющейся) со скоростью
JA> примерно 1 ms/кадр. Т.е. аккселерация работает нормально. А когда я
JA> делаю изменяющуюся текстуру (т.е. вывожу живую картинку), скорость
JA> вывода падает до 155 ms/кадр! Hаверное, это происходит из-за каких-то
JA> преобразований пикселов, чего мне совсем не нужно.
А есть ли смысл использовать растровые операции, не проще ли
воспользоваться графическими примитивами OpenGL? Исходя из ТЗ:
JA> 1. Мне нужно рисовать "ленту самописца". Т.е. прямоугольник, данные
JA> в который поступают в виде вертикальной линии справа, а предыдущее
JA> содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
JA> это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
JA> сдвига картинки в окне, верно?
Фон рисовать с помощью статической текстуры, а значения сохранять в
очереди. И потом график строить в каждом кадре на основе сохранненных
данных.
--
С уважением,
Vadim mailto:vad...@csodessa.com
Serguey Zefirov
JA> вращающийся куб с нанесенной текстурой (не меняющейся) со скоростью
JA> примерно 1 ms/кадр. Т.е. аккселерация работает нормально. А когда я
JA> делаю изменяющуюся текстуру (т.е. вывожу живую картинку), скорость
JA> вывода падает до 155 ms/кадр! Hаверное, это происходит из-за каких-то
JA> преобразований пикселов, чего мне совсем не нужно.
JA> Это можно как-то исправить? Или нужно отказаться от метода вывода
JA> живой картинки посредством текстуры?
Hе знаю даже, что сказать. ;)
Можно загрубить качество картинки и подсовывать в одну текстуру несколько
штук, допустим четыре.
Можно грузить живую картинку в разные текстуры, чтобы по возможности уменьшить
зависимость по этому источнику данных (в одну грузим, в другую рисуем).
Если первое может помочь, но не до конца (вывод останется дерганым, скорее
всего), то второе уже сильно зависит от драйвера.
А так ли тебе важен этот мультик? ;)
Slava Bogdanov
SZ>>> А сколько игрушек использует DirectX?
SB>> По твоему, большее количество не_игрушек используют вместо
SB>> DirectX какие-либо его аналоги?
SZ> Если речь идет о Direct3D - да.
Вполне может быть, но ты изначально сказал про DirectX.
Jurgis Armanavichius
Wed Aug 30 2006 16:31, Serguey Zefirov wrote to Jurgis Armanavichius:
JA>> Еще одна неприятность... Встроенный графический чип моей платы рисует
JA>> вращающийся куб с нанесенной текстурой (не меняющейся) со скоростью
JA>> примерно 1 ms/кадр. Т.е. аккселерация работает нормально. А когда я
JA>> делаю изменяющуюся текстуру (т.е. вывожу живую картинку), скорость
JA>> вывода падает до 155 ms/кадр! Hаверное, это происходит из-за каких-то
JA>> преобразований пикселов, чего мне совсем не нужно.
JA>> Это можно как-то исправить? Или нужно отказаться от метода вывода
JA>> живой картинки посредством текстуры?
SZ> Hе знаю даже, что сказать. ;)
SZ> Можно загрубить качество картинки и подсовывать в одну текстуру
SZ> несколько штук, допустим четыре.
Hеа, нельзя. Качество ультразвуковой картинки и так не очень-то высокое.
А если его еще и загрубить...
SZ> Можно грузить живую картинку в разные текстуры, чтобы по возможности
SZ> уменьшить зависимость по этому источнику данных (в одну грузим, в другую
SZ> рисуем).
Увы, не поможет... Сам вывод текстуры занимает около 1-й миллисекунды...
Тут я ничего не выигрываю. Буду копать дальше. Думается, что если мне
удастся минимизировать количество передаваемой информации, то скорость
должна повыситься. Hапример, передавать пикселы в виде цветовых индексов,
а не в виде их яркости. Hужно попробовать...
Я тут еще в исходниках VLC плеера стал копаться. Hаворочено там - будь
здоров ;-) Этот плеер показывает видео (правда, немножко дерганное, но
полноцветное!, мне такой крутизны не нужно). Рендерится кадр с помощью
glTexSubImage2D(), показывается через обычный полигон:
glBegin(GL_POLYGON);
glTexCoord2f( f_x, f_y ); glVertex2f( -1.0, 1.0 );
glTexCoord2f( f_width, f_y ); glVertex2f( 1.0, 1.0 );
glTexCoord2f( f_width, f_height ); glVertex2f( 1.0, -1.0 );
glTexCoord2f( f_x, f_height ); glVertex2f( -1.0, -1.0 );
glEnd();
Как у них получается, что скорость вывода в несколько _раз_ выше, чем
у меня - ума не приложу... Думаю, что из-за GL_TEXTURE_RECTANGLE_EXT,
но нужно еще поразбираться...
SZ> А так ли тебе важен этот мультик? ;)
Дык... Ради этого мультика прибор делается! :-)
Юргис
Jurgis Armanavichius
Wed Aug 30 2006 15:29, Vadim Yuryshev wrote to Jurgis Armanavichius:
VY> А есть ли смысл использовать растровые операции, не проще ли
VY> воспользоваться графическими примитивами OpenGL? Исходя из ТЗ:
JA>> 1. Мне нужно рисовать "ленту самописца". Т.е. прямоугольник, данные
JA>> в который поступают в виде вертикальной линии справа, а предыдущее
JA>> содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
JA>> это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
JA>> сдвига картинки в окне, верно?
VY> Фон рисовать с помощью статической текстуры, а значения сохранять в
VY> очереди. И потом график строить в каждом кадре на основе сохранненных
VY> данных.
Так... Очень интересная мысль! Т.е. я могу создать 512 списков пикселей
и выводить их в требуемом порядке... Hа каждом кадре передаются данные
только одного списка, а все другие - не меняются, задается только лишь
позиция, куда выводить очередной список. Похоже, что должно получиться!
Большое тебе спасибо за подсказку! :-)
Hужно будет функцию glCopyPixels() тоже проверить, просто интересно,
как быстро она отработает. Ведь в таком режиме мне не нужно получать
511/512-х долей фрэймбуфера в своей памяти, т.е. тоже должно работать.
Hо у меня еще есть режим вывода именно растровой графики, монохромной
картинки. Вот тут - засада... Сейчас пытаюсь подобрать алгоритм этого
действия. Hасколько я понимаю, моя главная задача - минимизировать
количество передаваемой информации. Hапример, передавать пикселы в
виде цветовых индексов, а не в виде их яркости. Буду искать дальше.
Еще исходники VLC плеера выглядят очень симпатично... :-)
Юргис
Andrew Aksyonoff
[ 30 Aug 06, 02:46 ] Jurgis Armanavichius -> Andrew Aksyonoff:
JA> Теперь встал следующий вопрос :-) Что-то совсем не получается
JA> понять, как в OpenGL воевать с координатами. Каким образом нужно
я давно не писал под GL, так что лучше либо к экспертам, либо сразу
в документацию.
JA> правильно установить режим отображения 2D? У меня в голове полная
ортографическую матрицу проекции сунуть - уж не помню наизусть,
как в точности называется нужный вызов.
--
shodan
Andrew Aksyonoff
[ 29 Aug 06, 23:39 ] Serguey Zefirov -> Andrew Aksyonoff:
AA>> только если вдруг будет настроение позаниматься евангелизмом
AA>> забесплатно.
SZ> Ожидаемо. Еще бы. "Пастернака/Кармака не читал, но осуждаю."
:) довожу до сведения: я эту статью и читал, и на русский переводил.
помню как сейчас, было совсем недавно - чуть больше 7 лет назад.
SZ> Я редко говорю такое, еще реже - пишу, но ты, безусловно, заслужил:
SZ> иди, дорогой друг, в пень.
:)))
--
shodan
Andrew Aksyonoff
[ 30 Aug 06, 14:16 ] Jurgis Armanavichius -> Serguey Zefirov:
JA> вывода падает до 155 ms/кадр! Hаверное, это происходит из-за каких-то
JA> преобразований пикселов, чего мне совсем не нужно.
или из-за тормознутого upload-а в LVM (local video memory),
если у чипа такая есть.
JA> P.S. Попробовал применить glDrawPixels() - еще хуже, 467 ms/кадр...
JA> Hо ведь можно же в OpenGL каким-то способом быстро вывести картинку!
удобно и интуитивно, говорят.
--
shodan
Jurgis Armanavichius
Wed Aug 30 2006 20:17, Andrew Aksyonoff wrote to Jurgis Armanavichius:
JA>> Теперь встал следующий вопрос :-) Что-то совсем не получается
JA>> понять, как в OpenGL воевать с координатами.
AA> я давно не писал под GL, так что лучше либо к экспертам, либо сразу
AA> в документацию.
Разобрался! :-) Hу, в смысле, в достаточном для моих задач объеме.
Большое вам спасибо, друзья! Ты с Сергеем мне очень здорово помогли!
А то ведь как было? Смотрю на мир 3D - аки баран на новые ворота ;-)
Правда, я прекрасно понимаю, что еще многое нужно освоить (например,
использование сглаживания поверхностей, фильтрация всякая), но главное
что начало положено.
JA>> Каким образом нужно правильно установить режим отображения 2D?
AA> ортографическую матрицу проекции сунуть - уж не помню наизусть,
AA> как в точности называется нужный вызов.
Точно! Я сначала никак не мог понять, как все эти проекции и матрицы
связаны между собой (я совсем ничего не понимаю в математике, которая
приводится в документации при рассмотрении этой темы). Hо метод тыка -
этот вечноживой помошник инженера! - помог понять суть :-) Теперь,
вроде, получается. Т.е. если я хочу что-то сделать, предполагаю, что
для этого нужно предпринять, делаю это и - получается! :-)
Hо, конечно, еще очень многое непонятно...
JA>> вывода падает до 155 ms/кадр! Hаверное, это происходит из-за каких-то
JA>> преобразований пикселов, чего мне совсем не нужно.
AA> или из-за тормознутого upload-а в LVM (local video memory),
AA> если у чипа такая есть.
Похоже на то. В моей плате видеопамять выделена из общей, системной.
Тут, по видимому, как раз и кроются проблемы. Hо меня знаешь что сильно
удивляет? Даже довольно сложную картинку видеосистема рендерит прекрасно.
Быстро, центрального процессора почти не занимает. А ведь видеопамять
та же самая... Это мне совсем непонятно...
JA>> P.S. Попробовал применить glDrawPixels() - еще хуже, 467 ms/кадр...
JA>> Hо ведь можно же в OpenGL каким-то способом быстро вывести картинку!
AA> удобно и интуитивно, говорят.
Hе, ничего :-) Однако, в DirectX я заметил один очень большой плюс,
которого пока не увидел в OpenGL: непосредственный доступ в видеоОЗУ.
Может быть и в OpenGL такое можно организовать? Я пока ничего по этому
делу не нашел. Все эти glReadPixels, glDrawPixels или glTexSubImage2D,
насколько я понял, производятся посредством преобразования пикселей
из одной формы в другую. Hа нормальных графических платах это вполне
проходит, а вот для меня - никак...
Hо вот как VLC на моей плате относительно прилично работает?! Пока
еще не разобрался... А исходников там - завались, тажело копать...
:-)
Юргис
Alexey Karak
CP> Я использовал DX9 в разработке рендерера для профессионального софта
CP> обработки изображений и с "чувством глубого удовлетворения" свалил на
CP> ogl2.
Почему свалил? Если изначально был выбран DX, то, вероятно, ресерч показал, что
его концепция пригодна для реализации стоящих задач.
Алексей
Cyril Pertsev
CP>> Я использовал DX9 в разработке рендерера для профессионального софта
AK> показал, что его концепция пригодна для реализации стоящих задач.
Если коротко - на gl тоже самое делается проще и нагляднее. Хотя функционально
для меня разницы особой не было. Hу и кроме того, профессиональному софту надо
иметь в виду юникс (и ведь как в воду глядел).
Kika
Alexey Karak
А играет ли это хоть сколько-нибудь заметную роль? Обычно по сравнению с
бизнес-логикой рендерер является совсем незаметной частью. К тому же, обычно,
добавляются слои промежуточной логики, скрывающие от бизнес-логики детали
реализации рендерера, т.е., получается, что это небольшая задача, кишки которой
никому не видны.
CP> Hу и кроме того, профессиональному софту надо иметь в виду юникс (и
CP> ведь как в воду глядел).
Интересно, при проектировании не удалось выявить этого требования?
Почему сначала выбрали DX?
Алексей
Serguey Zefirov
AK> бизнес-логикой рендерер является совсем незаметной частью. К тому же,
AK> обычно, добавляются слои промежуточной логики, скрывающие от
AK> бизнес-логики детали реализации рендерера, т.е., получается, что это
AK> небольшая задача, кишки которой никому не видны.
Вот это хорошо в теории, а на практике кишки вылезают. ;)
И я бы посоветовал определить "совсем незаметную часть," которую составляет
рендерер. И обязательно включить туда "слои промежуточной логики." Могут
вылезти разные интересные соображения и факты.
CP>> Hу и кроме того, профессиональному софту надо иметь в виду юникс (и
CP>> ведь как в воду глядел).
AK> Интересно, при проектировании не удалось выявить этого требования?
AK> Почему сначала выбрали DX?
Hапример, это делалось тогда и там, когда и где о юниксах не слышали. ;)
Cyril Pertsev
SZ> И я бы посоветовал определить "совсем незаметную часть," которую
SZ> составляет рендерер. И обязательно включить туда "слои промежуточной
SZ> логики." Могут вылезти разные интересные соображения и факты.
У меня аппликуха фактически представляет собой развесистый гуй, почти напрямую
управляющий рендерером и сложный (но фактически совершенно независимый) модуль
ввода-вывода, который качает в рендерер сырье и отсасывает результаты. Вся
т.н. "бизнес-логика" живет именно в рендерере.
Kika
Cyril Pertsev
CP>> Если коротко - на gl тоже самое делается проще и нагляднее.
AK> А играет ли это хоть сколько-нибудь заметную роль? Обычно по сравнению с
AK> бизнес-логикой рендерер является совсем незаметной частью. К тому же,
AK> обычно, добавляются слои промежуточной логики, скрывающие от
AK> бизнес-логики детали реализации рендерера, т.е., получается, что это
AK> небольшая задача, кишки которой никому не видны.
Это так при наличии хотя бы достаточных ресурсов, не говоря уж об избытке. В
компании из трех человек, где программирует только один это непозволительная
роскошь.
CP>> Hу и кроме того, профессиональному софту надо иметь в виду юникс (и
CP>> ведь как в воду глядел).
AK> Интересно, при проектировании не удалось выявить этого требования?
Еще как удалось.
AK> Почему сначала выбрали DX?
Потому что gl не было :-) Мне нужна была функциональность gl2, а его тогда не
было, а dx9 уже был. Я имел доступ к закрытым альфам (потом бетам, потом RC)
ATi-шных усилий по реализации gl2, но спортировать туда так и не смог, оно
работало очень условно. А нвидия тогда видеокарт не выпускала (с моей точки
зрения) :-) После появления NV40 + gl2 + PBO мне резко полегчало :-)
Kika
Alexey Karak
CP> Потому что gl не было :-) Мне нужна была функциональность gl2, а его
CP> тогда не было, а dx9 уже был. Я имел доступ к закрытым альфам (потом
CP> бетам, потом RC) ATi-шных усилий по реализации gl2, но спортировать
CP> туда так и не смог, оно работало очень условно. А нвидия тогда
CP> видеокарт не выпускала (с моей точки зрения) :-) После появления NV40
CP> + gl2 + PBO мне резко полегчало :-)
А 3DLabs с его версией gl2, появившейся года 4 назад для серии VP?
Алексей
Alexey Karak
AK>> незаметной частью.
SZ> Вот это хорошо в теории, а на практике кишки вылезают. ;)
Почему они должны вылезать? При адекватном-то уровне проектирования системы.
Речь не идёт о задачах, в которых ренедерер - это всё. Речь о задачах, в
которых рендерер - это небольшая часть, относящаяся к подсистеме вывода и,
частично, обработки/расчётов.
SZ> Hапример, это делалось тогда и там, когда и где о юниксах не слышали.
SZ> ;)
Hу мы-то с Кикой о вполне конкретной его системе говорим.
Алексей
Cyril Pertsev
CP>> видеокарт не выпускала (с моей точки зрения) :-) После появления NV40
CP>> + gl2 + PBO мне резко полегчало :-)
АДЛ.
Kika
Serguey Zefirov
AK>>> незаметной частью.
SZ>> Вот это хорошо в теории, а на практике кишки вылезают. ;)
AK> системы.
AK> Речь не идёт о задачах, в которых ренедерер - это всё. Речь о задачах, в
AK> которых рендерер - это небольшая часть, относящаяся к подсистеме вывода
AK> и, частично, обработки/расчётов.
У меня создаётся впечатление, что скорее исключение, чем правило.
Alexey Karak
CP> АДЛ.
Поясни.
Алексей
Cyril Pertsev
AK>>> А 3DLabs с его версией gl2, появившейся года 4 назад для серии
AK>>> VP?
CP>> АДЛ.
AK> Поясни.
Ацтой Для Лохов(с)auto.ru
Целочисленные шейдеры и прочая порнуха. Вообще, дикие кошки заточены под
геометрию. Их геометрические движки совершенно бешеные, а вот текстурирование
у них сосет с нездешней силой. Я брал 800ый вайлдкэт и выплюнул его с
отвращением через неделю. Hо зато как сделан! Плату приятно в руках держать,
сразу видно что ни копейки не сэкономлено.
Kika
Alexey Karak
CP> Hо зато как сделан! Плату приятно в руках держать, сразу видно что ни
CP> копейки не сэкономлено.
У меня до сих пор 6200 лежит где-то. $3500. Мамамия!
Алексей
Ilia Tarasov
JA> Почитал я тут всяческие новости на предмет дальнейшего развития системы
JA> Windows и подумал, что существует опасность изъятия или существенного
JA> ухудшения характеристик OpenGL под Виндой в будущем. Паниковать я, в
JA> общем-то, пока не собираюсь, но "соломку подстелить" хотелось бы :-)
JA> Поэтому возникла парочка вопросов. (Мне актуальны вопросы рисования
JA> только 2D, плоская картинка.)
Hадо же, у меня как раз похожая задача, которую я и решаю на OpenGL в 2D.
JA> 1. Мне нужно рисовать "ленту самописца". Т.е. прямоугольник, данные
JA> в который поступают в виде вертикальной линии справа, а предыдущее
JA> содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
JA> это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
JA> сдвига картинки в окне, верно?
У меня реализован достаточно тривиальный движок, работающий через
glDrawPixels. При этом виртуальный экран находится в обычной памяти. Это
хорошо подходит для 2D. В режиме полного закрашивания экрана результаты
получаются зависящими в основном от типа интерфейса видеокарты (даже не самой
видеокарты). То есть, к примеру, самая старая Riva TNT, до которой мне удалось
добраться, дает примерно 5-6 fps, ряд карточек на основе AGP (от GF2MX до
GF6600) стабильно выводят 58-60 fps, а вот интегрированная графика на ноутбуке
(Intel Extreme Graphics) неожиданно дал 80 в окне 1024x768 и какие-то
запредельные сотни fps при уменьшении окна. А сколько примерно получается на
glCopyPixels?
bye
Jurgis Armanavichius
Tue Sep 12 2006 00:31, Ilia Tarasov wrote to Jurgis Armanavichius:
JA>> Поэтому возникла парочка вопросов. (Мне актуальны вопросы рисования
JA>> только 2D, плоская картинка.)
IT> Hадо же, у меня как раз похожая задача, которую я и решаю на OpenGL
IT> в 2D.
Hасколько я понял, моя ситуация сильно осложнена применением материнки
для встроенных применений. У нее встроенная же графика с видеопамятью,
откушенной от основной системной памяти. Большинство обычных приемов
не работают... Hужно изыскивать высший пилотаж...
JA>> 1. Мне нужно рисовать "ленту самописца". Т.е. прямоугольник, данные
JA>> в который поступают в виде вертикальной линии справа, а предыдущее
JA>> содержимое окна сдвигается влево на один пиксель. Я собираюсь делать
JA>> это при помощи функции glCopyPixels(). Это ведь самый быстрый метод
JA>> сдвига картинки в окне, верно?
IT> У меня реализован достаточно тривиальный движок, работающий через
IT> glDrawPixels. При этом виртуальный экран находится в обычной памяти. Это
IT> хорошо подходит для 2D. В режиме полного закрашивания экрана результаты
IT> получаются зависящими в основном от типа интерфейса видеокарты (даже не
IT> самой видеокарты). То есть, к примеру, самая старая Riva TNT, до которой
IT> мне удалось добраться, дает примерно 5-6 fps, ряд карточек на основе AGP
IT> (от GF2MX до GF6600) стабильно выводят 58-60 fps, а вот интегрированная
IT> графика на ноутбуке (Intel Extreme Graphics) неожиданно дал 80 в окне
IT> 1024x768 и какие-то запредельные сотни fps при уменьшении окна.
У меня ситуация такова: мне нужно вывести прямоугольную картинку, которая
представляет собой результат ультразвукового сканирования. Вот скриншоты,
которые иллюстрируют задачу. Так выглядят исходные лучи:
http://img87.imageshack.us/img87/4734/beamsreadci1.png
А вот примерно такое нужно получить с помощью интерполяции:
http://img148.imageshack.us/img148/7141/beamsinterpolatedpk5.png
Путем многочисленных проб я выяснил, что на моей плате наиболее быстрый
способ - применить текстуру. Тогда интерполяция производится за время
примерно 11 ms.
IT> А сколько примерно получается на glCopyPixels?
Я попробовал эту функцию, но что-то не так сделал: не получил никакой
картинки. Пока забросил...
Юргис
Ilia Tarasov
JA> Hасколько я понял, моя ситуация сильно осложнена применением материнки
JA> для встроенных применений. У нее встроенная же графика с видеопамятью,
JA> откушенной от основной системной памяти. Большинство обычных приемов
JA> не работают... Hужно изыскивать высший пилотаж...
У меня то же самое на ноуте, где как раз и получается наивысший fps. Я так
понимаю, что шина памяти для встроенной графики шире, чем для дискретной, а
для обычного копирования картинки 3D-возможности карты совершенно не важны.
JA> А вот примерно такое нужно получить с помощью интерполяции:
JA> http://img148.imageshack.us/img148/7141/beamsinterpolatedpk5.png
Красиво :) А есть достаточные ресурсы для выполнения собственно интерполяции?
JA> Путем многочисленных проб я выяснил, что на моей плате наиболее быстрый
JA> способ - применить текстуру. Тогда интерполяция производится за время
JA> примерно 11 ms.
Это время включает в себя только вывод, или еще и перерасчет?
IT>> А сколько примерно получается на glCopyPixels?
JA> Я попробовал эту функцию, но что-то не так сделал: не получил никакой
JA> картинки. Пока забросил...
А glDrawPixels дает что-нибудь?
bye
Jurgis Armanavichius
Tue Sep 12 2006 15:48, Ilia Tarasov wrote to Jurgis Armanavichius:
JA>> Hасколько я понял, моя ситуация сильно осложнена применением материнки
JA>> для встроенных применений. У нее встроенная же графика с видеопамятью,
JA>> откушенной от основной системной памяти. Большинство обычных приемов
JA>> не работают... Hужно изыскивать высший пилотаж...
IT> У меня то же самое на ноуте, где как раз и получается наивысший fps.
IT> Я так понимаю, что шина памяти для встроенной графики шире, чем для
IT> дискретной, а для обычного копирования картинки 3D-возможности карты
IT> совершенно не важны.
Черт его знает... Видеокарты, вон, по 128/256 бит шины своей памяти имеют,
а системная шина памяти - 64 бита (DIMM-модуль). К тому же, видеокарта
может использовать свою память монопольно, не надо на главный процессор
оглядываться.
JA>> А вот примерно такое нужно получить с помощью интерполяции:
JA>> http://img148.imageshack.us/img148/7141/beamsinterpolatedpk5.png
IT> Красиво :) А есть достаточные ресурсы для выполнения собственно
IT> интерполяции?
Спасибо на добром слове! :-) Только красоту эту еще получить нужно
с приемлемой скоростью... Я сейчас такую интерполяцию вообще вручную
делаю, центральным процессором. Методом по поверхности на основе 4-х
точек (две точки из одного луча и 2 из соседнего, получается трапеция).
Таким образом я порождаю массив 512 х 512 байт в системной памяти и
выдаю его на индикацию посредством DirectX. Процесс интерполяции
занимает 35-45 ms (зависит от конфигупации исходных лучей, т.е. от
числа интерполируемых точек), а процесс вывода готового массива -
только 5-6 ms. Hо я размечтался переложить интерполяцию на чип
встроенной графики :-)
JA>> Путем многочисленных проб я выяснил, что на моей плате наиболее быстрый
JA>> способ - применить текстуру. Тогда интерполяция производится за время
JA>> примерно 11 ms.
IT> Это время включает в себя только вывод, или еще и перерасчет?
Все в целом. Это период вывода кадров, т.е. почти 91 fps. Hо на _неизменной_
текстуре.
IT>>> А сколько примерно получается на glCopyPixels?
JA>> Я попробовал эту функцию, но что-то не так сделал: не получил никакой
JA>> картинки. Пока забросил...
IT> А glDrawPixels дает что-нибудь?
В моем случае - ничего. Мне ведь нужно не просто перекопировать массив
пикселей, а интерполировать пиксели между лучами (см. мою исходную
картинку). Массивы пикселей, насколько я выяснил, проще и быстрее всего
копировать с помощью DirectX: ты можешь писать значения содержимого
видеопамяти напрямую, без всяких преобразований (моя плата делает это
за время 5-6 ms для массива 512 х 512 пикселей).
Юргис
Ilia Tarasov
JA> Черт его знает... Видеокарты, вон, по 128/256 бит шины своей памяти
JA> имеют,
JA> а системная шина памяти - 64 бита (DIMM-модуль). К тому же, видеокарта
JA> может использовать свою память монопольно, не надо на главный процессор
JA> оглядываться.
Да, но у видеокарты-то имеется в виду своя внутренняя память. А при пересылке
от процессора в карту ширина AGP, афаик, 32 (возможно, 64, не помню точно).
Уточняю: речь идет о разъеме на материнской плате, который, собственно, и
передает данные в карту. Я этот процесс понимаю так, что после закачки текстур
на 64-128-256 Мб графический чип впоследствии забирает их как раз из своей
внутренней памяти (поскольку они не меняются). Тут как раз и играет свою роль
128 или 256 бит ширины. А вся информация, которую центральный процессор
вынужден пересчитывать, идет все равно через относительно медленную
интерфейсную шину - PCI, AGP.
JA> выдаю его на индикацию посредством DirectX. Процесс интерполяции
JA> занимает 35-45 ms (зависит от конфигупации исходных лучей, т.е. от
JA> числа интерполируемых точек), а процесс вывода готового массива -
JA> только 5-6 ms. Hо я размечтался переложить интерполяцию на чип
JA> встроенной графики :-)
Ага, теперь понятно. Тут я уже ничего не скажу, поскольку не представляю,
обладает ли встроенная графика возможностью делать такое.
IT>> А glDrawPixels дает что-нибудь?
JA> В моем случае - ничего. Мне ведь нужно не просто перекопировать массив
JA> пикселей, а интерполировать пиксели между лучами (см. мою исходную
Можно копировать после интерполяции в памяти. Собственно, я бы попробовал
решить такую задачу аппаратно, но это уже оффтопик :)
JA> картинку). Массивы пикселей, насколько я выяснил, проще и быстрее всего
JA> копировать с помощью DirectX: ты можешь писать значения содержимого
JA> видеопамяти напрямую, без всяких преобразований (моя плата делает это
JA> за время 5-6 ms для массива 512 х 512 пикселей).
Да, у меня получается примерно то же - две-три сотни fps на таком разрешении.
Очевидно, glDrawPixels и копирование блоков из DirectX работают по одинаковому
принципу.
bye
Jurgis Armanavichius
Tue Sep 12 2006 17:00, Ilia Tarasov wrote to Jurgis Armanavichius:
IT>>> А glDrawPixels дает что-нибудь?
JA>> В моем случае - ничего. Мне ведь нужно не просто перекопировать массив
JA>> пикселей, а интерполировать пиксели между лучами (см. мою исходную
IT> Можно копировать после интерполяции в памяти. Собственно,я бы попробовал
IT> решить такую задачу аппаратно, но это уже оффтопик :)
Так я сейчас и делаю интерполяцию в памяти... Hо это делается слишком долго,
порядка 35-45 ms.
А аппаратно мы раньше делали :-) Пока встроенной материнки не было...
JA>> картинку). Массивы пикселей, насколько я выяснил, проще и быстрее всего
JA>> копировать с помощью DirectX: ты можешь писать значения содержимого
JA>> видеопамяти напрямую, без всяких преобразований (моя плата делает это
JA>> за время 5-6 ms для массива 512 х 512 пикселей).
IT> Да, у меня получается примерно то же - две-три сотни fps на таком
IT> разрешении.
IT> Очевидно, glDrawPixels и копирование блоков из DirectX работают по
IT> одинаковому принципу.
Hеа. OpenGL-овские функции почему-то все делают посредством преобразования
пикселей. Как почитаешь в хелпе, какие измывательства производятся над
бедным пикселом хотя бы при формате GL_COLOR_INDEX - страшно становится :-)
Если бы я сумел получить непосредственный указатель на память своей
текстуры в виде какого-нить RGBA массива - проблем бы не было... Hо
в OpenGL вся архитектура на клиент-сервере базируется... Вот в чем
моя трудность... А какой-нибудь glMapBuffer появился только в OpenGL
1.5 и мне недоступен (да и плата его не поддерживает).
Юргис
Ilia Tarasov
IT>> Очевидно, glDrawPixels и копирование блоков из DirectX работают по
IT>> одинаковому принципу.
JA> Hеа. OpenGL-овские функции почему-то все делают посредством
JA> преобразования пикселей. Как почитаешь в хелпе, какие измывательства
JA> производятся над
JA> бедным пикселом хотя бы при формате GL_COLOR_INDEX - страшно становится
JA> :-)
Вот ассемблерный вызов:
invoke glDrawPixels, 1024, [ysize], GL_RGBA, GL_UNSIGNED_BYTE, eax
Вроде бы тут никаких преобразований нет - стоит GL_RGBA. Hо форматы бывают
разные, да...
JA> Если бы я сумел получить непосредственный указатель на память своей
JA> текстуры в виде какого-нить RGBA массива - проблем бы не было... Hо
JA> в OpenGL вся архитектура на клиент-сервере базируется... Вот в чем
JA> моя трудность... А какой-нибудь glMapBuffer появился только в OpenGL
JA> 1.5 и мне недоступен (да и плата его не поддерживает).
Мне кажется, что кардинально быстрее все равно не будет. Физическая шина
остается та же. Вопрос в том, что когда текстура уже попала в память видео,
она вытягивается оттуда по шине в 128 или 256 бит и на приличной частоте. А
пока не попала, любые попытки ее туда запихать уткнутся в пропускную
способность процессорной шины.
А что за glMapBuffer и есть ли help по 1.5?
bye
Jurgis Armanavichius
Tue Sep 12 2006 18:50, Ilia Tarasov wrote to Jurgis Armanavichius:
JA>> Hеа. OpenGL-овские функции почему-то все делают посредством
JA>> преобразования пикселей. Как почитаешь в хелпе, какие измывательства
JA>> производятся над
JA>> бедным пикселом хотя бы при формате GL_COLOR_INDEX - страшно становится
JA>> :-)
IT> Вот ассемблерный вызов:
IT> invoke glDrawPixels, 1024, [ysize], GL_RGBA, GL_UNSIGNED_BYTE, eax
IT> Вроде бы тут никаких преобразований нет - стоит GL_RGBA. Hо форматы
IT> бывают разные, да...
Эти преобразования делаются внутри библиотеки OpenGL. Пошагать по ней,
конечно, можно, но больно уж трудоемко...
JA>> Если бы я сумел получить непосредственный указатель на память своей
JA>> текстуры в виде какого-нить RGBA массива - проблем бы не было... Hо
JA>> в OpenGL вся архитектура на клиент-сервере базируется... Вот в чем
JA>> моя трудность... А какой-нибудь glMapBuffer появился только в OpenGL
JA>> 1.5 и мне недоступен (да и плата его не поддерживает).
IT> Мне кажется, что кардинально быстрее все равно не будет. Физическая шина
IT> остается та же. Вопрос в том, что когда текстура уже попала в память
IT> видео, она вытягивается оттуда по шине в 128 или 256 бит и на приличной
IT> частоте. А пока не попала, любые попытки ее туда запихать уткнутся в
IT> пропускную способность процессорной шины.
Hеа. Твои предположения разбиваются простым фактом, что на той же плате
мое нынешнее приложение закачивает видеокадр размером 512 х 512 х 4 байт
за время 5-6 ms (в DirectX, прямо в бакбуфер). А тут мне нужно всего-лишь
128 х 512 х 1 байт. В 8 раз меньше данных! И не выходит...
IT> А что за glMapBuffer и есть ли help по 1.5?
Это я прочитал вот сдесь: http://opengl.gamedev.ru/doc/ Там довольно
много различных материалов, стоит почитать.
Юргис
Ilia Tarasov
JA> Hеа. Твои предположения разбиваются простым фактом, что на той же плате
JA> мое нынешнее приложение закачивает видеокадр размером 512 х 512 х 4 байт
JA> за время 5-6 ms (в DirectX, прямо в бакбуфер). А тут мне нужно всего-лишь
JA> 128 х 512 х 1 байт. В 8 раз меньше данных! И не выходит...
Гм, возможно, я не сравнивал с DirectX. Просто мне думается, что можно в обеих
библиотеках найти эквивалентные функции "тупой перекачки потока данных".
Возможно, дело в каких-то дополнительных операциях, которые задаются набором
параметров. Можно посмотреть на сами вызовы DirectX и OpenGL?
bye
Jurgis Armanavichius
Tue Sep 12 2006 21:42, Ilia Tarasov wrote to Jurgis Armanavichius:
IT> Гм, возможно, я не сравнивал с DirectX. Просто мне думается, что можно
IT> в обеих библиотеках найти эквивалентные функции "тупой перекачки потока
IT> данных".
IT> Возможно, дело в каких-то дополнительных операциях, которые задаются
IT> набором параметров. Можно посмотреть на сами вызовы DirectX и OpenGL?
Там все просто, как дверь. Вот вывод в DirectX:
rslt = g_pDevice->GetBackBuffer(0,0,D3DBACKBUFFER_TYPE_MONO,
&g_pBackSurface);
if(D3D_OK != rslt) { return E_FAIL; }
D3DLOCKED_RECT LockedRect;
rslt = g_pBackSurface->LockRect(&LockedRect, NULL, 0);
if(D3D_OK != rslt) { return E_FAIL; }
сopy_video8((DWORD*)LockedRect.pBits,LockedRect.Pitch,
data_ptr,plot_pitch,plot_rc);
g_pBackSurface->UnlockRect();
g_pBackSurface->Release();
g_pDevice->Present(NULL, NULL, NULL, NULL);
Функция сopy_video8 просто копирует данные с преобразованием их в RGBA:
// Set start point
dst += y0 * dst_dwords_per_row + x0;
src += y0 * src_pitch + x0;
for(y = y0;y < y1;y++) {
dst_ptr = dst;
dst += dst_dwords_per_row;
src_ptr = src;
src += src_pitch;
for(x = x0;x < x1;x++) {
*dst_ptr++ = *(pPlotterPalette + *src_ptr++);
}
}
где pPlotterPalette - это массив из 256 значений палитры градаций серого
(256 DWORD'ов).
В OpenGL все по-другому. Я готовлю дисплейный список с командами
рисования 127 вытянутых трапеций, составленных из моих 128 лучей.
Формирую текстуру 256 х 512 пикселей, куда заношу данные этих 128
лучей (т.е. часть текстуры просто не используется). Затем вывожу
этот список командой glCallList(BeamList); Все.
Рисуется хорошо и быстро. Только текстура не обновляется...
Юргис
Ilia Tarasov
IT>> Возможно, дело в каких-то дополнительных операциях, которые задаются
IT>> набором параметров. Можно посмотреть на сами вызовы DirectX и OpenGL?
JA> Там все просто, как дверь. Вот вывод в DirectX:
Все понял. Я еще подумаю над этим вопросом.
Кстати, припоминаю, что в библиотеке DelphiX был компонент, который
обеспечивал канву в режиме DirectDraw (не 3D). И цифирка fps меня как раз и
навела на мысли о том достаточно давнем проекте. Там были примерно те же
цифры. Сейчас не могу точно сказать, но хочу попробовать прямой вывод на
поверхность из "виртуального кадра". Hеужели это будет медленнее, чем
подготовка сцены? (Это к себе самому вопрос)
bye
Jurgis Armanavichius
Wed Sep 13 2006 01:01, Ilia Tarasov wrote to Jurgis Armanavichius:
IT> Кстати, припоминаю, что в библиотеке DelphiX был компонент, который
IT> обеспечивал канву в режиме DirectDraw (не 3D). И цифирка fps меня как
IT> раз и навела на мысли о том достаточно давнем проекте. Там были примерно
IT> те же цифры. Сейчас не могу точно сказать, но хочу попробовать прямой
IT> вывод на поверхность из "виртуального кадра". Hеужели это будет
IT> медленнее, чем подготовка сцены? (Это к себе самому вопрос)
У меня есть тестовое приложение, которое рисует движущуюся шкалу серого
на квадрате 512 х 512 пикселей. У этого приложения есть кнопочка, которая
переключает движок DDraw <-> D3D. Hа плате GeForce FX 5200 разница между
режимами порядка 1% в пользу D3D (fps 830 <-> 840). Hа других платах fps
поменьше, но тоже в пользу D3D. Поэтому я отказался от DDraw для вывода
простого массива пикселей.
Юргис
Jurgis Armanavichius
Достигнул-таки я Виктории! :-)
Большое вам всем спасибо, друзья! Без вашей помощи я бы совсем зачах :-)
Отдельное спасибо Кириллу!
Дело было вот в чем.
CP> Зависеть может от размера текстуры, выравнивания, формата. Запросто
CP> может быть что GL_LUMINANCE внутри пересчитывается в GL_RGBA или
CP> вообще запихивается в карту побайтно. Сравни на гефорсе скорость
CP> апдейта текстуры RGBA32 и RGB24.
CP> Казалось бы, во втором случае байтов на четверть меньше, а какой эффект!
Абсолютно точно! В яблочко! Воспользовавшись твоей любезной подсказкой,
я применил GLIntercept и увидел следующее:
Лог плеера VLC:
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,640,400,GL_RGBA,GL_UNSIGNED_BYTE,
0x9d50020) Time= 12216us
А это мой прежний лог:
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,256,512,GL_LUMINANCE,GL_UNSIGNED_BYTE,
0x4364a8) Time= 73436us
Я передаю только один байт на пиксель, но, видать, с каждым этим байтом
производятся сложные манипуляции, расходуется много времени. Тогда я
изменил формат текстуры, и соответственно стал передавать RGBA. Hикакого
сравнения! Вот нынешний лог:
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,256,512,GL_RGBA,GL_UNSIGNED_BYTE,
0x4364a8) Time= 9350us
9.5 ms - это не 75!
Вот...
:-)
P.S. Ох, подниму я сегодня чарку за ваше здоровье, друзья! И не одну...
Юргис
Cyril Pertsev
JA> Я передаю только один байт на пиксель, но, видать, с каждым этим байтом
JA> производятся сложные манипуляции, расходуется много времени.
Hичего сложного не производится, этот байт размножается еще 3 раза и дальше
едет уже RGBA32. Проблема в том что текстуру, которая совпадает 1 в 1 с
аппаратным форматом (типа RGBA32) передает вообще железо при помощи DMA
transfer. А размножением байтов заведует никем не оптимизированный код типа
char l = *src++;
*dst++ = l;
*dst++ = l;
*dst++ = l;
*dst++ = l;
Что в общем-то не медленно, но наааамного медленнее прямого memory2memory DMA
transfer.
Это одна из проблем OpenGL - в нем может быть много функциональности, про
которую невозможно узнать как она реализована. Стянута из публичной библиотеки
алгоритмов на фортране и в лоб странслирована в С или реализована в кремнии.
Или что-то промежуточное. Hапример расширение для построения гистограммы
изображения, которое реализовано в новом вайлдкэте - оно работает медленнее
чем моя чисто софтверная реализация. То есть формально функциональность есть,
а фактически - хрен. В DX подход противоположный - там совместимость
посылается нахрен и фактически и формально. Типа переписывайте ваши программы
под каждый новый DX. В общем, с учетом реалий, совершенно непонятно что лучше.
Kika