Comments 12
Супир. Обожаю подобные статьи.
Спасибо за статью!
а что вы имелли ввиду за «маленькую область 2х2 пространства фрактала»? Для чего она нужна?
И еще момент непонятный остается. Программа просчитывает один раз текстуру и выходит? или периодически вызывается и обновляет тестуру?
Можно и самому проверить, но пока нет возможности поставить здоровенный Unity.
а что вы имелли ввиду за «маленькую область 2х2 пространства фрактала»? Для чего она нужна?
И еще момент непонятный остается. Программа просчитывает один раз текстуру и выходит? или периодически вызывается и обновляет тестуру?
Можно и самому проверить, но пока нет возможности поставить здоровенный Unity.
Фрактал Мандельброта ограничен координатами от -1 до 1 по х и у. А у пикселей координаты от 0 до 1023. Нужно проецировать, чтоб фрактал на весь экран был.
Программа перерисовывает фрактал каждый раз, как пользователь изменит масштаб или позицию выводящего прямоугольника. Так что можно путешествовать по красочным прядям фрактала.
Программа перерисовывает фрактал каждый раз, как пользователь изменит масштаб или позицию выводящего прямоугольника. Так что можно путешествовать по красочным прядям фрактала.
cuda программируется точно также, только выходные данные идут не на рендеринг, а выгружаются обратно в память.
Вопрос скорее, зачем бить на квадраты 32x32. А дело в том, что пачка данных одновременно обрабатываемых мультипроцессором это 32 треда в одном варпе (разделение по вычислительным блокам) Х 32 варпа (разделение по времени), и важно кормить эту гидру синхронизированными данными, к примеру читать память так:
хорошо, а так:
плохо.
Внимательный, но неопытный в вопросах вычислений на GPU читатель перебьёт: позвольте! А откуда следует, что количество потоков 32x32? И как понимать «id.xy»?
Вопрос скорее, зачем бить на квадраты 32x32. А дело в том, что пачка данных одновременно обрабатываемых мультипроцессором это 32 треда в одном варпе (разделение по вычислительным блокам) Х 32 варпа (разделение по времени), и важно кормить эту гидру синхронизированными данными, к примеру читать память так:
var = mem[ id.x ] хорошо, а так:
var = mem[ id.x *1000 ] плохо.
Я этого не знал, но вы вероятно правы. Хотя, иногда нет другого выхода, кроме как делать примерно так:
потому что буфферы одномерные, а данные частенько двумерные, а структуру потоков делать одномерной вроде бы тоже не очень эффективно, да и лимиты есть по каждой оси.
var = buffer[id.x * height + id.y]потому что буфферы одномерные, а данные частенько двумерные, а структуру потоков делать одномерной вроде бы тоже не очень эффективно, да и лимиты есть по каждой оси.
Можно поменять местами id.x и id.y внутри kernel'а и делать так:
Правда, в таком случае надо об этом везде помнить, да и разные алгоритмы могут требовать разной укладки многомерного буффера в памяти. В некоторых случаях выгода от локальности данных внутри варпа может быть настолько большой, что имеет смысл в рантайме менять раскладку данных внутри буффера.
var = buffer[id.y * height + id.x]Правда, в таком случае надо об этом везде помнить, да и разные алгоритмы могут требовать разной укладки многомерного буффера в памяти. В некоторых случаях выгода от локальности данных внутри варпа может быть настолько большой, что имеет смысл в рантайме менять раскладку данных внутри буффера.
cuda программируется точно также, только выходные данные идут не на рендеринг, а выгружаются обратно в память.
Так здесь разве нельзя так же поступить? в последней строчке вместо
textureOut[id.xy] = colors[itn]; записать значения в какой-нибудь буфер и потом уже работать с этим буфером.
Да кому интересно делать какие-то «пустые» вычисления, если можно майнить с одной видеокарты от $2,5 в сутки.
А поставь таких видях с десяток и на работу не нужно ходить.
А поставь таких видях с десяток и на работу не нужно ходить.
прочитав заголовок и первый абзац решил, что речь пойдет о GPGPU
Sign up to leave a comment.
Вычисления на видеокарте, руководство, лёгкий уровень