В DirectX приложениях не отображается геометрия, которая рисуется из буфера stream output посредством функции D3D11DeviceContext::DrawAuto() Примеры: -Renga (не отображаются различные линии) -Тестовая программа https://gitlab.eterfund.ru/wine/wine-etersoft-devel/tree/master/Renga/bug_16351/DirectX%2011%20Engine%20VS2017/x64/Release (не отображается обводка куба) Если правильно понял, то вот эта функция в wine https://gitlab.eterfund.ru/wine/wine-rebased/blob/rebased/dlls/d3d11/device.c#L1225 Очевидно не реализована Пробовал в тестовой программе менять вызов DrawAuto() на Draw() - тогда всё работает в wine (и c opengl, и с vulkan, и с dxvk). В связи с этим пробовал уже в wine внутри d3d11_device_context_DrawAuto вызывать d3d11_device_context_Draw(). В тестовой программе заработало только с opengl, в renga стали отображаться линии, но расположены неправильно. Также интересно взглянуть на DXVK. Там реализована DrawAuto() https://github.com/doitsujin/dxvk/blob/master/src/d3d11/d3d11_context.cpp#L939 Но с dxvk в renga и в тестовой программе всё равно не работает отрисовка. Возможно стоит в wine сделать что-то аналогочное dxvk? Через wined3d_device_context_draw_indirect например? Еще интересный факт. Заявлено что в dxvk 1.1.1 пофиксили DrawAuto() https://github.com/doitsujin/dxvk/releases?page=5#:~:text=incorrect%20behaviour%20of-,DrawAuto,-with%20a%20non Я пробовал ставить предыдущую (без фикса) версию 1.0.3. И на ней тестовая программа работала правильно (обводка отображается). Ренгу протестировать не получилось, т.к. не хочет создаваться проект.
(Ответ Олег Никулин на комментарий #0) > Я пробовал ставить предыдущую (без фикса) версию 1.0.3. И на ней тестовая > программа работала правильно (обводка отображается). Ренгу протестировать не > получилось, т.к. не хочет создаваться проект. В DXVK DrawAuto() перестает работать в версии 1.4.4. На версии 1.4.3 в renga нормально работает создание проекта и все линии корректно отображаются. P.S. renga с dxvk работает только на версии wine с патчем child window rendering https://gitlab.eterfund.ru/owl2/wine-rebased/tree/child-window-patch без патча падает при инициализации графики, это отдельная проблема
(In reply to Олег Никулин from comment #0) > В DirectX приложениях не отображается геометрия, которая рисуется из буфера > stream output посредством функции D3D11DeviceContext::DrawAuto() > > Примеры: > -Renga (не отображаются различные линии) > -Тестовая программа > https://gitlab.eterfund.ru/wine/wine-etersoft-devel/tree/master/Renga/ > bug_16351/DirectX%2011%20Engine%20VS2017/x64/Release (не отображается > обводка куба) > > Если правильно понял, то вот эта функция в wine > https://gitlab.eterfund.ru/wine/wine-rebased/blob/rebased/dlls/d3d11/device. > c#L1225 > Очевидно не реализована > > Пробовал в тестовой программе менять вызов DrawAuto() на Draw() - тогда всё > работает в wine (и c opengl, и с vulkan, и с dxvk). В связи с этим пробовал > уже в wine внутри d3d11_device_context_DrawAuto вызывать > d3d11_device_context_Draw(). В тестовой программе заработало только с > opengl, в renga стали отображаться линии, но расположены неправильно. Это очень странное поведение. Не пробовали выяснить, с чем связно то, что при вызове из тестовой программы ::Draw() работает, а при вызове ::Draw() из ::DrawAuto() - нет? > Также интересно взглянуть на DXVK. Там реализована DrawAuto() > https://github.com/doitsujin/dxvk/blob/master/src/d3d11/d3d11_context. > cpp#L939 > Но с dxvk в renga и в тестовой программе всё равно не работает отрисовка. > Возможно стоит в wine сделать что-то аналогочное dxvk? Через > wined3d_device_context_draw_indirect например? > > Еще интересный факт. Заявлено что в dxvk 1.1.1 пофиксили DrawAuto() > https://github.com/doitsujin/dxvk/releases?page=5#:~: > text=incorrect%20behaviour%20of-,DrawAuto,-with%20a%20non > Я пробовал ставить предыдущую (без фикса) версию 1.0.3. И на ней тестовая > программа работала правильно (обводка отображается). Ренгу протестировать не > получилось, т.к. не хочет создаваться проект. Проблемы, вызванные использованием DXVK, никакого отношения к Wine не имеют и должны быть сообщены разработчикам DXVK.
(Ответ Dmitry Timoshkov на комментарий #2) > Это очень странное поведение. Не пробовали выяснить, с чем связно то, что > при вызове из тестовой программы ::Draw() работает, а при вызове ::Draw() > из ::DrawAuto() - нет? Не знаю. Могу только предположить про аргументы функций: https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11devicecontext-draw В Draw() надо передавать количество вершин сколько нужно отрисовать, и индекс вершины с которой начинать. Мне в тестовой программе точное количество неизвестно, поэтому указываю с запасом 128 (получается больше чем фактическое число вершин в буфере), индекс 0. А в DrawAuto() ничего передавать не надо, по идее она должна сама определять количество вершин. Когда я в wine вывывал Draw внутри DrawAuto, я также передавал количество 128 и индекс 0. Может как-то с этим связано? Хотя всё равно странно, т.к. в итоге у меня вызовы к Draw() одинаковые должны получаться.
(In reply to Олег Никулин from comment #3) > (Ответ Dmitry Timoshkov на комментарий #2) > > Это очень странное поведение. Не пробовали выяснить, с чем связно то, что > > при вызове из тестовой программы ::Draw() работает, а при вызове ::Draw() > > из ::DrawAuto() - нет? > Не знаю. Могу только предположить про аргументы функций: > https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11- > id3d11devicecontext-draw > В Draw() надо передавать количество вершин сколько нужно отрисовать, и > индекс вершины с которой начинать. Мне в тестовой программе точное > количество неизвестно, поэтому указываю с запасом 128 (получается больше чем > фактическое число вершин в буфере), индекс 0. А в DrawAuto() ничего > передавать не надо, по идее она должна сама определять количество вершин. > Когда я в wine вывывал Draw внутри DrawAuto, я также передавал количество > 128 и индекс 0. > Может как-то с этим связано? Хотя всё равно странно, т.к. в итоге у меня > вызовы к Draw() одинаковые должны получаться. Получается, что ::DrawAuto() должен знать или уметь вычислять правильное количество вершин, ассоциированное с текущим контекстом. Видимо нужно понять, как это делать. Можно предположить, что на стороне wined3d это известно.
(Ответ Олег Никулин на комментарий #0) > Пробовал в тестовой программе менять вызов DrawAuto() на Draw() - тогда всё > работает в wine (и c opengl, и с vulkan, и с dxvk). В связи с этим пробовал > уже в wine внутри d3d11_device_context_DrawAuto вызывать > d3d11_device_context_Draw() По ошибке тестировал не на той версии wine. Сейчас заново проверил: вызов Draw() вместо DrawAuto() работает. Но нужно определять количество вершин для отрисовки. Я для теста сделал константу 128, но это не вариант, т.к. если в буфере больше вершин, то часть геометрии не будет отрисована, а если меньше, то может рисоваться "мусор", оставшийся в буфере с прошлых кадров.
Пытаюсь найти способ определить количество вершин в stream output, которые нужно отрисовать drawauto(). Насколько я понимаю, нужен быть некий счетчик, который увеличивается на 1 каждый раз когда в stream output помещается новая вершина, и сбрасывается после вызова drawAuto(). Беру stream output через context->state->stream_output[0]->buffer Почему-то buffer всегда NULL. Через wined3d_device_context_get_stream_output() тоже. Еще есть такое понятие как transform feedback https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_transform_feedback.html похоже на аналог stream output в вулкане. И в wine он тоже используется, но я пока плохо понимаю как и для чего. Думаю надо смотреть в его сторону.
В вулкане есть функция vkCmdDrawIndirectByteCountEXT, которая работает аналогично обычному DrawIndirect, но количество вершин предполагается брать из transform feedback. Причем делается "without CPU intervention", сразу на видеокарте, прямо как в DirectX-овском DrawAuto(). Кажется это ровно то что на нужно. Пытаюсь сделать чтобы vkCmdDrawIndirectByteCountEXT использовалась при вызове DrawAuto(). Многое скопировал по аналогии с вызовом vkCmdDrawIndirect. В качестве буфера передаю stream_output. При запуске программы, использующей drawAuto(), происходит ошибка Unhandled page fault на строке wined3d_device_context_reference_resource(context, &state->stream_output[0].buffer->resource);
(Ответ Олег Никулин на комментарий #7) > В качестве буфера передаю stream_output. > При запуске программы, использующей drawAuto(), происходит ошибка Unhandled > page fault на строке > wined3d_device_context_reference_resource(context, > &state->stream_output[0].buffer->resource); stream_output[0].buffer в этот момент уже NULL, и вообще здесь нужен не stream output, а буфер который устанавливался через IASetVertexBuffers. Это поправил https://gitlab.eterfund.ru/owl2/wine-rebased/commit/4b20a72f26e15ba8a3a323b70716337870d33700 В тестовой программе отрисовка через drawAuto заработала. Но работает ужасно медленно, на глаз 2-3 фпс примерно. Также проверил в Renga. Тоже медленно работает, к тому же не вся геометрия рисуется корректно: поверх черных линий накладываются желтые, иногда отображается мусор (линии, которых быть не должно). Так что пока результат не особо удачный
Повторно тестирую. Тестовая программа лежит в /var/ftp/tmp/owl2/bug16697 Должен отображаться куб с красной обводкой по контуру (так в windows 10). Release_draw - для отрисовки обводки используется функция Draw() Release_drawauto - для отрисовки обводки используется функция DrawAuto() Других отличий нет. Проверил на alt p10, на видеокартах nvidia gtx 1050ti с драйверами nvidia 550 и noveau, а также на встройке amd ryzen 5600g с драйвером amdgpu. Тестировал в версиях wine rebased-etersoft-8.8 и rebased-etersoft-8.9. В 9.0 тестировал только amdgpu, результат аналогичен 8.9 Результаты: Release_drawauto: Обводка не отображается независимо от версии wine и используемого драйвера(т.к. функция не реализована). Release_draw, Драйвер nvidia 550: rebased-etersoft-8.8: обводка отображается, но не чисто красным, а с вкраплениями цвета куба. rebased-etersoft-8.9: в приложении черный экран, в консоли ошибки err:d3d:wined3d_context_vk_submit_command_buffer Failed to submit command buffer 0000000001004060, vr VK_ERROR_DEVICE_LOST. Release_draw, Драйвер nouveau: rebased-etersoft-8.8: в приложении черный экран, через пару секунд после запуска само закрывается (ошибок в консоли нет). rebased-etersoft-8.9: то же самое. Release_draw, Драйвер amdgpu: rebased-etersoft-8.8: обводка корректно отображается. rebased-etersoft-8.9: вместо обводки отображается другая геометрия (торчит сверху куба). Как видно, результаты зависят от используемого драйвера и видеокарты. Также, что-то поменялось между wine 8.8 и 8.9, что негативно влияет на результат. Полностью корректное отображение только на версии 8.8 с драйвером amdgpu.
(Ответ Олег Никулин на комментарий #9) > Также, что-то поменялось между wine 8.8 и 8.9, что негативно влияет на > результат. > Полностью корректное отображение только на версии 8.8 с драйвером amdgpu. Через bisect нашел, что стало хуже в коммите e2c30c8d460301b1e151d4fc092faf8c3abda5cd "Update vkd3d to bb680e73de4ac22700ec89b1f466eea8da0a2120"
Проверил в winehq 9.20. DrawAuto() не работает. Draw() с драйвером amdgpu работает корректно (другие драйверы не тестировал). Также дополнил багу на winehq https://bugs.winehq.org/show_bug.cgi?id=55458
Нашел в wine-staging старый патч, который реализует DrawAuto для deferred context: https://gitlab.winehq.org/wine/wine-staging/-/blob/d13e9fa487997b8eb22874a5fb1aab90aa7cd09f/patches/d3d11-Deferred_Context/0027-d3d11-Implement-DrawAuto-for-deferred-contexts.patch В актуальном на данный момент wine-staging этого патча уже нет, и к актуальному wine (9.0) он не применим.
(In reply to Олег Никулин from comment #12) > Нашел в wine-staging старый патч, который реализует DrawAuto для deferred > context: > https://gitlab.winehq.org/wine/wine-staging/-/blob/ > d13e9fa487997b8eb22874a5fb1aab90aa7cd09f/patches/d3d11-Deferred_Context/0027- > d3d11-Implement-DrawAuto-for-deferred-contexts.patch > В актуальном на данный момент wine-staging этого патча уже нет, и к > актуальному wine (9.0) он не применим. Этот патч сложно назвать реализацией, он ничего не делает.
Поизучал функцию vulkan vkCmdDrawIndirectByteCountEXT (своего рода аналог DrawAuto в vulkan) и как её надо использовать. Вкратце: 1. Указать буфер transform feedback: vkCmdBindTransformFeedbackBuffersEXT 2. Включить transform feedback: vkCmdBeginTransformFeedbackEXT 3. Отрисовать всё что нужно при помощи обычных команд, например, vkCmdDraw Результат будет записан в буфер transform feedback, указанный ранее 4. Остановить transform feedback: vkCmdEndTransformFeedbackEXT 5. Отрисовать содержимое transform feedback буфера: vkCmdDrawIndirectByteCountEXT Хороший пример: https://paminerva.github.io/docs/LearnVulkan/02.D-Transform-Feedback Кажется в wine уже есть почти всё нужное (шаги 1, 2, 3, 4). Снова попробовал сделать DrawAuto в wine через функцию vkCmdDrawIndirectByteCountEXT. Небольшой прогресс есть. Патч приложу к баге. Проверял только на видеокарте amd (amdgpu). В wine 9.0 в тестовой программе появляется геометрия, но отображается некорректно (также, как если в тестовой программе заменить вызов DrawAuto на Draw. Если те же изменения применить к wine 8.9, то DrawAuto корректно работает в тестовой программе, и проблем с производительностью не наблюдается. При вызове vkCmdBindTransformFeedbackBuffersEXT нужно указывать stride (размер в байтах одной вершины). Сейчас у меня фиксированно прописано 24 байта (верно для тестовой программы). Нужно вместо этого определять размер stride. И нужно будет протестировать с другими драйверами и в других программах (Renga).
Created attachment 6763 [details] Попытка реализации DrawAuto через vkCmdDrawIndexedIndirect
(In reply to Олег Никулин from comment #14) > Поизучал функцию vulkan vkCmdDrawIndirectByteCountEXT (своего рода аналог > DrawAuto в vulkan) и как её надо использовать. > Вкратце: > 1. Указать буфер transform feedback: vkCmdBindTransformFeedbackBuffersEXT > 2. Включить transform feedback: vkCmdBeginTransformFeedbackEXT > 3. Отрисовать всё что нужно при помощи обычных команд, например, vkCmdDraw > Результат будет записан в буфер transform feedback, указанный ранее > 4. Остановить transform feedback: vkCmdEndTransformFeedbackEXT > 5. Отрисовать содержимое transform feedback буфера: > vkCmdDrawIndirectByteCountEXT > > Хороший пример: > https://paminerva.github.io/docs/LearnVulkan/02.D-Transform-Feedback > > Кажется в wine уже есть почти всё нужное (шаги 1, 2, 3, 4). MSDN описание ID3D11DeviceContext::DrawAuto(): https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11devicecontext-drawauto В Wine методы классов d3d11 - это обертки вокруг вызовов dlls/wined3d, соответственно ::DrawAuto() нужно реализовать не в терминах Vulkan API, а как метод d3d11, вызывающий wined3d API. Внутри же wined3d есть несколько разных бэкендов и Vulkan всего лишь один из них.
А как это реализовано в dxvk?
(Ответ Dmitry Timoshkov на комментарий #17) > А как это реализовано в dxvk? В dxvk тоже сделано через vkCmdDrawIndirectByteCountEXT.
Created attachment 6765 [details] Патч DrawAuto 2
(Ответ Олег Никулин на комментарий #14) > При вызове vkCmdBindTransformFeedbackBuffersEXT нужно указывать stride > (размер в байтах одной вершины). Сейчас у меня фиксированно прописано 24 > байта (верно для тестовой программы). Нужно вместо этого определять размер > stride. Нашел как это сделать. См. "Патч DrawAuto 2". Размер stride передается приложением в функцию directx IASetVertexBuffers. Туда же передается offset, который тоже нужно указывать при вызове vkCmdDrawIndirectByteCountEXT. Нужно было только найти, откуда потом (при вызове vkCmdDrawIndirectByteCountEXT) брать эти параметры. Проверил отрисовку через DrawAuto в тестовой программе и в Renga. В wine-8.8 и wine-9.0 с обновленным патчем. Драйвер amdgpu. В 9.0 в обеих программах геометрия через DrawAuto отображается некорректно (рисуется не то и не там где надо). В 8.8 в обеих программах геометрия через DrawAuto отображается корректно. Нужно детально разобраться, почему в версиях после 8.8 перестает нормально работать. (Ответ Dmitry Timoshkov на комментарий #16) > В Wine методы классов d3d11 - это обертки вокруг вызовов dlls/wined3d, > соответственно ::DrawAuto() нужно реализовать не в терминах Vulkan API, > а как метод d3d11, вызывающий wined3d API. Внутри же wined3d есть несколько > разных бэкендов и Vulkan всего лишь один из них. У меня вроде так и сделано. Метод d3d11 вызывает wined3d API. Но Vulkan - единственный бэкэнд, при использовании которого будет работать DrawAuto. Возможно в OpenGL тоже получится сделать, т.к. там тоже есть transform feedback.
(Ответ Олег Никулин на комментарий #10) > (Ответ Олег Никулин на комментарий #9) > > Также, что-то поменялось между wine 8.8 и 8.9, что негативно влияет на > > результат. > > Полностью корректное отображение только на версии 8.8 с драйвером amdgpu. > Через bisect нашел, что стало хуже в коммите > e2c30c8d460301b1e151d4fc092faf8c3abda5cd > "Update vkd3d to bb680e73de4ac22700ec89b1f466eea8da0a2120" Этот коммит есть в ветке rebased-etersoft-8.9, но его нет в ветке rebased-etersoft. Заново сделал bisect в ветке rebased-etersoft. Тут проблемным оказался 3c186a5ed0d1932349b96b7897cae0851718a2b1 "vkd3d: Import upstream release 1.9." Причем до этого есть коммит "vkd3d: Import upstream release 1.7.", а import vkd3d 1.8 нет. То есть перешли с 1.7 сразу на 1.9. Полагаю перестало работать в vkd3d 1.8, т.к. "Update vkd3d to bb680e73de4ac22700ec89b1f466eea8da0a2120" относится к vkd3d 1.8.
Проверил тестовую программу Release_draw и Renga с драйверами nouveau, nvidia 550 и amdgpu. Видеокарты gtx 1050ti и встройка ryzen 5600g. renderer=vulkan. Делал две сборки wine. Первая - по состоянию на коммит 3c186a5ed0d1932349b96b7897cae0851718a2b1 "vkd3d: Import upstream release 1.9." Условно назову ее wine-vkd3d-1.9 Вторая - по состоянию на предыдущий коммит 3b5aef662f80e944555797b1616bc911a3518029. Условно назову ее wine-vkd3d-1.7 nouveau: wine-vkd3d-1.9: в Release_draw черный экран, через пару секунд после запуска сама закрывается (ошибок в консоли нет); Renga падает при построении стены wine-vkd3d-1.7: то же самое. Дополнительно проверил nouveau в wine-9.0: Release_draw работает, но обводка куба отображается некорректно; Renga работает. В какой версии wine nouveau начинает нормально работать еще не выяснил. nvidia 550: wine-vkd3d-1.9: Release_draw виснет; Renga виснет при построении стены. И там и там ошибка VK_ERROR_DEVICE_LOST. wine-vkd3d-1.7: Release_draw работает, обводка куба отображается с некорректным цветом; Renga работает. amdgpu: wine-vkd3d-1.9: Release_draw работает, обводка куба отображается некорректно; Renga работает. wine-vkd3d-1.7: Release_draw программа работает, обводка куба отображается полностью корректно; Renga работает. Также попробовал применить патч drawauto_wip2.patch к wine-vkd3d-1.7: nouveau: не проверить, т.к. ни тестовая программа, ни Renga нормально не работают. nvidia 550: в Release_drawauto обводка куба отображается с некорректным цветом; В Renga линии при построении стен отображаются некорретным цветом и будто накладываются друг на друга. amdgpu: в Release_drawauto обводка куба отображается полностью корректно; В Renga линии при построении стен отображаются полностью корректно. Итого: Начиная с коммита 3c186a5ed0d1932349b96b7897cae0851718a2b1 "vkd3d: Import upstream release 1.9." появились проблемы с зависанием при использовании драйвера nvidia 550, а также проблема с отображением обводки в тестовой программе. Но даже до этого коммита, полностью корректного отображения в тестовой программе и в Renga получилось добиться только при использовании драйвера amdgpu.
Проверил тестовую программу в префиксе с dxvk, драйвер nvidia 550. И до, и после коммита 3c186a5ed0d "vkd3d: Import upstream release 1.9." обводка куба отображается с некорректным цветом - также как без dxvk до коммита. То, что просто wine и wine + dxvk дают одинаковый неправильный результат, наводит на мысль, что это именно драйвер nvidia такой проблемный. Также, касательно ошибки VK_ERROR_DEVICE_LOST, можно найти упоминания, что старые версии драйвера nvidia более стабильны https://github.com/doitsujin/dxvk/issues/1791 https://forums.developer.nvidia.com/t/vk-error-device-lost-in-many-game-titles/164513/30 Хотя там не совсем наш случай. У нас ошибка VK_ERROR_DEVICE_LOST при вызове vkQueueSubmit
Created attachment 6770 [details] Патч DrawAuto 3
(Ответ Олег Никулин на комментарий #23) > Проверил тестовую программу в префиксе с dxvk, драйвер nvidia 550. > И до, и после коммита 3c186a5ed0d "vkd3d: Import upstream release 1.9." > обводка куба отображается с некорректным цветом - также как без dxvk до > коммита. > То, что просто wine и wine + dxvk дают одинаковый неправильный результат, > наводит на мысль, что это именно драйвер nvidia такой проблемный. Проверил Renga и тестовую программу в профексе с dxvk в wine-9.0.19-eter0.p10.1 (до реверта child window патча), драйвер nvidia 550. Как ни странно, в Renga функция DrawAuto() показала корректный результат, а в тестовой программе - нет. Получается, тестовая программа не совсем верно отражает проблему в Renga. Пытаюсь дальше починить DrawAuto в wine. На коммите 3b5aef66, без dxvk: Посмотрел ошибки vulkan validation layers при работе Renga (для этого нужно объявить переменную окружения VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation). Была ошибка VUID-vkCmdDrawIndirectByteCountEXT-counterBuffer-02290 - исправил путем добавления бита VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT при создании буфера. Затем появилась ошибка VUID-vkCmdBeginTransformFeedbackEXT-firstCounterBuffer-09630 - исправил, указав количество буферов = 1 при вызове функции vkCmdBeginTransformFeedbackEXT. Во время отрисовки в Renga теперь нет ошибок vulkan validation layers, однако с драйвером nvidia визуально ничего не поменялось, функция DrawAuto() всё равно дает некорректный результат.
