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

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


Сообщения - nonamezerox

Страницы: Назад 1 ... 3 4 5 6 [7] 8 Далее
181
MetalliC, не, depth peeling это именно то что у тебя в GPU плагине реализовано, а в пдфке речь идет о Weighted Blended OIT, которая как раз работает без слоев и ей нужно только MRT в два таргета и  два прохода, для исходных данных подготовка не требуется, параметрами алгоритма являются z-координата и финальный rgba цвет фрагмента:

Цитата
Первый проход:
// Output linear (not gamma encoded!), unmultiplied color from
// the rest of the shader.
vec4 color = ... // regular shading code

// Insert your favorite weighting function here. The color-based factor
// avoids color pollution from the edges of wispy clouds. The z-based
// factor gives precedence to nearer surfaces.
float weight =
      max(min(1.0, max(max(color.r, color.g), color.b) * color.a)), color.a) *
      clamp(0.03 / (1e-5 + pow(z / 200, 4.0)), 1e-2, 3e3);
 
// Blend Func: GL_ONE, GL_ONE
// Switch to premultiplied alpha and weight
gl_FragData[0] = vec4(color.rgb * color.a, color.a) * weight;

// Blend Func: GL_ZERO, GL_ONE_MINUS_SRC_ALPHA
gl_FragData[1].a = color.a;

Второй проход:
vec4 accum = texelFetch(RT0, int2(gl_FragCoord.xy), 0);
float reveal = texelFetch(RT1, int2(gl_FragCoord.xy), 0).r;
 
// Blend Func: GL_ONE_MINUS_SRC_ALPHA, GL_SRC_ALPHA
gl_FragColor = vec4(accum.rgb / max(accum.a, 1e-5), reveal);

182
MetalliC, кстати, вот вопрос давно у меня зрел, а вот так почему нельзя и где подводные камни? Или тут есть ньюансы, которых в depth peeling нет?

183
или наоборот ужимается в тех 3х играх что рендерят в 1280.
Но нафига? Или это такой ленивый порт с аркадок чтобы ассеты не перерисовывать?

185
Цитата
использует не весь DX12 а лишь API

Огнетушитель опустошен и теперь по теме:

Собственно, отличие DX12 от DX11 вкратце описано на MSDN:

Цитата
To improve the CPU efficiency of Direct3D apps, Direct3D 12 no longer supports an immediate context associated with a device. Instead, apps record and then submit command lists, which contain drawing and resource management calls. These command lists can be submitted from multiple threads to one or more command queues, which manage the execution of the commands. This fundamental change increases single-threaded efficiency by allowing apps to pre-compute rendering work for later re-use, and it takes advantage of multi-core systems by spreading rendering work across multiple threads.

Сжато пересказывая на русский язык:
Отличием DX12 от его предшественника является система списков команд, которые пришли заместо старой концепции (на самом деле нет, наоборот вернулись к еще более старой но переосмысленной  концепции очень старых версий opengl и directx) немедленного выполнения, то бишь в DX11 отдельные этапы приготовления грофона (загрузить текстуру, загрузить меши, загрузить шейдеры, привязать параметры к шейдерам и.т.д.) выполняются непосредственно при вызове соответствующих методов, а в DX12 они вместо этого запихиваются по очереди в промежуточный буфер команд и уже после этого отдается команда выполнить их все вместе. А все остальное там практически то же самое.

Нафига это сделали? Ну в первую очередь потому что многопоточность, с которой даже последние DX10 и DX11 не особо то и дружили. То бишь несмотря на многопоточность игры, непосредственное  взаимодействие с видеокартой можно было делать только в одном потоке, а остальные занимались либо прочими вещами, либо подготавливали для этого потока данные. Вторая (ну и собственно, самая распиаренная) причина - оверхед (то бишь, грубо говоря, штраф) на вызовы отдельных этапов приготовления грофона в сложных случаях. То бишь если мы для отдельных объектов много-мого раз дергаем методы immediate api, то получаем кучу бесполезного простоя видеокарты, а если мы объединим их и отправем видеокарте пачкой то получаем выигрыш в производительности.
Для интересующихся, примерный прейскурант оверхеда (в версии Nvidia) выглядит так:

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

Теперь собственно насчет эмулятора и "где наши обещаные ФПС????!!!!111111адинадин" -  да нигде, эмулятор он по определению CPU-bound, сфигали там производительность должна была подняться, если DX12 решает проблемы сугубо многопоточности (а обе эмулируемые консоли однопроцессорные) и drawcall-overhead, который в играх GC/Wii в целом на уровне соответствующих лет? "Так ваще от него будет какой-то толк???" - теоретически будет для тяжелых в плане грофона игр вроде баттлефронта где как раз в оригинале идет изнасилование именно GPU многоэтапным рендерингом с сохранением промежуточных результатов, и то, это если перепишут полностью GPU подсистему, тащемта.

