Войти
ПрограммированиеФорумГрафика

Vulkan API (вышел!) (580 стр)

Страницы: 1579 580 581 582 583 Следующая »
#8685
(Правка: 23:46) 23:42, 20 авг. 2021

IBets
precision highp float;
Игнорируется всеми компиляторами после 300 версии GLSL.

Сейчас, насколько я знаю, есть только double(dvec, dmat) - 64 битное число с плавающей точкой, и float(vec, mat) - 32 битное.

precision highp float идет по умолчанию, в glslang так это уж точно.

(тоесть разницы не будет добавлю я это или нет, для ГПУ которые поддерживают Вулкан)

Если ты имел в виду что "возможно" компилятор начнет считать используя 32 битные float вместо 64 битных - то по умолчанию флоаты должны быть 32 битные в GLSL и если компилятор считает их 64 битными - то ничего не измениться.


#8686
(Правка: 1:15) 1:14, 21 авг. 2021

IBets
> Я в glsl особо не шарю, но в доке вроде описано precision highp float по
> дефолту для вершинных шейдеров, а для фрагментного precision medium float.
вот доки по GLSL в Вулкане
https://www.khronos.org/registry/SPIR-V/specs/unified1/GLSL.std.450.html

> The operand x must be a scalar or vector whose component type is 16-bit or 32-bit floating-point

и тут сказано
https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html
> The RelaxedPrecision Decoration allows 32-bit integer and 32-bit floating-point operations to execute with a relaxed precision of somewhere between 16 and 32 bits.

и отмечены операции над которыми RelaxedPrecision не имеет эффекта

Возможно ты и прав в контексте что точность автоматически меняется на ГПУ между 32 и 16 битами.

Но декларация
precision highp float;
Не должна иметь никакого эффекта, я проверил результат тотже.
(я не помню адрес спецификации где сказано что начиная с GLSL 300 precision не имеет эффекта)

P.S. Я пол часа гуглил, а ты пост удалил)) ну лан))

#8687
(Правка: 1:32) 1:21, 21 авг. 2021

melvy
Не точность не должна меняться. FP16 надо явно юзать, и по ассемблерному коду было бы видно так как это явные операции, Vega потому что поддерживает FP16
Попробуй кстати на dxc чекнуть еще. И да почему у тебя iTime идет через интерполятор?

#8688
(Правка: 1:42) 1:33, 21 авг. 2021

IBets
> Не точность не должна меняться. FP16 надо явно юзать, и по ассемблерному коду
> было бы видно так как это явные операции, Vega потому что поддерживает FP16
> Попробуй кстати на dxc чекнуть еще. И да почему у тебя iTime идет через
> интерполятор?

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

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

> И да почему у тебя iTime идет через интерполятор?

в минимальном коде по ссылке на shader-playground iTime идет как
in float iTime;
возможно поэтому

в оригинальном коде в указанном шейдере
https://www.shadertoy.com/view/sllXW8
на Shadertoy iTime это uniform
в коде на Вулкане это push-constant
Код шейдера на вулкане вместе с приложением (иксешником) можешь скачать тут. Этаже ссылка на шадертое в комментарии. Там можешь смотреть и менять код шейдера. (он идентичен шадертою)

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

#8689
(Правка: 5:24) 2:56, 21 авг. 2021

melvy
Ну как бы код GCN любой уважающий себя погромист графики наверное должен понимать. Архитектуре то уже почти десяток лет да и дока нормальная
Можем сойтись на том что операции (ADD, MUL) с FP  ни дистрибутивны ни ассоциативны,
поэтому если оптимизатор одной корпорации раскроет скобки по дистибутивности или переставит скобки по ассоциативности решив что так быстрее, а другой нет то результаты будут разные(Это лишь гипотеза так что прошу не пинать)
Ну и вообще я бы записывал результаты операции в Store Buffer, читал бы его на CPU и сравнивал с референсом CPU-шным. Чтобы понять где идет не так

