Войти
ПрограммированиеФорумГрафика

Видеокарта и работа с ... ней? Эффективно ли?

Страницы: 1 2 38 9 Следующая »
#0
0:51, 23 дек. 2015

Здравствуйте. Я не хочу вдаваться в подробности того, как через большое время когда-нибудь займусь одним адским и глупым, затратным по времени делом - написанием кода управления ресурсами видеокарты. Попрошу без критики. Какие на это уйдут средства, сколько человек эту задачу будет решать и т.д. вам не известно, как и то, что это мне даст, следовательно нечего обсуждать глупость чужих намерений без смысла.

Намерения мои таковы. Создать библиотеку подобную OpenGL или DX(хотя это наверное из другой песни) для того, чтобы действия вывода на экран изображений проводились без лишних действий. Для этого мне нужно 2 вещи:
1. Файлы библиотеки с действиями(функциями) на assembler-e.
Сущность функций реализованных в самой библиотеке не только в том, чтобы CPU задавал задачи видеокарте, а еще и вмешательство в ее работу, причем довольно банальное. Правильное распределение ресурсов и иные способы решения задач по обработке видеоинформации.
2. Делаю из этого .dll, .lib и хидеры .h для С++, чтобы комфортно пользоваться функциями библиотеки.

Суть - оптимизация, ускорение вывода графики, т.е. борьба за FPS и за удобство

Попрошу обратить внимание на обстоятельства:
1. Не могу не заметить - на все компы куда бы ни ставили DX и в особенности OpenGL, везде библиотеки эти работают. Пусть иногда и с какими-то недочетами. То есть это своего рода универсальные вещи? Для чего я об этом упомянул? Цель - доказать, что если будет написано что-то третье, то можно добиться его универсальности, а следовательно это возможно.
2. Существует много излишеств в OGL и DX, и в особенности во всяких готовых движках и они влияют на производительность. А хочется, чтобы эти лишние команды и неверное распределение ресурсов устранить, тем более что из-за повышения графического качества игр, борьба там ведется за каждый FPS.
3. DX и OGL возможно не содержат специальных оптимизаторов для повышения производительности GPU. Уж OGL точно. Поэтому частично или полностью отсутствует система кратчайшего пути в решении задачи обработки графики. А хочется, чтобы такая оптимизация была.

Хочу сам управлять ресурсами и самой видеокартой, но не знаю как. Для видеокарт существует свой ассемблер? Как получить к ней доступ и управлять всеми доступными ресурсами самому. Хотя бы для 2D вывод сделать. Посоветуйте что-нибудь готовое из средств и книги для этого и где они вообще.


#1
1:01, 23 дек. 2015

дружище, тебе надо идти работать в амд или нв, ну или ковыряй открытый линуксовый драйвер для карт 10 летней давности :D

#2
1:05, 23 дек. 2015

OtherSide
> Существует много излишеств в OGL и DX, и в особенности во всяких готовых
> движках и они влияют на производительность. А хочется, чтобы эти лишние команды
> и неверное распределение ресурсов устранить, тем более что из-за повышения
> графического качества игр, борьба там ведется за каждый FPS.
с той же целью уже делались (и сделались) Mantle и следующие за ним дх12 с вулканом

OtherSide
> Как получить к ней доступ и управлять всеми доступными ресурсами самому
не забывай что между DX/OGL и видюхой ещё драйвер стоит, в котором может своих неэффективностей и черезжопий хватать. делать в обход драйвера идея нереальная, т.к. придётся учитывать отдельно каждую модель гпу

#3
1:13, 23 дек. 2015

OtherSide
стесняюсь спросить, виной всему проблемы типа этих?
http://www.gamedev.ru/code/forum/?id=207698#m0

#4
1:49, 23 дек. 2015

