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

Отслеживание грязных битов

  • Статья

В этой статье описывается функция отслеживания битов грязное, которая поддерживается начиная с Windows 11 версии 24H2 (WDDM 3.2). Драйверы, поддерживающие динамическую миграцию на устройствах параллелизации GPU, также должны поддерживать грязное отслеживания битов.

Введение

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

Передача содержимого памяти между физическими узлами выполняется в двух общих передачах:

  1. Браунут: в течение периода брауна виртуальная машина по-прежнему работает, но система выполняет итеративное сохранение любых грязное данных. Цель заключается в том, что объем данных, грязных во время каждой итерации, становится меньше, пока он не будет конвергентирован на меньшем подмножестве данных, которые можно быстро копировать. Этот объем данных зависит от рабочей нагрузки компьютера и не гарантируется конвергентной к определенному размеру.

  2. Отключение. В течение периода отключения виртуальная машина приостановлена, а все оставшиеся грязное данные копируются. Эта копия гарантирует, что полученные данные на конечном компьютере совпадают с состоянием источника.

Без грязное битового отслеживания система должна полагаться на одну полную копию буфера кадров GPU (VRAM) в течение периода отключения. Чтобы поддерживать передачу брауна, оборудование должно иметь возможность активно отслеживать грязные страницы памяти и сообщать ему обратно в ОС, чтобы ОС знала только то, какую память копировать.

Подробный дизайн

Возможности создания отчетов

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

Запуск и остановка записи грязное

Если отслеживание грязное информации имеет высокую стоимость производительности оборудования, то имеет смысл включить только отслеживание грязное в период браунинга. В это время минимизация затрат на миграцию важнее, чем потенциальное влияние отслеживания на производительность.

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

Запрос грязное битов

Грязная информация представлена в виде битового плана грязное страниц. Каждый бит в битовой плоскости представляет одну "страницу" памяти. Размер страницы грязное данных не должен соответствовать естественным размерам страниц виртуальной адресации на GPU (например, 4 КБ/64 КБ). Это может быть любой наиболее оптимальный для конкретного оборудования. Драйвер сообщает этот размер страницы во время инициализации.

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

Виртуальные машины не обязательно переносятся в одно место назначения, поэтому миграция буфера кадров происходит для каждого виртуального экземпляра GPU. Поэтому драйвер должен иметь возможность запрашивать сведения о битовом плане для указанного под диапазона общего буфера кадров, представляющего этот конкретный виртуальный экземпляр GPU. Например, 8 ГБ GPU разделены четырьмя способами должны иметь возможность отдельно запрашивать и сбрасывать биты битового плана для каждого диапазона VRAM в 2 ГБ отдельно, не затрагивая другие грязное битовые данные.

Изменения DDI

Возможности

В DXGK_QUERYADAPTERINFOTYPE добавляются следующие ограничения.

  • DXGKQAITYPE_DIRTYBITTRACKINGCAPS

    Теперь система вызывает функцию DXGkDddiQueryAdapterInfo с DXGK_QUERYADAPTERINFOTYPE DXGKQAITYPE_DIRTYBITTRACKINGCAPS во время инициализации адаптера, чтобы определить возможности драйвера и оборудования для отслеживания битов грязное.

    KMD должен заполнить указанную DXGK_DIRTY_BIT_TRACKING_CAPS структуру, на которую указывает pOutputData .

  • DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS

    Если параметр KMD set DirtyBitTrackingSupported to TRUE, система вызывает функцию DXgkDdiQueryAdapterInfo с DXGK_QUERYADAPTERINFOTYPEDXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS для каждого сегмента памяти в системе для запроса сведений о поддержке отслеживания грязное битов.

    KMD должен заполнить указанную DXGK_DIRTY_BIT_TRACKING_SEGMENT_CAPS структуру, на которую указывает pOutputData .

DDIs на основе памяти

Отслеживание операций изменения в VRAM заключается в выделении, которые могут не выполняться непрерывно. Первоначальное использование в Динамической миграции, например, применяется к отслеживанию резерва framebuffer для виртуальной функции. Таким образом, физические адреса, представленные в отслеживании грязное битов, состоят из коллекции диапазонов, представляющих распределение, на которое выполняется работа.

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