#8690
(Правка: 3:36) 3:24, 21 авг. 2021

IBets
> Ну и вообще я бы записывал результаты операции в Store Buffer, читал бы его на
> CPU и сравнивал с референсом CPU-шным
Для этого нет софта готового для Вулкана.

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

Большинство багрепортов которые "приняли" у меня идут с "как баг повторить на khronos vulkan samples" и пошаговый туториал редактирования построчно... очень интересно такое писать.
Но в некоторых случаях оказывается что это баг "khronos vulkan samples" ( в 2021 да) и никто фиксить не будет, ни драйвер ни "samples" когда баг есть в 100% других Вулкан приложениях... кулстори


Для ОпенГЛ есть только shadertrap от гугла https://github.com/google/shadertrap
И результат(от записи значений в буфер и перенос памяти буфера в RAM) там идентичен тому что на экране на шадертое (в ОпенГЛ).

IBets
> Ну как бы код GCN любой уважающий себя погромист графики наверное должен
> понимать.

<толпы уважающих себя программистов, безработных>

IBets
> Архитектуре то уже почти десяток лет да и дока нормальная
> Можем сойтись на том что операции (ADD, MUL) с FP  ни дистрибутивны ни
> ассоциативны,
в 2020 несколько десятков багрепортов от меня, по критическим багам в Вулкане, которые только месяц назад пофиксилии то еще не все.
и в 2021 Вальв фиксит свой ACO после моих багрепортов...
<нужно больше бесплатных бетатестеров>

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

#8691
(Правка: 3:42) 3:32, 21 авг. 2021