Synthetic
> OtherSide
> стесняюсь спросить, виной всему проблемы типа этих?
> http://www.gamedev.ru/code/forum/?id=207698#m0
Это меня навело на такие размышления. Вы ведь я думаю в курсе - http://pmg.org.ru/nehe/ogl01.htm
На экране пользователя объектов 3D может быть и 10тыс(реально интерфейс героев 7 содержит на одном только видимом экране именно столько). Их сортировать? только отсортировать 10000 объектов каждый кадр - это настоящий удар по производительности.
Друзья, не хочу показаться странным, этих проблем туева туча.

Mr F
> OtherSide
> Как получить к ней доступ и управлять всеми доступными ресурсами самому
не забывай что между DX/OGL и видюхой ещё драйвер стоит, в котором может своих неэффективностей и черезжопий хватать. делать в обход драйвера идея нереальная, т.к. придётся учитывать отдельно каждую модель гпу.

А кто сказал, что я такой идиот? Не настолько же. Ну любят люди интересные и сложные задачи. В обход драйверов - нет, не желаю. Это слишком.

OtherSide
>То есть это своего рода универсальные вещи? Для чего я об этом упомянул? Цель - доказать, что если будет написано что-то третье, то можно добиться его >универсальности, а следовательно это возможно.
Для чего я вам это пишу. Вообще-то если человек такое пишет, он наверное не собирался драйверы обходить стороной ибо универсальности тогда добиться невозможно. А общаться с видюхой через них. То есть еще один OpenGL только свой. И... увольте предпочту С++ - у ассемблер, чтоб не было ни капли лишних действий.

#5
2:00, 23 дек. 2015

OtherSide
> И... увольте предпочту С++ - у ассемблер, чтоб не было ни капли лишних действий.
У нас кстати есть уже один такой, ronniko называется, всё делает на fasm.

#6
2:00, 23 дек. 2015

OtherSide
> Их сортировать? только отсортировать 10000 объектов каждый кадр - это настоящий
> удар по производительности.
Забей на видеокарту. Представь что у тебя просто в памяти массив пикселей с фиксированным разрешением M*N, и ты в него рисуешь спрайты один за одним (софтварно). Сможешь решить проблемы с прозрачностью без сортировки? Если сможешь - можешь смело патеновать алгоритм. Ну или предложить вендорам видеокарт, а там глядишь поддержка дойдет и до OpenGL и DirectX.

#7
2:13, 23 дек. 2015

OtherSide
> отсортировать 10000 объектов каждый кадр - это настоящий удар по
> производительности.
ты можешь хоть 10 раз по 10000 все отсортировать и это никак не скажется на фпс

#8
2:24, 23 дек. 2015

Да что вы пристали то к предыдущей теме. Не из-за этого все вцелом. Я просто знаю, что когда перейду к более серьезному чему-то будет только хуже и там найду и в DX и в OGL всяких много разных гадостей. Когда GLSL еще не был внедрен в OGL, все страдали. И сейчас из-за DX и OGL  страдают.

#9
2:26, 23 дек. 2015

Frankinshtein
Да как бы сказать...
http://rextester.com/PXBC81141
10*735.00 μs=7.35 ms.
Другое дело, что это std::sort, с помощью radix-sort, можно скорее всего раза в 3 ускорить.

Ну а если не сортировать 10 раз, то и с ~0.7 ms наверно можно жить.

#10
3:00, 23 дек. 2015

MrShoor
> Если сможешь - можешь смело патеновать алгоритм.
А ты хоть знаешь, что это возможно? И довольно просто. Никогда себе не задавал вопрос если одну точку перекрывают 5 спрайтов с разным цветом и альфой, есть ли разница в очередности их вывода с условием, что каждый цвет выводится верно, т.е. с учетом альфы в данной точке. Подумай хорошенечко, чтоб стало ясно перед какой простой банальной задачей стояли GLеры и не решили ее.
Только я подумал, ну напишу я программу собственной обработки пикселей, но будет ли это быстрее, чем реализовано в OGL где ты что-то отправляешь GPU.

Вот скажите, просто другой OpenGL написать ведь можно? Я уже сказал, что я этим заниматься сейчас не буду. Но придет время и займусь.

