Поделиться через


Обновления для IddCx версии 1.5, 1.6 и более поздних версий

Следующие обновления в IddCx версии 1.5 и 1.6 применяются как к консоли, так и к драйверам удаленного косвенного отображения (идентификаторы).

Обновленная версия IddCxGetVersion

Версия IddCx, возвращенная IddCxGetVersion , была обновлена до 0x1500 для версии 1.5 и 0x1600 для версии 1.6. Полный список сведений о версиях, связанных с IddCx, см . в версиях IddCx.

Сведения WPP в открытых символах IddCx

Начиная с IddCx версии 1.5 общедоступные файлы символов IddCx содержат все сведения обработчика трассировки программного обеспечения Windows (WPP). Это изменение означает, что команда отладчика !wmitrace.logdump декодирует и отображает сообщение WPP в отладчике ядра.

Возможность доступа к буферам, выделенным в системной памяти

В некоторых сценариях буферы цепочки буферов находятся в системной памяти; Например, если WARP (Платформа расширенной растеризации Windows, системный отрисовщик программного обеспечения) является используемым адаптером отрисовки. IddCx 1.5 добавляет следующие обратные вызовы ОС, которые позволяют драйверу получать доступ к буферам в системной памяти, что позволяет избежать копирования подресурсов:

  • IddCxSwapChainSystemMemory позволяет идентификатору идентификатора проверить, являются ли буферы для цепочки буферов резидентными в системной памяти. Результат этого обратного вызова остается постоянным в течение всего времени существования цепочки переключения. Драйвер должен проверить значение этого обратного вызова в своемобратном вызове EvtIddCxMonitorAssignSwapChain и настроить состояние для освобождения и получения буферов.

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

    На этапе назначения новой цепочки буферов драйвер должен решить, какой вариант IddCxSwapChainReleaseAndAcquireBuffer IddCxSwapChainReleaseAndAcquireSystemBuffer/ будет вызывать конкретную цепочку буферов и продолжать использовать этот вариант для остальной части времени существования этой цепочки буферов. Чтобы решить, драйвер должен учитывать свои конкретные требования и результат вызова IddCxSwapChainSystemMemory. Драйвер вызывает ошибку операционной системы при проверке процесса UMDF, если он:

    • Вызывает другой вариант IddCxSwapChainReleaseAndAcquireSystemBuffer/IddCxSwapChainReleaseAndAcquireBuffer.
    • Вызывает IddCxSwapChainReleaseAndAcquireSystemBuffer , когда IddCxSwapChainSystemMemory возвращает значение false.

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

Возможность доступа к буферам в физической непрерывной памяти

Примечание.

IddCxSwapChainGetPhysicallyContiguousAddress не поддерживается в любой системе Windows 10 и, скорее всего, будет устарел в будущем.

Начиная с IddCx 1.6, добавлена функция обратного вызова ОС IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS и iddCxSwapChainGetPhysicallyContiguousAddress OS, чтобы буферы могли быть доступны в физической непрерывной памяти.

Драйверы отображения могут запрашивать, чтобы основные поверхности были выделены в физической непрерывной системной памяти, задав флаг IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS в IDDCX_ADAPTER_CAPS. Эта возможность позволяет драйверу напрямую сканировать поверхность без промежуточной копии.

Запрос драйвера во время инициализации не гарантируется успешно. Если запрос не выполнен, вызов IddCxAdapterInitAsync не завершится ошибкой. Вместо этого, когда драйвер выполняет iddCxSwapChainReleaseAndAcquireBuffer (или IddCxSwapChainReleaseAndAcquireSystemBuffer), он должен вызывать IddCxSwapChainGetPhysicallyContiguousAddress, чтобы получить физический адрес поверхности. IddCxSwapChainGetPhysicallyContiguousAddress сначала подождите все ожидающие команды отрисовки, а затем отмените кэши ЦП, связанные с диапазоном адресов, в котором хранится поверхность. Однако если первоначальный запрос на выделение поверхностей в физической непрерывной памяти завершился сбоем, то iddCxSwapChainGetPhysicallyContiguousAddress возвращает E_NOINTERFACE.