186
абсолютно верно.
и как показала история это всё CISC-овое оказалось тупиковым направлением развития.
где эти все М68К или нестоящие/нативные х86 ? а нету.
лишь нынешние i686 с RISC ядром внутри.

Ну, по факту нет, победил не RISC, а Le Priborchique™ :D. А настоящие RISC  интел вышеб с рынка один  за одним. Да и те которые RISC которые еще живые (вроде ARM) по факту тоже начали использовать Le Priborchique™ и обрастать кучей команд.

Все же risc/cisc оно про ISA, а не про microarchitecture, а по этому критерию CISC в лице x86 таки победил всех как минимум на "большом" рынке именно за счет поддержки legacy и оттачивания той самой microarchitecture, пока другие суперскалярностью мерялись. А то и первый Arm2 таки не честный RISC, а тоже с микрокодом внутри, есличо.

187
Цитата
нативная поддержка вычислительных операции над 16-битными числами и 16-битный же стек ещё как решают. И очень просто -- процессору просто меньше кода приходится выполнять.

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

188
Ну тут вообще странно, хотя если учесть что зилог суть дополненный клон 8080, который первый более-менее функциональный CPU вообще то вполне похоже на правду. Но то что на такт больше все равно странно - чисто по схемологике дешифрация 3 бит адреса операнда(который тем более вне адресного пространства) против дешифрации 16 бит адреса и последующей дешифрации 8 бит с доступом к sram. Хммм чота падазрительно(ТМ).

Ну и да.  SMS - из деталей с ближайшего радиомагазина, а NES-фулл кастомЪ Железо. :lol: Вообще конечно забавно, что именно неску клонировали больше, ведь в SMS кроме допиленного тексасовского видеочипа все остальное реально можно было на радиорынке готовое купить.

Добавлено позже:
А и да, у SMS оператива и видеопамять драмовская (вернее XRAM который суть DRAM с набортным контроллером), а у NES SRAM

189
Вообще забавно, конечно, по идее должно быть наоборот, ведь моська безрегистровая и все время лазает в оперативу а зет с регистрами и за каждым операндом в оперативу ему лазить не нужно. Неужели zero page так решает.

190
Почему эмулю пофиг? Настройки изменяют режим работы экрана и эмуль соответственно реагирует (в заголовке окна показан режим интерлейс/развёртка)
Как раз на это эмулю не пофигу - progressive и interlace - де-факто подразумевают два совершенно разных режима на железе, часто и с разным размером framebuffer'а и принципом рендеринга в него же (см. SCANMSK,EXTBUF) и эмулятор вполне может в зависимости от показывать или не показывать багули.

191
Лучше бы уклон делали, конечно, на OGL, чем на DX12... Хотя по логике вещей так в будущем и будет, так что нелюбители Win10 (например, я) пока в пролёте  :neznayu:.

С OpenGL есть сложности в плане трудоемкости эмуляции GPU 3-го и последующих поколений (это в которых шейдеры появились) - он слишком высокоуровневый для этого дела (основные проблемы там с видеопамятью и со связью микро и макростейта (грубо говоря кода шейдеров и кода CPU), которые в API PS3 реализованы на более низком уровне, нежели в OpenGL). Последние версии, конечно в этом плане чуть получше (в частности Bindless Texture, SSBO), но у OpenGL традиционная беда с поддержкой в драйверах и багами в них же и в поддерживаемых видеокартах. DH в обсуждении на гитхабе вообще говорил, что как только появится спека Vulkan и поддержка в драйверах этого самого вулкана, будут уходить на него, а на GL вообще положат болт.

Добавлено позже:
по RSX доступной документации крайне мало

Вернее, её читай вообще нет, даже в SDK. Есть там RSX User's Manual, но он скорее чисто научно-популярный, нежели мануал, поскольку разработчику про его устройство знать не надо, он с libGCM и Nvidia CG работает. А вот сама игра после компиляции и сборки очень даже с низкоуровневым функционалом работает. Так что основная инфа там по большей части от команды разработчиков свободного драйвера видеокарт Nvidia для линукса.

192
nonamezerox, то есть потери во фрейме 716х412 мы будем иметь только по горизонтали в виде сокращения 716 до 549,33, я правильно понял?

По вертикали тоже - в PAL 576 отображаемых строк из 625, а в место них и вовсе 412 - все ради этой маразматической идеи сделать леттербокс наоборот и вывести через анаморф.  Нахрена это было делать если на пульте от телевизора есть кнопка управлением растягиванием картинки - не знаю. Капком те еще наркоманы.

