Отслеживание использования распределения

При удалении списка выделений диспетчер видеопамяти (VidMm) больше не может отслеживать выделения, на которые ссылается определенный буфер команд. В результате VidMm больше не может отслеживать использование ресурсов и обрабатывать связанную синхронизацию. Эта ответственность теперь относится к драйверу пользовательского режима (UMD). В частности, UMD необходимо обрабатывать синхронизацию в отношении прямого доступа ЦП к выделению и переименованию.

VidMm асинхронно откладывает уничтожение выделенных ресурсов безопасным способом, который не блокирует вызывающий поток и является производительным. Такой UMD не должен беспокоиться о необходимости отложить освобождение ресурсов. Когда VidMm получает запрос на уничтожение выделения, по умолчанию предполагается, что команды, поставленные в очередь до запроса на уничтожение, могут потенциально получить доступ к выделению, которое уничтожается. Таким образом, VidMm откладывает операцию уничтожения до завершения поставленных в очередь команд. Если UMD знает, что ожидающие команды не обращаются к выделению, которое уничтожается, он может указать VidMm обработать запрос без ожидания, задав флаг AssumeNotInUse при вызове Deallocate2 или DestroyAllocation2.

Lock2

UMD отвечает за обработку надлежащей синхронизации в отношении прямого доступа к ЦП. В частности, требуется, чтобы UMD:

1. Поддержка семантики блокировки без перезаписи и отмены, что означает, что UMD необходимо реализовать собственную схему переименования.

2. Для операций с картой, требующих синхронизации (то есть, за исключением упомянутых ранее операций без перезаписи или удаления):

   • Возвращается WasStillDrawing, если попытка получить доступ к выделению, которое в данный момент занято, и вызывающий запросил, чтобы операция Lock не блокировала вызывающий поток (D3D11_MAP_FLAG_DO_NOT_WAIT).
   • Или, если флаг D3D11_MAP_FLAG_DO_NOT_WAIT не задан, дождитесь, пока выделение не станет доступным для доступа к ЦП. UMD необходимо реализовать ожидание без опроса. UMD будет использовать новый механизм мониторинга контекста.

На данный момент UMD продолжает вызывать LockCb/UnlockCb, чтобы попросить VidMm настроить выделение для доступа к ЦП. В большинстве случаев UMD может поддерживать сопоставление выделенных ресурсов на протяжении всего времени их существования. Однако в будущем LockCb и UnlockCb будут удалены в пользу новых вызовов Lock2Cb и Unlock2Cb. Цель этих новых обратных вызовов — предоставить свежую, чистую реализацию с набором обновленных аргументов и флагов.

Диапазоны свизлинга удаляются из версии WDDM 2. Разработчик драйвера несет ответственность за устранение зависимости от swizzling диапазонов при вызовах LockCb при переходе к реализации, основанной на Lock2Cb.

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

Драйвер указывает, доступен ли сегмент процессору через флаг CpuVisible, который находится в элементе Flags структуры DXGK_SEGMENTDESCRIPTOR.

Для выделения ресурсов, доступных для ЦП:

• Кэшируемые выделения, доступные для ЦП, должны находиться в сегменте апертуры или быть неактивными, чтобы быть заблокированными. Мы не можем гарантировать согласованность кэша между ЦП и сегментом памяти на графическом модуле обработки (GPU).
• Выделения, доступные для ЦП, расположенные в полностью доступном для ЦП сегменте памяти (изменяемой с помощью редизуемой ПАНЕЛИ), гарантированно будут заблокированы и могут возвращать виртуальный адрес. В этом сценарии не требуются специальные ограничения.
• Выделения, доступные для ЦП, расположенные в недоступном для ЦП сегменте памяти (с доступом или без доступа к CpuHostAperture), могут не сопоставляться с виртуальным адресом ЦП по различным причинам. Если CpuHostAperture превышает доступное пространство или выделение не указывает апертурный сегмент, получить виртуальный адрес невозможно. По этой причине все выделения, доступные для ЦП, в сегментах памяти, не доступных для ЦП, должны содержать сегмент диафрагмы в поддерживаемом наборе сегментов. Это требование гарантирует, что VidMm может разместить выделение в системной памяти и предоставить виртуальный адрес.
• Выделения, доступные для ЦП, уже размещённые в системной памяти (или сопоставленные в апертурном сегменте), гарантированно будут функционировать надежно.

Для выделения ресурсов, не доступных для ЦП:

• Выделения, доступные для ЦП, поддерживаются объектами раздела, которые не могут указывать непосредственно на буфер кадра GPU. Чтобы заблокировать выделение, недоступное для ЦП, оно должно поддерживать апертурный сегмент в поддерживаемом наборе сегментов или уже находиться в системной памяти (не должно быть резидентом на устройстве).

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

Lock2 в настоящее время не содержит флагов, а зарезервированные биты флагов должны быть 0.

CpuHostAperture

Чтобы улучшить поддержку блокировки с сегментами памяти, недоступными для ЦП, в случае сбоя при изменении размера BAR, в апертуре PCI предоставляется CpuHostAperture. CpuHostAperture ведет себя как диспетчер на основе страниц, который затем можно сопоставить непосредственно с регионами видеопамяти через функцию интерфейса драйвера устройства DxgkDdiMapCpuHostAperture(DDI). Затем VidMm может сопоставить диапазон виртуального адресного пространства непосредственно с неконтинуальным диапазоном ЦПHostAperture и иметь CpuHostAperture для последующего сопоставления с видеопамятью без необходимости переупорядочивания диапазонов.

Максимальный объем защищаемой памяти, на который ЦП может ссылаться в сегментах недоступной для ЦП памяти, ограничен размером CpuHostAperture. Сведения о предоставлении ЦПHostAperture ядру графики DirectX можно найти в диафрагме узла ЦП.

Когерентность ввода-вывода

На платформах x86/x64 на сегодняшний день все ГП должны поддерживать когерентность ввода-вывода через PCIe, чтобы ГП могли считывать или записывать данные в кэшируемую системную память и поддерживать когерентность с ЦП. При отображении поверхности как кэш-когерентной с точки зрения GPU, GPU необходимо отслеживать кэши ЦП при доступе к поверхности. Эта форма когерентности обычно используется для ресурсов, из которых ожидается, что ЦП будет считывать, например, некоторые промежуточные поверхности.

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

• Данные, которые необходимо записать обратно (запись ЦП, чтение GPU)
• Устаревшие данные, которые должны быть недействительными (запись GPU, чтение ЦП).

На платформе без когерентности ввода-вывода ответственность за отслеживание доступа ЦП и GPU к выделениям ложится на UMD. Ядро графики предоставляет новый DDI инвалидации кэша, который UMD может использовать для записи данных обратно и аннулирования диапазона виртуальных адресов, связанного с кэшируемым выделением. На платформах, которые не поддерживают когерентность операций ввода-вывода, от UMD требуется вызвать эту функцию после записи ЦП и до чтения GPU, а также после записи GPU и перед чтением ЦП. Последнее может показаться неочевидным поначалу. Но, так как ЦП мог спекулятивно считать данные до того, как запись от GPU попадёт в память, необходимо сделать недействительными все кэши ЦП, чтобы ЦП снова считывал данные из оперативной памяти.