Почему VK_PRESENT_MODE_FIFO_KHR вызывает катастрофические проблемы с производительностью c в Ubuntu MATE? - PullRequest
0 голосов
/ 01 мая 2020

Я реализую простой рендерер Vulkan в соответствии с популярным руководством Vulkan (https://vulkan-tutorial.com/Introduction) и столкнулся с интересной проблемой, связанной с режимом презентации и производительностью среды рабочего стола.

Я написал демо-версию треугольника на Windows, и она показала хорошие результаты; однако я перенес его в свою установку Ubuntu (работает с MATE 1.20.1) и обнаружил любопытную проблему с производительностью всей среды рабочего стола во время его работы; некоторые режимы представления swapchain, кажется, вызывают абсолютную хаос c в среде рабочего стола.

При настройке Vulkan swapchain с presentMode, установленной в VK_PRESENT_MODE_FIFO_KHR и последующей работе приложения, вся среда рабочего стола размалывается до остановка всякий раз, когда любое окно перетаскивается. Когда перетаскивается буквально любое окно на всем рабочем столе, вся среда рабочего стола замедляется до ползучести, создавая скорость примерно 4-5 кадров в секунду. Однако когда я заменяю presentMode на VK_PRESENT_MODE_IMMEDIATE_KHR, среда рабочего стола не подвержена этой проблеме и не испытывает проблем с производительностью при перетаскивании windows.

Когда я исследовал это, прежде чем спросить здесь, я увидел, что несколько человек обнаружили, что они испытывают такое поведение, когда их приложение доставляет фреймы как можно быстрее (не vsyn c 'd), и что правильная синхронизация с vsyn c устраняет это заикание. Однако в моем случае все наоборот; когда я использую VK_PRESENT_MODE_IMMEDIATE_KHR, т. е. не ожидая vsyn c, производительность перетаскивания плавная, а когда я синхронизируюсь с vsyn c с VK_PRESENT_MODE_FIFO_KHR, он заикается.

VK_PRESENT_MODE_FIFO_RELAXED_KHR производит идентичные (catastrophi c) результаты в стандартном режиме FIFO.

Я пытался использовать Compton GPU compoitor вместо Compiz; эффект все еще был (независимо от того, какое окно перетаскивалось, рабочий стол все еще становился очень медленным), но был немного менее выраженным, чем при использовании Compiz.

Я полностью реализовал рамку / изображение на основе VkSemaphore Схема синхронизации / swapchain, как определено в руководстве, и я проверил, что при использовании VK_PRESENT_MODE_FIFO_KHR приложение отображает только кадры с целевыми 60 кадрами в секунду. (При использовании IMMEDIATE он работает на скорости 7 700 кадров в секунду.)

Самое интересное, , когда я измерял количество кадров (используя glfwGetTime()), в периоды, когда окно перетаскивалось время кадра очень короткое . Скриншот показывает это; Вы можете увидеть очень короткое / ненормальное время кадра при перетаскивании окна, а затем «типичное» время кадра (заблокированное до 60 кадров в секунду), пока окно все еще.

screenshot

Кроме того, только при использовании VK_PRESENT_MODE_FIFO_KHR, в то время как наблюдается это экстремальное снижение производительности, Xorg привязывает ЦП к 100% на одном ядре, в то время как запущенное приложение Vulkan использует Значительное количество процессорного времени (73%), как показано на скриншоте ниже. Этот всплеск наблюдается только при перетаскивании windows в среде рабочего стола и совсем не наблюдается, если используется VK_PRESENT_MODE_IMMEDIATE_KHR.

enter image description here

I Любопытно, сталкивался ли кто-нибудь еще с этим и есть ли известное исправление для этого поведения окна.

Информация о системе: Ubuntu 18.04, Mate 1.20.1 с Compiz, проприетарными драйверами Nvidia.

Редактировать: Эта ветка Reddit , похоже, имеет аналогичное описание проблемы; VK_PRESENT_MODE_FIFO_KHR, вызывающий экстремальные проблемы с производительностью рабочего стола при использовании проприетарных драйверов Nvidia.

Edit 2: Эта ошибка может быть легко воспроизведена с помощью vkcube из vulkan-tools. Сравните производительность рабочего стола vkcube с использованием --present-mode 0 против --present-mode 2.

...