Добавлено позже:
Раз уж тут такие спецы собрались, то меня такой вопрос все интересовал. Как известно при эмуляции Вий игр в некоторых играх частенько случаются фризы, вызванные вроде как кешированием шейдеров. В следствии чего при последующей игре на уже пройденных уровнях, задержек как правило нет, если конечно кэш не почистить. Так вот, какого это происходит? Почему PCSX2 обходится без этого? Да и вроде на том же долфине, кубовские игры так же подобной проблемы не имеют.

Ну вообще GPU у GC и PS2 как бы совсем разные. У GC видеочип уже к следующему поколению относится - там уже и недо-pixel shader pipeline (похож на register combiners в GeForce 2) и Hardware T&L есть и MSAA и мультитекстурирование и сжатые текстуры S3CT вместо палитр. У GS тупа много полигонов, быстрый альфаблендинги халявный overdraw за счет выделенной сверхбыстрой видеопамяти (и отсюда же проблемы с текстурами, так как её мало), а все остальное вынесено в CPU. А насчет куба - хз, у меня подфризы в MP1 случаются.

193

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

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



Добавлено позже:
И ещё, если я всё правильно понял из текста, то отбрасываются не только лишние крайние строки в виду округления, но и вообще 66% отрендеренных строк при предварительном даунскейлинге "412/3=~137.33"... не хочу сказать грубо, но х...ня какая-то получается  :?

У него в тексте просто слова горизонтальное и вертикальное перепутаны местами. Вертикальное - количество строк, горизонтальное - количество пикселов в строке (которых в аналоговом сигнале нет, так как сигнал в строке непрерывный, но на самом деле как бы имеет место быть, так как есть частотные ограничения у передающего тракта и помехи, которые фильтром нижних частот вырезаются, ограничивая таким образом количество деталей в строке).
 412/3 - это чтобы потом умножить на 4 и получить разрешение видимой части картинки по горизонтали.


194
притом что шейдоров там в помине пока нет

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


195
в РЕ для Вии это не натив без разтягиваний, это такой веселый костыль, где бекграунд рендерится по центру, а все 3Д в честном 16:9, а потом сверху бахаются черные полосы, дабы не было видно что 3Д есть и за границами бекграундов

И, с учетом того, что Wii  HD сигнал выводить не умеет, а SD, как всем известно, в 16x9 не может (может только анаморф, который суть картинка 16х9 сплюснутая по горизонатли в кадр 4х3), то на выходе получаем ситуацию "навернуть lowres говна способом, достойным пера маркиза де сада бесплатно без смс" :lol: :lol: :lol:

196
ну конечно можно попросить автора изменить номер версии, но думаю он не послушает :)
а как номер версии зависит от стабильности? :)

Да в целом никак, есть хренова туча способов, кнут вот в своем TeXе вовсе использует число пи и добавляет по одной цифре к версии. Просто в большинстве схем принято, что версия с еденицей означает как минимум полную реализацию запланированной функциональности, но в других это не обязательно.

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

Что касается конкретно PS2, то если без костылей - то да.

198
эмуль  :lol:, правильней писать запускатор

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

199
P.S. А открытие исходников по мне всегда правильный шаг, как минимум дающий надежду на развитие проекта в будущем.
Вот именно, что надежду, а не гарантию.

200
Во много раз? Оригинальные авторы с тобой не согласны. Помню, в 2007-2008, когда еще не было "костыльного" эмуля, мы на гораздо более слабых машинах играли в фуллспиде всякие финалки и кингдом хартсы.

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

Цитата
Да. Но они должны быть "аварийным" вариантом, должны юзаться там где по честному никак. Они не олжны быть напиханы везде где только можно, разве нет?

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

201
Да у всех эмуляторов есть свои хаки и костыли. Без них никак.

Ну речь шла о такой расово-неверной разновидности костылей как патчи оригинального ps2 кода, заметающие под ковер проблемы с функционалом эмулятора. У поставленного в пример официального эмулятора из PS3 с расовой неверностью абсолютно полный порядок - при установке игры из PSN к дистрибутиву помимо ISO-образа заботливо прилагается правильная для этой конкретной игры версия эмулятора с правильным же патчем, все как у треклятого неправильного pcsx2.

