Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - nonamezerox

Страницы: Назад 1 2 [3] 4 5 6 Далее
61
Я может, открою многим здесь Америку, но я нашел причину медленной загрузки кэша при повторных запусках (когда может грузиться по полчаса).

Да, открыл. Причем именно об этом и именно тебе и писал еще месяц назад.

Еще раз.

В долфине решили проблему путем полной эмуляции FIXED FUNCTION PIPELINE видеопроцессора Flipper, и, до этого у ишируки, путем пропуска пиксельной части этого самого PIPELINE.

В видеопроцессоре RSX - PROGRAMMABLE PIPELINE. Его нельзя заэмулировать целиком с помощью огромного шейдера, как это сделали в долфине.

P.S. С кешем rpcs3 проблема в том что он сделан неправильно. Он вообще сохраняет непереведенные программы RSX (то бишь в родном формате PS3), в то время как нужно сохранять уже скомпилированные  шейдеры под конкретный бэкенд.

По этому поводу BlackDaemon тогда ответил, что с текущей архитектурой эмулятора ждать исправления не скоро но стоит, потому что декомпилятор (часть кода, занимающаяся разбором декодированием микрокода кода RSX перед генерацией кода для ПК) у них все время правится и кеш в "родном формате" по этой причине будет постоянно "ломаться" при переходе на новый билд эмулятора и нужно ждать либо переписывания либо стабилизации кода этого самого рекомпилятора. И каких либо оптимизаций в этом плане тоже ждать только после того как эпопея  с декомпилятором разрешится.

62
Как всегда PSP версия рулит)

В этой игре на pcsx2 internal resolution только нативное работает, что ли?

63
Вспомни тех маэстро, что писали код на чистом ассемблере, и где они сейчас.

Там же где и раньше, последние 20 лет - микроконтроллеры, встраиваемые системы и прочий эмбед.

Слыхал, специалисты/писатели, способны на МНОГО более, чем позволено железу. Разве нет?

Конечно нет. Опитимизировать можно только неэффективные алгоритмы и, затем, неэффективные реализации, если модификация самих алгоритмов не помогает.  В любом случае, скорость железа тут предел, если не брать в расчет разномастный оверклокинг. И  в случае эмулятора правило "1 такт эмулируемой машины =  N тактов той, где запущен эмулятор" не обойти никак, можно лишь уменьшать это самое N, как правило путем различных упрощений вроде HLE, JIT-рекомпилятора, замены геморного по производительности функционала хаками на каждую конкретную игру.

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

Добавлено позже:
Нынче практически всецело полагаются на вычислительные мощности, нежели на прямые руки. Ты так не считаешь?

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

65
Расскажите как убрать убогие мешающие тени

1) Перестать пороть чушь, не разбираясь в вопросе
2) https://tortoisegit.org/
3) https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=Community&rel=15
4) https://tortoisegit.org/docs/tortoisegit/tgit-dug-clone.html
5) ??????
6) Компилируем эмулятор
7) Заходим в игру
8) Видим багу
9) ???????
10) https://developer.nvidia.com/nvidia-nsight-visual-studio-edition
11) http://gpuopen.com/compute-product/codexl/
12) Что бы понимать, что искать, читаем: http://www.opengl-tutorial.org/ru/intermediate-tutorials/tutorial-16-shadow-mapping/
13) С помощью п10 или п11 (в зависимости от видеокарты) ищем где проблема
15)??????
16) Правим код (файлы https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/Common/FragmentProgramDecompiler.cpp, https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/Common/FragmentProgramDecompiler.cpp и их соответсвующие реализации в папках каждого рендера)
17) Отправляем PR на https://github.com/RPCS3/rpcs3/
18) ??????
19) PROFIT!!!!!

66
А так,ваши домыслы,это все в зад и глубоко. :neznayu:

Ну то что вы невежа это понятно, можете не продолжать.

Цитата
Видео действительно в эмуле работает на 20/30%,а проц маслает очень шустро.Я с 8-ю потоками могу поиграть наверное только в тетрис без лагов,а вот Redemption убивает проц в почти 100%  0_0

Собственно, поэтому и не понимаете, почему это происходит и придумываете разный бред своего воспаленного сознания.

67
Обработка вершин переехала с CPU на GPU, после чего ты и начал говорить, что всё пропало, верните всё в зад.


68
Кэш делается под GPU
Сейчас кеш сделан под тупо сохранение микрокода RSX в неизменном виде.

