ГЛ много текстур на одном квадрате (мультитекстурирование) ?

[intmain]

рендеринг происходить будет дольше

Вот кста интересный момент, как мы знаем у видяхи есть унифицированные блоки - ядра, есть блоки текстурной выборки - TMU вроде. Есть блоки rasterization - ROP их обычно гораздо меньше чем TMU, и от их кол-ва/кач-ва вроде бы основная мощь видяшки зависит.

Мне просто интересно, вот на каком этапе эта задержка будет ?
Если я скажем все 8 текстур буду мешать.

При выборке текстуры из памяти (в 8 раз больше данных? тут да может )?
При просчете в унифицированном ядре (как минимум 8 умножений, для простого финального дифуза всех слоев )?
При rasterization ( хз че там, треугольник из нормализированного пространстве в плоскость 8 раз проектиться? )?

[s-andriano]

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

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

[intmain]

Кроме того, разные версии драйверов могут реализовывать те или иные возможности разными способами даже для одной карты.

Вот Кармак когда показывал свои 3д очки на одном из роликов на ютубе ругался что пришлось много работать и исправлять баги в драйверах нвидия, типо ему пришлось драйвера заново переписывать интересно как это он сделал?

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

не совсем понял как, смотри:

а. кол-во данных в сек. которые может считать/записать видео карта в своей локальной памяти = фиксировано (частота памяти * мультипликатор-ддр * (битность шины / 8) )

б. кол-во таков на гпу = фиксировано (частота гпу), каждая инструкция шейдера занимает сколько-то тактов, и как бы отъедает от этого пирога мощности в сек.

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

кол-во тактов будет затрачено в конечном итоге одно и тоже.

чего я упустил?

[s-andriano]

Сообщение от intmain

Вот Кармак когда показывал свои 3д очки на одном из роликов на ютубе ругался что пришлось много работать и исправлять баги в драйверах нвидия, типо ему пришлось драйвера заново переписывать интересно как это он сделал?

Правильнее ставить вопрос:
Почему ему пришлось это делать?

а. кол-во данных в сек. которые может считать/записать видео карта в своей локальной памяти = фиксировано (частота памяти * мультипликатор-ддр * (битность шины / 8) )

б. кол-во таков на гпу = фиксировано (частота гпу), каждая инструкция шейдера занимает сколько-то тактов, и как бы отъедает от этого пирога мощности в сек.

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

кол-во тактов будет затрачено в конечном итоге одно и тоже.

чего я упустил?

Во-первых, Ваше утверждение "а" противоречит утверждению "б": либо у нас процессор вынужден ждать данных от памяти и при этом количество его тактов оказывается больше расчетного. Либо процессор ничего не ждет - тогда получается, что пропускная способность памяти используется не полностью, т.е. по факту меньше расчетной.
Другими словами, имеется эффект "слабого звена" производительность системы по сути является функцией минимума от производительности процессора и памяти. Правда, каждая из них входит со своим коэффициентом, а величина коэффициента, в свою очередь, зависит от применяемого алгоритма. Поэтому программист в какой-то мере способен на них влиять.
Но в целом производитель старается так спроектировать видеокарту, чтобы отношение коэффициентов на среднестатистическом алгоритме было близко к единице.
Отсюда и возможный ответ на Ваш вопрос: почему мультитекстурирование ограничено определенной константой - потому, что больше окажется неэффективно из-за ограниченной пропускной способности памяти.

[Пепел Феникса]

Сообщение от intmain

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

кол-во тактов будет затрачено в конечном итоге одно и тоже.

чего я упустил?

сравните вагон и тележку, разница есть?
вы раз в сек запускаете по тележке или же раз в сек по вагону.

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

там много чего есть.

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

а что за видяха?

[intmain]

у нас процессор вынужден ждать данных от памяти

это можно посмотреть профилировщики шейреров к примеру, простой шейдер с чтением из текстуры. я где-то читал что на geforce fx чтение занимало до 20 тактов, поэтому там много раз думали а стоит ли еще раз читать текстуру для какого-нибудь fx. В современных картах чтение, очевидно на порядок меньше тактов занимает.

Либо процессор ничего не ждет - тогда получается, что пропускная способность памяти используется не полностью

достаточно запустить GPU-z и какую-либо игрулю в окне и пронаблюдать показатель memory controller, в зависимости от игры он может грузиться полностью а может только на 50% (все это с выключенным ограничением на фпс естественно) тут все зависит насколько игра требовательна к пропускной способности памяти и насколько интенсивно она ее использует. т.е. насколько интенсивно шейдеры производят чтение запись в текстуры, геометрию, проходы с постпроцессов.

Другими словами, имеется эффект "слабого звена" производительность системы по сути является функцией минимума от производительности процессора и памяти

именно. чем выше потолок у обоих тем топовей карта.

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

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

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

видяха мечтает об неизменяемых стейтах о едином большом заливе геометрии на кадре (либо вообще его отсутствии, залив только при загрузке), и глупом шейдере. а в типичном случае она будет постоянно дергаться:
1. установкой нового шейдера
2. обновлением униформ
3. установкой текстур
4. установкой геометрии
5. прорисовкой
вот эти дергания много отедают от пирога производительности.

а что за видяха?

Я вообще про любую современную и не очень. А у мну интель хД какой-то.

[s-andriano]

Сообщение от Пепел Феникса

там много чего есть.а что за видяха?

Как раз от видяхи это не зависит.
Это общий принцип.

[s-andriano]

Сообщение от intmain

...чтение занимало до 20 тактов...В современных картах чтение, очевидно на порядок меньше тактов занимает.

Очевидно?
Лично я не знаю ни одного довода за то, чтобы это вообще было правдой.
Если это для Вас очевидно, приведите хотя бы пару-тройку доводов "за" то, что скорость чтения, измеряемая в тактах GPU, вообще хоть как-то увеличилась, не говоря даже об увеличении на порядок.

достаточно запустить GPU-z и какую-либо

Достаточно для чего?
От запуска GPU-z что, пропускная способность памяти увеличится?

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

1. Хардверное ограничение - вполне резонный вариант (один из). Известно, что GPU - векторный процессор. Если длина вектора позволяет одновременно обработать 8 текстур, значит, если мы будем брать от 1 до 8 текстур, скорость выполнения именно этой операции никак не изменится (возможно, изменится время загрузки и выгрузки вектора), но как только у нас появится 9-я текстура, вместо одной операции потребуется провести две, от чего производительность скачком уменьшится.
2. Вспоминаем, что OpenGL - система, служащая для того, чтобы оградить разработчика от железа. Поэтому он должен выполнять любые функции вне зависимости от того, поддерживаются они железом или нет. Если, скажем, никакое мультитекстурирование не поддерживается железом в принципе, значит все равно в информационную функцию нужно выдать какое-то число. И вполне резонно предположить, что это число будет выбрано разработчиком с учетом баланса производительности GPU и памяти.

вот эти дергания много отедают от пирога производительности.

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

[intmain]

Очевидно?
Лично я не знаю ни одного довода за то, чтобы это вообще было правдой.

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

Достаточно для чего?

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

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

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

[Пепел Феникса]

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

почитайте про SIMD операции, видяха практичекски вся обрабатывает именно так данные.