Скажите, что тогда содержат библиотеки OpenGL? Ну поставим задачу банально. Начнем с 2D. Есть пиксель. Есть массив пикселей, т.е. изображение. И есть 2D объекты. Каким образом и в какой момент пикселем, выводимым на экран или массивом начинает заниматься видеокарта? Когда эта передача происходит. Я же могу все решить без нее. Просто просуммировать с изображением и вывести к чертовой бабушке все это на экран. То есть я могу сделать это процессорно. Как происходит передача задания по графическому вычислению от CPU к GPU? В какой момент и каким способом?

В DLLках OGLских же это есть я так понимаю.

#11
3:16, 23 дек. 2015

OtherSide
> Никогда себе не задавал вопрос если одну точку перекрывают 5 спрайтов с разным
> цветом и альфой, есть ли разница в очередности их вывода с условием, что каждый
> цвет выводится верно, т.е. с учетом альфы в данной точке.
Для классического блендинга типа:
new_color = dest_color * (1 - src_alpha) + src_alpha * src_color
разница в порядке вывода есть.

Более простой пример из жизни. Есть два объекта, почти не прозрачных. Синий и красный. Если синий сверху - то красный еле видно, и наоборот.

#12
3:19, 23 дек. 2015

OtherSide
> Вот скажите, просто другой OpenGL написать ведь можно?
Современный OpenGL реализут разработчики драйверов в своих драйверах. Отказаться от OpenGL это почти тоже самое, что отказаться от драйверов.

> Как происходит передача задания по графическому вычислению от CPU к GPU? В какой момент и каким способом?
Собирается набор инстукций, все это пакуется в DMA пакеты драйвером, и по шине отсылается видеокарте. В DMA пакетах сожержится команды, код и данные, которые видеокарте надо обработать. А в какой момент - это как драйвер решит. Зачастую драйвер по прерыванию от видеокарты узнает, что она закончила обработку определенного DMA пакета, и драйвер сам решает стоит накинуть ей новых пакетов или нет. Посмотреть на пакеты можешь через GPUView.

> Есть массив пикселей, т.е. изображение. И есть 2D объекты. Каким образом и в какой момент пикселем, выводимым на экран или массивом начинает заниматься видеокарта? Когда эта передача происходит. Я же могу все решить без нее. Просто просуммировать с изображением и вывести к чертовой бабушке все это на экран. То есть я могу сделать это процессорно. Как происходит передача задания по графическому вычислению от CPU к GPU? В какой момент и каким способом?
Есть такая штука как графический конвейер. Он лежит прямо в железе. Можно конечно и без него, но не нужно. Изучи как устроен графический конвеер, чтобы понять как работает видеокарта, а потом убедись, что почти все что на конвеере - лежит в основе современных OpenGL и DirectX. Тот OpenGL который ты используешь, аля glBegin/glEnd - устаревший рудимент.

#13
5:38, 23 дек. 2015

OtherSide
Да, да, я с Вами полностью согласен. Все они со своими знаниями, деньгами, фирмами не могут ничего.
Сделали какую то ерунду. Всё тормозит, люди не могут получить нормальное изображение, мучаются с какими то ненужными функциями, оболочками, драйверами.
И так уже лет 20-30, ну никак ничего не могут родить. А может это всемирный заговор? Специально, чтобы программистам было что выдумывать.
Ещё надо новую математику и новые видеокарты придумать.

Ждём с нетерпением результатов. Прям на следующей неделе и ждём.

ухты | Видеокарта и работа с ... ней? Эффективно ли?

(далее серьёзно)
P.S. Надеюсь смог объяснить Вам ситуацию на рынке 3D ПО.
И..., если придумать альтернативу текущему 3D математическому аппарату, который будет проще и быстрее, то тогда точно у Вас многое получится.
Так как все нынешние наработки развивались(а небыли даны свыше) одновременно(математика, аппаратура), и в результате мы имеем то, что мы имеем.

#14
8:04, 23 дек. 2015

OtherSide
> Когда GLSL еще не был внедрен в OGL, все страдали. И сейчас из-за DX и OGL 
> страдают.
Кармаку про это расскажи :)

Страницы: 1 2 38 9 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.