В общем случае буфер - это непрерывная, управляемая область памяти.
Память - это большой набор адресов элементов для чтения / записи (конечно, один элемент на адрес), скажем, 2 30 адреса элементов 8-битной памяти составляют 1 ГБ памяти.
Если существует только одна программа, и она использует эти адреса статически (например, адреса от 0x1000 до 0x2000 используются для хранения списка элементов), тогда память не должна управляться, и в этом контексте буфер это просто непрерывный диапазон адресов.
Однако, если есть несколько программ или использование памяти программ является динамическим c (например, это зависит от того, сколько элементов было запрошено для чтения из ввода), тогда память должна управляться.
Вы должны отслеживать, какие диапазоны уже используются, а какие нет. Таким образом, буфер становится непрерывным диапазоном адресов с их атрибутами (например, используется ли он или нет).
Атрибуты буфера могут сильно различаться между различными распределителями памяти, в общем, мы скажем, что буфер управляется , потому что мы позволяем распределителю памяти обрабатывать его: найдите подходящий свободный диапазон, отметьте его как использованный, скажите, может ли он переместить буфер назад, отметьте его свободным, когда он будет завершен.
Это верно для каждой совместно используемой памяти, поэтому, безусловно, это верно для основной памяти (RAM) и графической памяти c.
Это память внутри графической c карта, доступ к которой осуществляется точно так же, как и в основной памяти (с точки зрения ЦП).
Что возвращает CreateBuffer - это COM-объект в основной памяти, который содержит метаданные, необходимые для простой обработки буфера
Он не содержит самого буфера, потому что этот COM-объект всегда находится в памяти, в то время как буфера обычно нет (он находится в графической c памяти).
CreateBuffer запрашивает драйвер graphi c для поиска подходящего диапазона свободных адресов в запрашиваемой памяти и заполнение некоторых метаданных .
Прежде чем процессор сможет получить доступ к основной памяти, необходимо настроить некоторые метаданные таблицы (таблицы страниц) как часть его механизма защиты.
Это также верно, если ЦПУ необходим доступ к памяти graphi c (возможно, с несколькими дополнительными шагами, для управления MMIO при необходимости).
В графическом процессоре также есть таблицы страниц, поэтому, если к графическому процессору требуется доступ к основной памяти, эти таблицы страниц также должны быть созданы.
Вы видите, что важно знать, как будет использоваться буфер.
Еще одна вещь, которую следует учитывать, - это то, что графические процессоры используют высокооптимизированный формат памяти - например, буфер, используемый для поверхности, может быть изображен как прямоугольник angular область памяти.
То же самое верно для буфера, используемого текстурой.
Однако два хранятся по-разному: поверхность сохраняется линейно, каждая строка за другой, в то время как буфер текстуры плиточный (как будто он сделан из множества, скажем, 16x16 поверхностей, сохраняемых линейно одна за другой).
Это ускоряет выборку и фильтрацию.
Кроме того, для некоторых графических процессоров может потребоваться изображение текстуры с заданным значением c область памяти, буфер вершин в другом и т. д.
Поэтому важно предоставить драйверу graphi c всю информацию, которая ему необходима, чтобы сделать лучший выбор при выделении буфера.
Как только буфер найден, драйвер (или среда выполнения D3D) инициализирует буфер по запросу.
Это может быть сделано путем копирования данных или псевдонимов через таблицы страниц (если шаг допускает это) и, в конечном итоге, использует некоторую форму копирования при записи.
Однако при этом исходные данные больше не нужны (см. this ).
COM-объект, возвращаемый CreateBuffer, является удобным прокси, затем он удаляется, благодаря обычному механизму come AddRef / Release, он также просит драйвер graphi c освободить буфер.