Добавлено позже:
Мне не ясно почему они ни какие операции карте не отдают.

Потому же почему нельзя заменить карьерный самосвал спорткаром. И наоборот.

CPU и GPU это два разных по своей идеологии вычислительных устройства и то что хорошо работает на одном не всегда будет хорошо работать на другом.

GPU - заточен под однотипную обработку больших масивов данных, с результатом в виде большого массива данных.  Если нет массива данных, то и нет смысла перекладывать это на GPU. Далее, GPU достаточно тяжело переносит операции ветвления, из-за своей параллельной архитектуры (не забываем, что "потоки" в терминах GPU - это именно потоки входных данных, а не потоки выполнения независимых программ, как у CPU). И если у нас есть условие
if(a>b){
do_something
}else{
do_another
}
То на GPU будут выполнены ОБЕ ветки условия, потому что в обрабатываемом массиве не одна пара переменных a и b, а несколько. И ГПУ будет работать так, проверит для каждой пары во входном массиве условие, "выключит" те потоки где это условие ложно, выполнит алгоритм для оставшихся "включенными" потоков, затем включит выключенные, выключит включенные и выполнит вторую ветку условий.

Из этого же вытекает следующее - GPU крайне так же хреново выполняет алгоритмы типа Reduce (свертки данных, когда у нас на входе много чисел а на выходе - одно), поскольку его "потоки данных" ничего не знают друг о друге и именно в связи с этим ограничением у GPU и такие цифры производительности в гигафлопсах, по сравнению с CPU.

То бишь задача GPU - выполнение относительно несложных алгоритмов над большими объемами  однотиных данных. При несоблюдении всех условий (сложность алгоритма, малые объемы данных, выполнение "горизонтальных операций" между соседними элементами этих самых массивов данных) от GPU толку не будет.

То есть если у нас массив {a1,a2,a3,a4,a5,...an} и нам нужно сложить все элементы массива - то не покатит.

Если у нас два массива {a1,a2,a3,a4,a5,...an} и {b1,b2,b3,b4,b5,...an} и нам нужно на выходе получить массив {a1+b1,a2+b2,a3+b3,a4+b4,a5+b5,...an+bn} - то отлично, данная задача подходит для выполнения на GPU и теперь вопрос в количестве n, если оно мало  (меньше общего количества нитей GPU), то его выгоднее выполнить на CPU, потмоу что затраты на установку задачи и на команды получения результата GPU будут больше чем время её выполнения.

С условиями - если алгоритм содержит много операторов if  и условие в этих операторах зависят от отдельных элементов массивов данных - то алгоритм будет выполняться медленно, и огромное количество поотоков тут не поможет. Если в условии - какая либо глобальная константа (uniform -переменная в терминах OpenGL), одинаковая для всех потоков - то тут проигрыша в производительности не будет, поскольку условие одинаково для всех потоков и другие ветки выполняться не будут.

69
Быть может, надумают некий "анализатор данных" образа игры, кой способен будет заранее записать все возможные варианты шейдеров на винт

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

70
Следовательно, алгоритм обработки шейдеров был другой - видимо какой-то реалтаймовый интерпретатор.

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

во время компиляции лично у меня идёт чудовищная нагрузка на процессор

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

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

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

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

Так что остается надеяться и страдать.

71
лично для меня даже если в итоге это всё обойдется в 500р за одну интересующую игру - это уже не приемлемо... а если таких игр 5, 3, или 1?

Тогда отстегиваешь 10 рублей за фатку / прошиваемую слимку. Вернее можно за те же 5 найти.

72
Молочные кексики, как раз таки я жду эмулятор чтоб некоторые эксклюзивы поиграть. Ради игр жду

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

73
Процессор не совместим

Хм, надо же существуют кордвадуба без поддержки 64бит, всегда думал что это только атомов ранних касалось, а у пней и всех последующих коров все 64 битное начиная с пень4 прескотов еще под 478 сокет.

74
BlackDaemon,

Так я про
Цитата
first time compilation
и имел в виду, думает ли он в вулкановском (и в опенгловском у кого поддерживается 4.6) рендере переходить от генерации GLSL к генерации бинарного SPIR-V. Это же должно работать быстрее для как на стороне эмулятора (работа с числами и побитовыми операциями вместо работы с текстовыми строками + исключение из процесса glsl->spv компиляции), так и на стороне драйвера.

75
Насчёт DX12 сомневаюсь, что что-то будет, т.к. на текущий момент им никто из разработчиков не занимается, в настройках выбора рендера к DX12 уже дописано "[DO NOT USE]". По варианту для Vulkan буду ждать ответа от kd-11 :)

