Вы правы в том, что это не бинарная совместимость в строгом смысле слова - я использовал этот термин как упрощение. ROCm/HIP обеспечивает совместимость на уровне исходного кода через автоматическую конвертацию, а не прямое выполнение CUDA бинарников. При этом суть остаётся той же - разработчику в большинстве случаев не требуется вручную переписывать код, так как HIP автоматически handled большинство различий в архитектурах.
Что касается технических различий (LOP3, размеры shared memory и т.д.) - они действительно есть, и именно поэтому используется промежуточный слой трансляции, а не прямое исполнение бинарного кода. HIP/ROCm абстрагирует эти различия, позволяя достичь практически той же цели - запуска CUDA кода на AMD GPU с минимальными модификациями.
Всё отлично в моём случае. Но опять же из-за того что невозможно натурально сравнить работу напрямую и через ROCm, то нельзя точно говорить о каких-либо цифрах, неизвестен процент потерь. Я догадываюсь что производительность около 80-95%, в той же stable diffusion моя RX 6600 выдает результаты скорости, относительно сопоставимые с RTX 3060.
даже на 6500 xt рабоатет если говорить за работу на линукс. А вот на windows, по всей видимости, решили не тратиться на работу с младшими архитектурами, и реализовали поддержку только самых новых решений и c барского плеча дали поддержку на 6800 и выше.
для правильного сравнения именно качества кодеков, вам необходимо было сравнивать их с данными параметрами: h264: -vcodec libx264 -preset veryslow -b:v 2000k (можете указать своё значение) h265: -vcodec libx265 -preset veryslow -b:v 2000k Только в таких равных условиях, мы можем говорить о качественной разнице самих кодеков. У кого будет меньше артефактов и искажений - тот и будет качественнее.
H264 — воспроизводится без проблем практически везде, но имеет оскорбительно плохую эффективность в сжатии видео в сравнении с другими актуальными кодеками. AV1 — открытый кодек, который сжимает видео более эффективно, чем HEVC, но требует значительно больше ресурсов как для кодирования, так и для декодирования, что, несмотря на его свободу от лицензий, делает его непригодным для использования за пределами таких онлайн-кинотеатров, как Netflix или Amazon Prime, которыми как раз и поддерживается его развитие.
Исходя из названия статьи, ну чисто логически же можно было понять что основной упор идет на hevc и я не буду рассказывать о чем-либо кроме него. Так и вот в цитате и самой статье я ни один раз упоминал что hevc это не центр вселенной и мироздания. Что для ваших "домашних кейсов" есть разные кодеки тоже упомянуто в цитате.
Серьёзно, ваши сообщения уже больше подходят на спам. Вы уже ни один раз игнорировали доводы из статьи, хотя вроде её и читали...
Имелось ввиду что h265 самый продвинутый среди представленных ранее в статье вариантов. И не в плане качества кодирования, а количества параметров кодирования и их влияния на картинку, то есть он более гибкий чем остальные варианты.
Эта часть не требует уточнения в данной статье. Даже если усложнять этот абзац, то придем к одним и тем же выводам, так что я сразу сжал данную информацию в таком выводе.
Можно считать их мертвыми на данный момент. Они устарели. Конечно никто никуда не пропадал, но ими вне специфичных задач, нету смысла пользоваться. Есть ещё всякие prores от apple, но у меня не про это статья.
А что касается запуска видео, то ну просто установите VLC и бед знать не будете.
Эм, это blu-ray исходник в 1080p, и я не совсем понимаю зачем вы так зацикливаетесь на определенном материале, какое это вообще имеет отношение к вашему первоначальному циттированию? И VHS шумы как правило безумно разнятся по своей убитости от одной кассеты к другой, так что не думаю что вообще целесообразно пытаться иметь с этим дело.
В этом сообщении как раз рассказывается про ZLUDA касательно запуска sd на AMD вк под windows
Вы правы в том, что это не бинарная совместимость в строгом смысле слова - я использовал этот термин как упрощение. ROCm/HIP обеспечивает совместимость на уровне исходного кода через автоматическую конвертацию, а не прямое выполнение CUDA бинарников. При этом суть остаётся той же - разработчику в большинстве случаев не требуется вручную переписывать код, так как HIP автоматически handled большинство различий в архитектурах.
Что касается технических различий (LOP3, размеры shared memory и т.д.) - они действительно есть, и именно поэтому используется промежуточный слой трансляции, а не прямое исполнение бинарного кода. HIP/ROCm абстрагирует эти различия, позволяя достичь практически той же цели - запуска CUDA кода на AMD GPU с минимальными модификациями.
Хотелось бы больше конкретики.
Спасибо! По всей видимости, я действительно зря не решился начать изучать ZLUDA.
Всё отлично в моём случае. Но опять же из-за того что невозможно натурально сравнить работу напрямую и через ROCm, то нельзя точно говорить о каких-либо цифрах, неизвестен процент потерь. Я догадываюсь что производительность около 80-95%, в той же stable diffusion моя RX 6600 выдает результаты скорости, относительно сопоставимые с RTX 3060.
даже на 6500 xt рабоатет если говорить за работу на линукс. А вот на windows, по всей видимости, решили не тратиться на работу с младшими архитектурами, и реализовали поддержку только самых новых решений и c барского плеча дали поддержку на 6800 и выше.
Как думаете, почему AMD реализовала портирование ROCm на Windows посредствам wsl а не прямого портирования?
Да, хорошая идея. Сделал.
для правильного сравнения именно качества кодеков, вам необходимо было сравнивать их с данными параметрами:
h264: -vcodec libx264 -preset veryslow -b:v 2000k (можете указать своё значение)
h265: -vcodec libx265 -preset veryslow -b:v 2000k
Только в таких равных условиях, мы можем говорить о качественной разнице самих кодеков. У кого будет меньше артефактов и искажений - тот и будет качественнее.
Вы название статьи читали?
А также данный абзац?
Исходя из названия статьи, ну чисто логически же можно было понять что основной упор идет на hevc и я не буду рассказывать о чем-либо кроме него. Так и вот в цитате и самой статье я ни один раз упоминал что hevc это не центр вселенной и мироздания. Что для ваших "домашних кейсов" есть разные кодеки тоже упомянуто в цитате.
Серьёзно, ваши сообщения уже больше подходят на спам. Вы уже ни один раз игнорировали доводы из статьи, хотя вроде её и читали...
Даже не углубляясь в вопрос, я не рассматриваю в статье какой-либо live streaming с ffmpeg.
Извините, но я не понимаю что вы от меня хотите. Я не вижу в целом смысла в поднятии данного вопроса в данном случае.
Имелось ввиду что h265 самый продвинутый среди представленных ранее в статье вариантов. И не в плане качества кодирования, а количества параметров кодирования и их влияния на картинку, то есть он более гибкий чем остальные варианты.
Эта часть не требует уточнения в данной статье. Даже если усложнять этот абзац, то придем к одним и тем же выводам, так что я сразу сжал данную информацию в таком выводе.
Да.
Можно считать их мертвыми на данный момент. Они устарели. Конечно никто никуда не пропадал, но ими вне специфичных задач, нету смысла пользоваться. Есть ещё всякие prores от apple, но у меня не про это статья.
А что касается запуска видео, то ну просто установите VLC и бед знать не будете.
ну да, честно говоря, формат вышел не лучший, хотя я писал на пк, и выглядело нормально.
Такое не чинится никак. Тут и обычная студия мультипликации в обморок упасть может, а вы о каких-то плагинах и апскейлерах говорите)
Эм, это blu-ray исходник в 1080p, и я не совсем понимаю зачем вы так зацикливаетесь на определенном материале, какое это вообще имеет отношение к вашему первоначальному циттированию? И VHS шумы как правило безумно разнятся по своей убитости от одной кассеты к другой, так что не думаю что вообще целесообразно пытаться иметь с этим дело.
Так вы говорите о каком-то филтьре из 2000-х, а я о довольно современном алгоритме Neat Video v5 из 2019 года.
После прогонки через wavelet color fix, так и вообще загляденье