LINUXTALKS.CO

Apple считает, что её компьютеры Mac в будущем вполне могут стать игровыми решениями

 

L


0

1

Разработчики игр никогда не видели 96 ГБ графической памяти, доступной им сейчас, на M2 Max. Я думаю, что они пытаются понять это, потому что возможности необычны. Они привыкли работать с гораздо меньшим объемом видеопамяти. Поэтому я думаю, что это еще одно место, где у нас будет интересная возможность вдохновить разработчиков выйти за рамки того, что они делали раньше

★★★★★
Ответ на: комментарий от Oberstserj

Реальное значение имеет только та видеопамять, которую видеокарта использует в цикле рендеринга кадров, а это два, максимум три гигабайта, вся остальная видеопамять это по сути кеш и стоит ли он тех денег, что стоит 92 Гб ОЗУ?

torvn77    
★★
Linux / Chrome
Ответ на: комментарий от torvn77

Ну здесь ты не совсем прав. Никто не запрещает тебе забить конвейер видеопамяти под завязку. Вопрос в доступе, какие рамки даст ОС. Меня всегда умиляли яббл тем, что они ноют о том, что игроделы не смотрят в их сторону, но сами не дают инструментария. Вот очередное нытье. Ну пусть ноют дальше, пока не поймут.

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от Minona

Там написано что инструментарий будет.

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

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от Oberstserj

Вопрос в доступе, какие рамки даст ОС.

Если говорить о памяти выше этих двух трёх гигабайт то она ФИЗИЧЕСКИ не может участвовать в реалтайиовом рендеринге кадра, потому что эти два три гига получаются как отношение пропускной способности шины памяти видеокарты к частоте кадров, можно запихнуть сколько угодно ОЗУ, на обращение к большему просто не хватит пропускной способности шины.

В М-процах память унифицированная.

@Minona ввиду вышенаписанного это либо не играет ни какой роли, либо только усугубляет ситуацию делая размер реально используемого буфера ещё меньше.

torvn77    
★★
Android / Chrome
Ответ на: комментарий от torvn77

она ФИЗИЧЕСКИ не может участвовать в реалтайиовом рендеринге кадра

А причем тут именно реалтайм? Рассматривай эту память как кэш например.

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

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от Oberstserj

Рассматривай эту память как кэш например.

Чтобы обратится к этому кешу ты должен израсходовать время работы шины памяти, а оно у тебя всё занято текущим кадром.

И ещё под кадром следует понимать не двумерную картинку, а всю совокупность моделей, текстур и шейдеров используемых для его рендеринга.

torvn77    
★★
Android / Chrome
Ответ на: комментарий от torvn77

Чтобы обратится к этому кешу ты должен израсходовать время работы шины памяти, а оно у тебя всё занято текущим кадром.

Ля..а системной информации у нас на шине как будто не существует? Одна картинка на шине? Нет конечно. Ну и запихни сначала пресеты в видеопамять и оперируй ими как примитивами. Ты наоборот шину высвобождаешь. (Разумеется это фантазии, я хз чо там яббл за инструментарий даст. Очевидно, что придется напрямую доступ к железу давать)

И ещё под кадром следует понимать не двумерную картинку, а всю совокупность моделей, текстур и шейдеров используемых для его рендеринга.

И ясен пень, что все это не будет постоянно занимать шину.

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от Oberstserj

И ясен пень, что все это не будет постоянно занимать шину.

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

torvn77    
★★
Android / Chrome
Ответ на: комментарий от torvn77

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

А чо не килобайт? Шина ж занята, позвоните попозже? А если вспоминать, что еще и с цветами надо работать, то получается три шины надо. Ужас, ужас!

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от torvn77

можно запихнуть сколько угодно ОЗУ, на обращение к большему просто не хватит пропускной способности шины.

Ну давай сравним:

Designed for the most demanding gamers, content creators and data scientists, the GeForce RTX 3090 Ti features a record-breaking 10,752 CUDA cores, and boasts 78 RT-TFLOPs, 40 Shader-TFLOPs and 320 Tensor-TFLOPs of power. And It's packed with 24GB of the fastest 21Gbps GDDR6X memory.
M2 Max - 400GB/s of unified memory bandwidth.
M2 Pro - 200GB/s of unified memory bandwidth.
M2     - 100GB/s of unified memory bandwidth.

Хватит тебе пропускной способности?

Minona    
★★★★★
Windows / Yandex
Ответ на: комментарий от Minona

M2 Max - 400GB/s of unified memory bandwidth.

Пусть частота кадров будет 15 герц, тогда размер задействуемого в работе ОЗУ
(400GB/s)/(15Гц)=26.5 ГБ.

В общем если вас устраивают современные стандарты Киберпанка с его знаменитыми 15 FPS в секунду то размер используемого ОЗУ будет аж целых 26 Гигов, но вот если захочется 60 FPS, то размер буфера уже будет всего чуть меньше 7 ГБ.

Это конечно лучше чем у современных карт, но это по прежнему не те самые 96ГБ

torvn77    
★★
Последнее исправление: torvn77 (всего исправлений: 2)

Linux / Chrome
Ответ на: комментарий от torvn77

Это что за буфер ты посчитал?

но лучше бы для этого использовать не отдельное ОЗУ, а кеш внутри чипа.

В моём i5-9400 L2 кэш ~400ГБ/с выдаёт, а память 40.
А теперь скажи, где ты видел L2 кэш на 7 ГБ?

Minona    
★★★★★
Windows / Yandex
Ответ на: комментарий от torvn77

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

Это теоретически отвлечённый случай в котором точно определено какая именно информация и в каком порядке будет использована для рендеринга. И это верно в случае статической сцены. Но если предположить что у нас несколько тысяч детализированных моделей, например персонажей, которые в любой момент могут появится в кадре и не исключено что все сразу, тогда требуется возможность очень быстро данные получать. К тому же, не всё что видеокарта считает, в итоге попадает на дисплей. Графический движок может рендерить то что будет заслонено от «камеры», только для того что бы от этого упали какие то отражения или тени. Например в движке какой то из частей X-com зелёные изгороди полностью рендеряться даже если не показываются, видимо для предотвращения каких то ошибок.

по сути кеш

Кэш стоит своих денег, хотел я было написать, но сформулирую по другому. Запас жопу не ебёт. Дело не в пропускной способности шины PCI-E, а в её задержках, плюс задержках ОЗУ. Постоянное тасование текстур между ОЗУ и видеопамятью увеличивает время отрисовки кадра. Как среднее, так и периодическое пиковое. А это раздражает.

rezedent12    
★★★★★★
Windows / Firefox
Ответ на: комментарий от torvn77

Идиот

По древнеримскому определению, человек живущий вне политики. Ты ошибся, я вовлечен в общественную жизнь.

если не хочешь разбираться в вопросе то просто игнорируй тред.

Ну дык ты сам-то хоть в состоянии свои суждения подтвердить? Пока только слюной брызжешь. Давай таймслоты сигналов на шине разбирать. Если конечно ты сам понимаешь о чем вообще говоришь.

Oberstserj    
★★★★★
Последнее исправление: Oberstserj (всего исправлений: 1)

Ubuntu / Firefox
Ответ на: комментарий от rezedent12

Кэш стоит своих денег, хотел я было написать, но сформулирую по другому. Запас жопу не ебёт. Дело не в пропускной способности шины PCI-E, а в её задержках, плюс задержках ОЗУ. Постоянное тасование текстур между ОЗУ и видеопамятью увеличивает время отрисовки кадра. Как среднее, так и периодическое пиковое.

@torvn77, заметь, Петр и то лучше тебя понимает вопрос. Счетовод-делитель блин.

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от torvn77