К слову, отрелизили уже опенгл 4.6 где тоже добавили возможность шейдеров SPIR-V

76
Не надо по стопам stalker4 путать кэширование шейдеров с их компиляцией. Речь именно о компиляции, вне зависимости от того есть ли в эмуле функция кэширования. OGL более процессорозависимый и это может давать бОльшие просадки при компиляции шейдеров, хотя у себя я особой разницы не вижу. Ну пользуйся Vulkan-ом. Лучшей альтернативы всё равно не наблюдается (об этом ниже).

Единственное что им более-менее сможет помочь в случае хардварного рендеринга, это уход от HLSL/GLSL в сторону бинарных DXIL/SPIR_V, они чуть пошустрее должны компилироваться, все же байткод,  а не текстовый высокоуровневый язык. Ну и в кеш писать тоже их (у опенгл тут киллер-фича в виде glGetProgramBinary, которая вообще нативный для видюхи компа бинарник возвращает), а не нвидиевские бинарники, хоть в таком случае и страдает актуальность кеша при переключении бэкендов.

77
Почитайте, что ли, как в Дельфине решили эту проблему - http://emuplace.com/news/novosti_ehmuljacii/3484-progress-emulyacii-iyul-2017.html...

Еще раз.

В долфине решили проблему путем полной эмуляции FIXED FUNCTION PIPELINE видеопроцессора Flipper, и, до этого у ишируки, путем пропуска пиксельной части этого самого PIPELINE.

В видеопроцессоре RSX - PROGRAMMABLE PIPELINE. Его нельзя заэмулировать целиком с помощью огромного шейдера, как это сделали в долфине.

P.S. С кешем rpcs3 проблема в том что он сделан неправильно. Он вообще сохраняет непереведенные программы RSX (то бишь в родном формате PS3), в то время как нужно сохранять уже скомпилированные  шейдеры под конкретный бэкенд.

78
Я не вникал в тонкости так называемой "тяжёлой компиляции шейдеров" во время игрового процесса, но мне это не по нраву ещё со времён Demul'а / Dolphin'а.

Ну и зря не вникал. Тонкости такие, что этим делом занимаются сторонние и абсолютно ну вообще никак не зависящие от разработчиков эмулятора программы в лице Microsoft Directx(r), AMD Catalyst(tm) и GeForce GameReadyDriver(tm). И по другому с видеокартой в рамках операционной системы Windows тупо работать нельзя.

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

Ну, рецепт известен - софтовый рендер. Это вообще все проблемы с эмуляцией GPU снимет.

Добавлено позже:
BlackDaemon,

Кстати, раз уж тут многие интересуются скоростью компиляцией шейдеров, спроси kd-11, что он думает о перспективе создания нового бэкенда для DX c компиляцией в DXBC (а по-хорошему в DXIL). И нового бэкенда для вулкана c компиляцией в SPIR-V binary

79
Меня гложет уверенность что можно было обойтись и без этой функции, другие же эмули без нее обходятся

Какие эмули? Приставок позапрошлого поколения и далее до атари 2600?. Дык, ясен болт.




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

Тут затык на стороне сторннего софта (драйвера видеокарты, встроенного туда компилятора шейдерного языка и невозможности использовать шейдеры в DX, OGL, Vulkan как-либо в обход компилятора. У вулкана и DX, правда, есть более низкоуровневые языки , но это по-прежнему требующий компиляции язык программирования, написанный буквами, и максимум что можно будет с этого получить - подфризы чуть короче).

81
stalker4, еще раз.

DX и OpenGL принимают шейдеры только в формате исходного кода на языке высокого уровня (GLSL и HLSL) путем последующей компиляции этого исходного кода в машинный код конкретной видеокарты. Тупо потому что у видеокарт разных производителей разная архитектура и даже в рамках одного модельного ряда одного производителя архитектура и система команд может отличаться. На PS3 шейдеры компилируются на стороне разработчиков  при разработке и сборке игры и лежат на диске игры уже в виде машинного кода, потому что видеокарта, в отличии от ПК на PS3 одна - единственная. Чтобы шейдер с диска игры PS3 эмулировать на ПК, его нужно сначала перевести с низкоуровневого машинного кода Nvidia в высокоуровневый код на языке программирования GLSL (или HLSL, если речь про DX, выполняется эмулятором), а затем скомпиллировать обратно с этого языка уже в машинный твоей видеокарты (выполняется драйвером твоей видеокарты). Эта процедура достаточно длительная и от этого никуда не убежать, потому что так устроены GAPI, так устроены видеокарты и подфризы будут в любом случае хоть с кешем хоть без, просто с кешем они будут однократно.

