общая память и текстура памяти в opencl

Question

Я пишу код деинтерлейсинга в Opencl. Я читаю пиксели, используя read_imageui() API в локальной памяти.

Так же, как код по адресу: https://opencl-book-samples.googlecode.com/svn-history/r29/trunk/src/Chapter_19/oclFlow/lkflow.cl

согласно моему пониманию, когда мы читаем пиксели с помощью этого API мы читаем из памяти текстур. Я сомневаюсь, что использование пикселей сначала в общей памяти поможет мне получить любую скорость, поскольку память текстур уже действует как кеш и обеспечивает быстрый доступ к данным.

Может ли кто-нибудь уточнить мои сомнения?

Answer 1

1. Если вы можете поместить все свои данные в личную память, прочитав ее с помощью read_imageui, вы обязательно должны это сделать. Имейте в виду, что у вас есть только 256 байт частной памяти на рабочий элемент, если ваше ядро ​​компилирует SIMD16 и 512 байтов, если оно компилирует SIMD8.

2. Следует ли использовать локальную память или нет, зависит от шаблона доступа. Действительно, у Samplers есть свои кеши L1 и L2, поэтому, если ваши обращения к данным всегда попадают в кеши, вы должны быть в порядке. Помните, что локальная память банка, поэтому у вас есть 16 банков, из которых вы можете получить 4 байта за раз, что означает, что вы получаете полную пропускную способность, если вы ударите все 16 банков из всех рабочих элементов в одном аппаратном потоке (обычно 16 или 8 из них). Таким образом, у вас может возникнуть ситуация, когда вам лучше сначала считывать данные изображения в локальную память, а затем обращаться к локальной памяти упорядоченным образом. Хорошим примером этого являются алгоритмы, такие как SIFT или SURF, где вы получаете доступ к изображению таким образом, что сэмплеровский кеш действительно не очень помогает (вы все равно получаете преимущества интерполяции семплера), но затем вы размещаете все эти данные в локальной памяти и получаете доступ к ним повторно в довольно регулярной схеме.

Answer 2

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