melvy
Ну здесь можно разными способами пойти. Самый простой это взять Unity на нем налобать(10 строк код C# + шейдер),
DiligentEngine (50-70 строк C++ + шейдер), сырой Vulkan + VMA (150-200).
Тебе просто нужен один Dispath(1, 1, 1) и записать первой WaveLine значение в буффер
Не знаю баги по пукану обычно в слоях валидации, а так чтобы в драйвере был баг при валидных данных надо постараться
Я встретил лишь один баг при использовании VkPipelineCreationFeedbackCreateInfoEXT, на AMD и Intel некорректные данные возвращались

#8692
(Правка: 3:44) 3:43, 21 авг. 2021

IBets
> взять Unity
уже смешно (да(да))
(ты сам хоть запускал юнити на вулкане больше чем на одной видеокарте?)

> DiligentEngine

не работает ни на одной видеокарте кроме Nvidia 10XX и старше (на АМД тоже не работает)
я багрепортил в Нвидию и Кронос и DiligentEngine, везде wontfix и показывают друг на друга (там утечки памяти и неосвобождаемая память в ГПУ появляется, самый сломанный движок на вулкане что я видел)

> сырой Vulkan + VMA (150-200).

выше написал никто не будет доверять этому коду

> Не знаю баги по пукану обычно в слоях валидации, а так чтобы драйвер лег надо постараться

У меня Вулкан падает от Vulkan 1.0 кода абсолютно валидного с Khronos Samples, на всех видеокартах. Еще ни 1 драйвер(разных ГПУ) что я пробовал не смог в Vulkan 1.2 всегда чтото сломано на уровне драйвера.

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

#8693
3:46, 21 авг. 2021

IBets
> Я встретил лишь один баг при использовании

https://forums.developer.nvidia.com/c/visual-and-game-development/vulkan/205
https://community.amd.com/t5/opengl-vulkan/bd-p/opengl-and-vulkan-discussions
https://gitlab.freedesktop.org/mesa/mesa/-/issues
https://github.com/doitsujin/dxvk/issues

тысячи их

#8694
(Правка: 4:27) 3:49, 21 авг. 2021

melvy
Лол у меня все работает. На R7 265 все даже работает, а это пещерная видеокарта. Да и с таким примитивным одним шейдером, нечему ломаться. Баги есть везде, но это редко блочит в использовании продукта.
Если на автомобиле поврежден ремень безопасности, то это не помешает водить автомобиль, да и с вероятностью 99.999% об этом и не узнаешь пока не вылетишь через лобовое

#8695
3:58, 21 авг. 2021

IBets
> На R7 265 все работает
не представляю "что там может работать"

на AMD даже под Линуксом вулкан делает "thread_stuck_in_device_driver" и зависание системы от запуска двух "vulkan triangle" от "khronos samples"... это шокконтент, особенно на старых картах R7 где вулкан в вечной бете

> но это не мешает использовать продукт

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

... кароче это флуд вникуда уже...

Изначально я зашел только про float-ы на ГПУ поговорить, кто не видел смотрите на прошлой странице ссылки и скриншоты.

#8696
(Правка: 4:11) 4:08, 21 авг. 2021

melvy
Потому что код не валидный пишешь вот оно и фризит. Бесконечный луп или что то подобное. Обычно нужно дождаться TDR.
Doom как то же работает на вулкане, проблема лишь в руках, а не в API. Сейчас бум какой то по пограмированию всего, НЕ найти работу очень сложно

#8697
(Правка: 4:17) 4:12, 21 авг. 2021

IBets
> Потому что код не валидный пишешь вот оно и фризит
>> сырой Vulkan + VMA (150-200).
> выше написал никто не будет доверять этому коду

xDDD
melvy
> Самое худшее в багрепортах на Вулкан это то что первое что скажут - ваш код
> кривой, и ты никак не докажешь что код валидный (факт того что слои валидации
> не ругаются ничего не значит).
>
> Большинство багрепортов которые "приняли" у меня идут с "как баг повторить на
> khronos vulkan samples" и пошаговый туториал редактирования построчно... очень
> интересно такое писать.

xD

IBets
> Doom как то же работает на вулкане
https://github.com/doitsujin/dxvk/issues

> НЕ найти работу очень сложно
ок

#8698
(Правка: 4:29) 4:19, 21 авг. 2021

melvy
> https://github.com/doitsujin/dxvk/issues
А причем тут dxvk? Написать враппер DX9, DX11, DX12 поверх вулкана не тривиальная задача. С DX12 вообще хз что делают, учитывая что вулкановская модель биндинга ресурсов лишь подмножество от модели биндинга DX12
Или там приколы с депрекэйтед Stream-Output Stage(но это побороли в 2018)
PS: Посмотрел там нет dx12, чет я спутал с vkd3d

#8699
(Правка: 4:36) 4:27, 21 авг. 2021

IBets
> А причем тут dxvk?
> не тривиальная задача
любая не тривиальная задача выходящая за пределы Хелло-Ворд на вулкане находит баги
Если у вас Дум и к выходу которого выпускают новые драйвера с фиксом всех багов, чтоб ваш Дум работал.
То в случае "обычных тестов" когда ты делаешь нестандартную TAA с репроекцией и пытаешься запустить - а оно работает "по разному" на разных ГПУ из за багов... и переделываешь чтоб "оно работало" обходя десятки разных багов, таже история с нестандартным voxel-GI который не может читать память ГПУ из за нестандартной логики когда все валидно (не мой код я только тестировал)

тотже DiligentEngine очень не стандартный движок, и он тоже не работает на большинстве видеокарт с вулканом

(про Юнити или УЕ4 - там тыщи ошибок валидации уже на сцене с двумя камерами, пока крупная корпорация не проплатит фикс этого всего для своего "реального проекта" а не игрушек от бомже-разработчиков, никто это фиксить не будет)
(DX12 не лучше и драйвера там еще хуже чем в вулкане, я говорил лишь про проблемы вулкана)

П.С. я зря конечно этот флуд устроил, извиняюсь.

Страницы: 1579 580 581 582 583 Следующая »
ПрограммированиеФорумГрафика