А причина тут в том, что Dreamcast и Gamecube не проектировались с применением тяжелых галюциногенных наркотиков в сжатые сроки с нуля под лозунгом "Перевыполним план по треугольникам в секунду к E3 1999 любой ценой! Выдать всем двойную дозу!", поэтому там можно было и с меньшим количеством костылей. Что, впрочем, не отменяет успешного стремления кода pcsx2 к неспоровождаемости и непортируемости на другие архитектуры (тут к успеху уже пришли) и как следствие закрытию тикетов на ту же первую ксеносагу c честным признанием в фундаментальном провале с функционалом и невозможностью поправления сейвов без переписывания мумулятора целиком.

202
Официальный эмулятор, можно подумать, не на хаках и костылях работает, ага.

http://www.ps3devwiki.com/ps3/Emulation#CONFIG_File

203
Ну, качество кода в целом не всегда есть абсолютная добродетель, вот к примеру перед чтением кода UE4 или тем более V8 вообще рекомендуется колюще-режущие предметы убирать со стола, дабы не возникло желание избавиться с их помощью от собственных глаз, однако сами продукты работают и весьма хорошо.

204
ZEROx, Да, больше всего этому эмулятору не хватает открытия исходников. После этого разработка не пойдёт, а понесётся. Но даже после этого уйдут годы, пока он будет удобоварим для хомячков.

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

205
P.S: В «наше время» да, это преподносилось действительно так.

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

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

Уж прости. Их мешают известно с чем. Потому и работают, в основном, за харчи.

Кто кого мешает? Кто за харчи работает? Херню какую-то несешь.


206
Да и вообще, - на хрена крупнейшим корпорациям понадобились какие-то там Петровичи из глубинки, или-же Боб из частного гаражного кооператива, в наше-то время.

В наше время как раз такие люди на вес золота (без шуток). Ты не представляешь насколько катастрофически (то есть в прямом смысле) ухудшилась ситуация с кадрами в целом по IT за последние 10 лет. Да и раньше таких людей с руками отрывали.

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

Это не эмуляция, а симуляция.

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

207
когда проект только начинался, это все шло с парой фпс и тонной графических багов на довольно таки не слабых ПеКа
и смысла париться для Сони абсолютно не было

Ну, epsxe они тоже не трогали, хотя тот вполне успешно работал  при еще живой PSX (Производство прекращено в 2005 году, до 2002 вполне неплохо так даже игры выходили). Да и трогать его было бы проще, тк closed-source. Тут именно проблема в юридической бесперспективности - исходники эмулятора ни на микросхему, ни на нетлист этой микросхемы ни даже на HDL исходники этой микросхемы не только близко не похожи, они вообще про мягкое и зеленое. И, поскольку разработка ведется не комммерческой компанией, которой можно остановить продажи, а частником-энтузиастом, а то и группой энтузиастов по всему миру, то бороться тупо бессмысленно.

208
Когда проект только начинался, пс2 продавалась во всю, но Сосни ни разу не пытались его убить
Тут, полагаю, дело в статусе разработчика, конектикс и блим разрабатывались лицами юридическими как коммерческий продукт, и то по-сути сони именно выиграть суд не смогли, смогли только поднасрать продажам(продукт на время судебного разбирательства был арестован и не имел права продаваться) и разорить конторы.  Но то контора, а то физлицо занимающееся написанием эмулятора на энтузиазме. Поэтому начиная уже с epsxe ничего никому не было. И не будет, пушо в рамках англосаксонского права  прецедент присутствует, тк оба суда сони проиграли.

Единственное что они реально могут сделать - это сманить ключевых разработчиков себе в команду и там уже дальше ограничить их трудовым договором и NDA.

209
С ключами крайне пикантная ситуация в юридическом плане - не факт что вообще будут реализовывать, повторять судьбу geohot'a желающих мало.

210
nonamezerox, да как-то пошла эта вредная привычка из IRC канала, и уже привыкли подгрузку модулей прошивки называть LLE :blush: Вот и ляпнул по неосторожности :lol: Смотрю, сейчас в большинстве современных эмуляторов используется аналогичный подход - в Jpcsp/PPSSPP, и скорее всего в Xenia и Cemu. Был тестером Jpcsp во времена его активной разработки, и когда DH взялся за RPCS3, то предложил ему сделать подобную реализацию, чтобы избавиться от лишнего геморроя :) Да, SPE и asmjit делал Nekotekina, а llvm первоначально делал gopalsr83, дальше пробовал SPURS разбирать и пропал без вести; vlj обновил код с llvm до 3.6.

Да в современных условиях,  когда в приставках уже полноценная ОС да еще и поверх гипервизора, да еще и разные ревизии железа отличаются кишками и только в OS API все более-менее стабильно, правильный подход, плюс, помня о истории с Сони, геохотом и взломом, с точки зрения закона в целом тоже. А вот с библиотеками кодогенерации, честно говоря, у вас бардакус вульгарис.

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