82
 
может в будущем возьмут опыт у Phire  и о его технологии Ubershaders 


ли он настолько же быстр=эффективен как и у убершейдера?

Как только libshaman и libnosterdame, отрелизят так сразуже.

83
Softer,

Добавлено позже:
гибридный режим вообще потребляет столько же ресурсов
Естественно, потому что он на 1 кадр врубается. С онли убершейдер режимом плагин превращается в хороший такой бенчмарк для видеократ.

84
Softer, как раз дело в том, что на GPU Wii шейдеров нет - там GPU в целом напроминающий GF1-2 с похожим FFP функционалом. И этот самый гпу возможно целиком заэмулировать с помощью одного громадного шейдера, что в долфине и сделали, когда железо стало это позволять. До этого у них на каждую установку FFP параметров гернерился отдельный шейдер.

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

Если же речь об интерпретации и выполнении машинного кода шейдеров WiiU целиком силами видеокарты ПК - то, скорее всего, маловероятно, хотя в последних версиях GAPI и последних видеокартах - и возможно. Но работать это будет очень плохо - видеокарта  для таких задач с кучей ветвлений, циклов чтения данных  и длинным кодом малоприспособлена. В будущем, когда ситуация с производительностью и функционалом изменится - возможно будет даже и лучше, чем в нынешнем варианте, когда скомпилированный код шейдеров приставки декомпилируется обратно в исходник на HLSL/GLSL и затем повторно компилируется драйвером.

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

Тут все просто - в Dolphin'e убершейдеры можно сделать, у Cemu  - нельзя. Тупо потому что соврешенно разные GPU.

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

Дык они вроде как спрятаны изначально и так были

87
Ликбез.

Вот это вот называется шейдер:


Вот это называется материал:

Вот это называется постэффект:

Не путай их. Шейдер - это программа для GPU, результат её работы  - не обязательно материал или постэффект. (На самом деле в современных OpenGL и DirectX (современные - это все что новее 10-летней давности) не написав шейдер ты кроме закрашенного одним цветом экрана не сможешь вывести ничего, даже графику уровня PS1).

Красота на экране - это не шейдер, это либо результат его работы, или специально запеченная в профессиональном 3д-рендере красивая текстура, которую ты по незнанке принял за эффект или материал расчитаный  шейдером (собственно, те "шейдеры", которые ты "видел" на PS2 - именно оно)

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

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

89
Меса вроде бы враппер opengl->software, ей всё равно какой gpu. Галиум без месы я найти не смог, я даже не очень понял что это. Вики пишет - прослойка между API и драйверами. То есть это для драйвероделов, что ли? Generic библиотеки для использования внутри самих драйверов? В общем тут я не разобрался...

Собственно меса - это такая опенсорсная реализация стека OpenGL (в основном под unix-подобные операционные системы, то бишь линукс бсд и так далее), Gallium уже давно является неотъемлимой частью этой самой месы и представляет собой промежуточный интерфейс перед драйвером поверх которого можно теоретически хоть OpenGL хоть DirectX реализовывать (вот эту фишку, емнип, использует только вайн для реализации DX без промежуточной прослойки в OpenGL, но чтобы это включить там нужно емнип самому копилировать с каким-то ключом), то бишь скорее для API-делов. Так же меса включает в себя опенсорсные драйвера, кои к слову не все используют галлиум, например интеловские галлиум не используют и реализуют опенгл напрямую. Так же в месе есть три драйвера эмулирующие видеокарту на CPU (llvmpipe- самый новый, быстрый и функциональный (реализует вплоть до Opengl 3.3)). Вот эти софтварные драйверы и можно компилировать под виндовс в качестве dll библиотек (хардварные, по понятной причине несовместимости интерфейсов OS windows и linux, нельзя ). Ну и под линукс есть еще проприетарные драйвера которым меса не нужна в принципе.

90
Softer, как я понял, у него скомпиленая под винду меса 3д, которая после компиляции дает програмный эмулятор/рендер Opengl. И поверх него накачены вайновские врапперы DX-OGL. То бишь 3д у него програмно эмулируемое путем линухового рендера из месы под винду.

Страницы: Назад 1 2 [3] 4 5 6 Далее