Я нашёл опровержение твоей формулы.
На ютубе тест 2070.
По спекам пропускная памяти 448 ГБ/с.
В тесте игра жрёт 6700 МБ видеопамяти и выдаёт 77 к/с.
6700*77/1024=503 ГБ/с.

Upd:
Тест 1650 в CS:GO
2.4 ГБ * 360 к/с = 864 ГБ/с
А псп по спекам 192 ГБ/с

Minona    
★★★★★
Последнее исправление: Minona (всего исправлений: 1)

Windows / Yandex
Ответ на: комментарий от Minona

6700*77/1024=503 ГБ/с.

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

Тест 1650 в CS:GO
2.4 ГБ * 360 к/с = 864 ГБ/с
А псп по спекам 192 ГБ/с

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

torvn77    
★★
Linux / Chrome
Ответ на: комментарий от torvn77

Совпадает с допостимой погрешностью

12% - допустимая погрешность?
🤦‍♂️

2.4 ГБ * 360 к/с = 864 ГБ/с
А псп по спекам 192 ГБ/с

Это может так же означать

Это означает что твоя формула - хрень.

Minona    
★★★★★
Windows / Yandex
Ответ на: комментарий от Minona

Это означает что твоя формула - хрень.

Это означает что я вежливый человек и оставляю некоторое место для твоего "лица" с которым у тебя проблемы, так как мог бы сам сообразить то, что вполне можно увеличить частоту кадров за счёт уменьшения используемого объёма ОЗУ.

torvn77    
★★
Android / Chrome
Ответ на: комментарий от torvn77

можно увеличить частоту кадров за счёт уменьшения используемого объёма ОЗУ

Никак не могу отделатся от мысли что ты шиз. В разы больший чем я.

Частота кадров зависит главным образом от времени прорисовки кадра. Текстуры большего размера могут увеличивать время их обработки. Но сам по себе используемый объём памяти не влияет на время кадра.

Когда то раньше была создана специализированная шина для подключения видеоадаптёров, называемая AGP. Суть её была в том, что она позволяла подключать графический процессор напрямую к оперативной памяти. Недостатком этого метода при использовании динамической памяти, а это безальтернативный вариант в современных персональных компьютерах, является конкуренция между центральным процессоров и видеопроцессором за пропускную полосу видеопамяти. В итоге значительная часть быстродействия ОЗУ тратиться даже не на выборку данных, а на переключение страниц. Центральный процессор требует максимально быстрого переключения страниц памяти, так как выполняет наборы инструкций с произвольными переходами. Видеопроцессору требуется высокая скорость потока данных, так как он обычно работает с текстурами. То есть страницы памяти можно сделать большими, а переключение между ними медленным.

Поэтому стандарты ОЗУ и видео ОЗУ значительно различаются.

Однако многоядерность привела к росту кэша, поэтому у современных центральных процессоров снизились требования к скорости переключения страниц, но поднялись к пропускной способности. Современная память DDR4 и DDR5 имеет большие размеры страниц чем у DDR3. Что приблизило её к видеопамяти, нередки случаи когда собирают компьютеры для игр со встроенной в ЦП графикой на быстром ОЗУ. В такой архитектуре видеоускоритель принципиально не отличается от ещё одного ядра центрального процессора, а планированием доступа к страницам памяти управляет общий блок. По сути именно большой кэш L3 сделал доступными минимальные издержки такого использования оперативной памяти.

rezedent12    
★★★★★★
Windows / Firefox
Ответ на: комментарий от Minona

Не забывайте, что значительная часть bandwidth расходуется на копирование данных из памяти ОЗУ в память видеокарты.

В данном случае это не нужно.

grim    
★★★★★
Android / Firefox
Ответ на: комментарий от Minona

Там написано сколько VRAM используется - 2.4 ГБ.

Хорошо, давай пруф на тест, буду смотреть какие особенности привели к такому результату(это если ты ничего не напутал)

torvn77    
★★
Последнее исправление: torvn77 (всего исправлений: 1)

Android / Chrome