Forums :: Register :: Login |
anonymous user |
Common forum | 1 | 2 | next »» | Create new thread
|
CEMEH
Posts: 123 |
2008-11-21 11:01:44
| reply!
А вот давайте поговорим про наши будущие радости. Главная статья тут - http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf Итак, чего там: - Несколько простых in-order ядер (похоже, больше чем в Cell). - Новый набор инструкций, расширенный на 512 bit SSE, 16 регистров. - Инструкции для Gather/scatter на load/store - Два порта инструкций - один compute, другой basic x86/load/store/etc. Не уверен, есть ли shuffle, был бы - было бы круто. - 256 kb кеша на ядро, можно устанавливать приоритет кеш-линиям и использовать его как scratchpad - 4x Hyper-Threading на ядро - Отдельные юниты для texture fetch Вот я очень хорошо понимаю, почему такая херотень очень отличается от GPU. GPU работает совсем не так. В GPU 20 с лишним ядер, и в каждом принципиально больше регистров. В G200 вот 8192, как нам говорит CUDA manual. Много регистров - затем, чтобы одновременно висело много тредов, не 4 как на Larrabee. Много тредов - чтобы лучше скрадывать memory latency, тредов много, найдется тот, кому нужно вычислять. Эффективный на тред кеш меньше, но области близкие - фетчат текстуры условно рядом. На Larrabee надо скрывать latency самому - префетчить заранее, тратить на это кеш, регистров не хватит. Так как регистры очень широкие (512 - дохера), то данные толстыми кусами, префетчить далеко. В общем, в сравнении с GPU все более-менее ясно, что все неясно. А теперь расскажите мне, про Larabee в сравнении с Cell? В чем принципиальные отличия? У Cell сколько регистров? Или DMA гораздо лучше менеджить? Или чо-каво? |
|
shodan
Posts: 44 |
to: CEMEH, 2008-11-21 13:31:34
| reply!
> На Larrabee надо скрывать latency самому - префетчить заранее, One remaining issue is texture co-processor accesses, which can have hundreds of clocks of latency. This is hidden by computing multiple qquads on each hardware thread. Each qquad’s shader is called a fiber. The different fibers on a thread co-operatively switch between themselves without any OS intervention. A fiber switch is performed after each texture read command, and processing passes to the other fibers running on the thread. Fibers execute in a circular queue. The number of fibers is chosen so that by the time control flows back to a fiber, its texture access has had time to execute and the results are ready for processing. |
|
IronPeter
Posts: 127 |
to: CEMEH, 2008-11-21 14:02:09
| reply!
> Главная статья тут - > http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf > А теперь расскажите мне, про Larabee в сравнении с Cell? В чем принципиальные > отличия? У Cell сколько регистров? Или DMA гораздо лучше менеджить? Или чо-каво? > Оно абсолютно такое же. С точностью до мелких нюансов. 128 битных регистров у него 128 штук. Итого на 512 floats. У Larrabee 16 регистров по 16 floats, помноженные на 4 SMT потока. Итого на 1024 floats. Локальной памяти у Cell 256 кило. У Larrabee тоже 256. Причем вариант Larrabee можно софтверно превратить в вариант Cell. Надо взять, выделить несколько раз по 256 кило в основной памяти. И там хранить локальные данные каждого процессора, оно скоро закешируется. Да, оно будет тормозить, сообщая по кольцевой шине о каждой транзакции внутри L2 кеша. Легко отспекать, что транзакция к L2 будет не меньше времени полупрохождения сигнала по кольцу. Десятки тактов. На Cell 5 тактов. Только надо учесть, что на Cell транзакция в LS осуществляется над 128 битами. А тут над 512. Паритет. У Larrabee таки есть скэтчпад ( LS ) и DMA операции загрузки в него. Почему-то LS называется тут L1 cache - но это на совести авторов. Содержит разумные 32 килобайта. И прямо можно делать DMA. Только без явных проверок на готовность. GPU, Larrabee и Cell - это одна и та же архитектура. С точностью до нюансов. Кольцо, связывающее процессоры сопоставимых характеристик. Поглядев на Larrabee, можно увидеть даже правый и левый пайплайны. Легко догадаться, где исполняется команда jump... |
|
IronPeter
Posts: 127 |
to: IronPeter, 2008-11-21 14:23:46
| reply!
PS. про команды работы с L2 и L1 нужно почитать чуть внимательнее Together with Larrabee’s load-op VPU instructions, this means that the L1 cache can be treated somewhat like an extended register file. These cache control instructions also allow the L2 cache to be used similarly to a scratchpad memory, while remaining fully coherent. Надо конкретные инструкции работы с кешами смотреть. |
|
CEMEH
Posts: 123 |
to: shodan, 2008-11-21 17:42:52
| reply!
> > На Larrabee надо скрывать latency самому - префетчить заранее, > > One remaining issue is texture co-processor accesses, which can have hundreds > of clocks of latency. This is hidden by computing multiple qquads on each > hardware thread. Each qquad’s shader is called a fiber. The different fibers on > a thread co-operatively switch between themselves without any OS intervention. > A fiber switch is performed after each texture read command, and processing > passes to the other fibers running on the thread. Fibers execute in a circular > queue. The number of fibers is chosen so that by the time control flows back to > a fiber, its texture access has had time to execute and the results are ready > for processing. То есть сделать такое количество файберов, чтобы код отдельного шейдера до следующего texture access выполнялся столько же, сколько худший latency до памяти... Опять утолщает working set, потому что худший случай. А вдруг оно в кеше все? А вдруг два фетча друг за другом? Т.е. на GPU бы автоматически тому треду, которому фетч дошел, было бы продолжено выполнение. Но я эмоцию понял, да. |
|
CEMEH
Posts: 123 |
to: IronPeter, 2008-11-21 17:58:58
| reply!
> Оно абсолютно такое же. С точностью до мелких нюансов. 128 битных регистров у > него 128 штук. Итого на 512 floats. У Larrabee 16 регистров по 16 floats, > помноженные на 4 SMT потока. Итого на 1024 floats. Ничего, что эти 1024 во-первых, разделены на 4 SMT-треда, а во-вторых, состоят из 16 длинных регистров, а не 128 коротких? Т.е. на Larrabee код будет стараться загрузить чанк 64 флоата для одной SIMD операции, то есть 64 "элемента" за раз. Т.е. будет держать в регистрах данных на 64 элемента, а не на 16, то есть свободы в регистрах совсем мало. Разве что LS этот еще как регистры использовать, да он поди для SMT shared. > Локальной памяти у Cell 256 кило. У Larrabee тоже 256. Причем вариант Larrabee > можно софтверно превратить в вариант Cell. Надо взять, выделить несколько раз > по 256 кило в основной памяти. И там хранить локальные данные каждого > процессора, оно скоро закешируется. Да, оно будет тормозить, сообщая по > кольцевой шине о каждой транзакции внутри L2 кеша. Легко отспекать, что > транзакция к L2 будет не меньше времени полупрохождения сигнала по кольцу. > Десятки тактов. На Cell 5 тактов. Только надо учесть, что на Cell транзакция в > LS осуществляется над 128 битами. А тут над 512. Паритет. Можно же тупо L2 как scratchpad использовать, не? |
|
shodan
Posts: 44 |
to: CEMEH, 2008-11-21 23:31:43
| reply!
> Т.е. на GPU бы автоматически тому треду, которому фетч дошел, было бы > продолжено выполнение. Я читал по диагонали, поэтому не понял, руками они сделали файберы, или железка сама. Руками? |
|
CEMEH
Posts: 123 |
to: shodan, 2008-11-22 08:49:46
| reply!
> > Т.е. на GPU бы автоматически тому треду, которому фетч дошел, было бы > продолжено выполнение. > > Я читал по диагонали, поэтому не понял, руками они сделали файберы, или железка > сама. > > Руками? Ну, как мне кажется, из фразы The different fibers on a thread co-operatively switch between themselves without any OS intervention. следует, что руками, да. Иначе какое оно co-operatively? |
|
IronPeter
Posts: 127 |
to: CEMEH, 2008-11-22 11:23:02
| reply!
> Ничего, что эти 1024 во-первых, разделены на 4 SMT-треда, а во-вторых, состоят > из 16 длинных регистров, а не 128 коротких? > Т.е. на Larrabee код будет стараться загрузить чанк 64 флоата для одной SIMD > операции, то есть 64 "элемента" за раз. Очевидно считается, что для скалярного алгоритма достаточно 16 float регистров. А вектора - это всего лишь 4-ки скаляров, не более того. У 5xxx-6xxx семейства GPU были примерно такие же ограничения. > Можно же тупо L2 как scratchpad использовать, не? Я там тупо неправильно прочитал. Там scratchpad L2, а не L1. В принципе накладные расходы - они на первую аллокацию линейки памяти в кеше. Так что если активная область процессора имеет размер меньше 256 кило и не пересекается с другими процессорами - то оно действует как spu LS. А про конкретные командочки, которые помогают менеджить кеш - надо читать внимательнее. Думаю, что под файберами имеется в виду не файберы уровня операционной системы. А просто большой сабсет данных, над которым крутится карусель. Как в 5xxx-6xxx, да и последующей CUDA. |
|
CEMEH
Posts: 123 |
to: IronPeter, 2008-11-23 05:56:08
| reply!
> Очевидно считается, что для скалярного алгоритма достаточно 16 float регистров. > А вектора - это всего лишь 4-ки скаляров, не более того. У 5xxx-6xxx семейства > GPU были примерно такие же ограничения. Ну вот а на Cell было не 16, а 128. Разве не помогало? > А про конкретные командочки, которые помогают менеджить кеш - надо читать > внимательнее. Я погляну, ага. > Думаю, что под файберами имеется в виду не файберы уровня операционной системы. > А просто большой сабсет данных, над которым крутится карусель. Как в 5xxx-6xxx, > да и последующей CUDA. А расскажи подробней, как это? Мне Боря что-то тоже про карусель рассказывал, я так и не понял. Это метод выбора следующего warp'a на обработку такой или как? |
|
IronPeter
Posts: 127 |
to: CEMEH, 2008-11-23 10:13:17
| reply!
> Ну вот а на Cell было не 16, а 128. Разве не помогало? Помогает в нюансах. Вот делаем мы какую-нибудь фигню, вроде потокового вертекс-процессинга. Латентности команд от 4 до 8. То есть нам необходимо обрабатывать сразу 16-32 вертекса ( а не 4-8! ). И код выглядит примерно как fm r0, r4, r8 fm r1, r5, r9 fm r2, r6, r10 fm r3, r7, r11 (fm это float multiply ). В данном конкретном месте ничего не изменится, если использовать регистры в 4 раза большей ширины. Однако даже в коде выше могут быть регистровые зависимости. И зависимости по памяти. Оно лечится на этапе компиляции - командочки мелкие, их можно переставлять по-разному. Группировать вместе команды с левого и правого пайпа. У Larrabee такое лечится 4 нитями, которые плотно занимают функциональные устройства. Есть другие задачи. Скажем, софтверный triangle cull. Там надо взять и компактифицировать массив, в котором дырки. Вот такое делать проще, если команды над 4 числами,а не 16. Наверное, тут надо будет вывернуть мозги наизнанку. И пользовать тот самый регистровй memory scatter-gather. На cell его нет. > А расскажи подробней, как это? Мне Боря что-то тоже про карусель рассказывал, я > так и не понял. Это метод выбора следующего warp'a на обработку такой или как? Ну да. Основная идея - то что данных очень много. А собственно живых ALU меньше. Данных должно быть не просто много, чтобы скрыть регистровые латентности, а дофига, чтобы скрыть латентности памяти. Базово pixel quad - это такая сущность со своим набором регистров, битовой маской ( в частности получается из разных джампов ), и instruction pointer. ALU блок берет и обрабатывает эти сущности, одну за другой. Наступил джамп - плодит сущность на две, с разными ip и битовыми масками. Сами регистровые данные можно плодить, можно не плодить. Как работает скедулер на тех ранних GPU - никто не знает точно. Кто говорит - не знает, кто знает - не говорит. На CUDA уже можно догадываться поточнее. |
|
CEMEH
Posts: 123 |
to: IronPeter, 2008-11-23 19:59:08
| reply!
> Ну да. Основная идея - то что данных очень много. А собственно живых ALU > меньше. Данных должно быть не просто много, чтобы скрыть регистровые > латентности, а дофига, чтобы скрыть латентности памяти. Базово pixel quad - это > такая сущность со своим набором регистров, битовой маской ( в частности > получается из разных джампов ), и instruction pointer. ALU блок берет и > обрабатывает эти сущности, одну за другой. Наступил джамп - плодит сущность на > две, с разными ip и битовыми масками. Сами регистровые данные можно плодить, > можно не плодить. > > Как работает скедулер на тех ранних GPU - никто не знает точно. Кто говорит - > не знает, кто знает - не говорит. На CUDA уже можно догадываться поточнее. Не, это я все понимаю. Но почему карусель? Мне казалось, если данные на warp из памяти пришли, оно мгновенно может на него переключиться в случае недостатка инструкций. Т.е. исполняет в той последовательности, в какой memory requests/ALU latency позволяет. Боря говорил, что там все сложнее и ебанутее. |
|
IronPeter
Posts: 127 |
to: CEMEH, 2008-11-23 20:31:40
| reply!
> Не, это я все понимаю. Но почему карусель? Мне казалось, если данные на warp из > памяти пришли, оно мгновенно может на него переключиться в случае недостатка > инструкций. Т.е. исполняет в той последовательности, в какой memory > requests/ALU latency позволяет. Боря говорил, что там все сложнее и ебанутее. Ну смотри, почему это может быть не так.Вот представь старое-старое железо, которое умеет текстурные стадии. Те самые комбайнеры. Представь, что на перестройку стадий надо тратить некоторое фиксированное время. Чтобы превратить конкретный instruction pointer в бандл инструкций - ту самую настройку комбайнеров. И чтобы зафлашить прежние вычисления, с другими настройками конвеера. Вплоть до того, что надо зафетчить шейдер из памяти :|. Впрочем, конкретно тут только мои домыслы. На вопрос "так ли это" один человек в теме ответил "да, именно так". Второй, с такой же уверенностью "оно совсем не так". |
|
CEMEH
Posts: 123 |
to: IronPeter, 2008-11-25 01:03:14
| reply!
> Ну смотри, почему это может быть не так.Вот представь старое-старое железо, > которое умеет текстурные стадии. Те самые комбайнеры. Представь, что на > перестройку стадий надо тратить некоторое фиксированное время. Чтобы превратить > конкретный instruction pointer в бандл инструкций - ту самую настройку > комбайнеров. И чтобы зафлашить прежние вычисления, с другими настройками > конвеера. Вплоть до того, что надо зафетчить шейдер из памяти :|. > > Впрочем, конкретно тут только мои домыслы. На вопрос "так ли это" один человек > в теме ответил "да, именно так". Второй, с такой же уверенностью "оно совсем не > так". Странно это все, вроде warp'ы в этом смысле и так каждые два такта переключаются, а шейдер фетчить надо что при переходе к следующей инструкции, что к другому шейдеру. Надо короче специалиста звать. Боря, ау! А что за форум-то? Линк? |
|
IronPeter
Posts: 127 |
to: CEMEH, 2008-11-25 11:58:12
| reply!
> > а шейдер фетчить надо что при переходе к следующей инструкции... Ну так в карусели эти переходы очень редкие. Сначала инструкция ( точнее бандл ) над всеми данными, потом следующий бандл... Еще надо помнить, что у пухелей есть жесткий order. Они в ROP должны в известном порядке приходить. Чтобы реализовать фичу "махонький треугольник на махоньком треугольнике с блендом". |
|
CEMEH
Posts: 123 |
to: IronPeter, 2008-11-25 17:51:10
| reply!
> >> а шейдер фетчить надо что при переходе к следующей инструкции... > > Ну так в карусели эти переходы очень редкие. Сначала инструкция ( точнее бандл > ) над всеми данными, потом следующий бандл... Даже не при условном переходе, при просто переходе на следующую инструкцию. Ну в общем да, одно префетчить можно, другое нельзя, конечно. > Еще надо помнить, что у пухелей есть жесткий order. Они в ROP должны в > известном порядке приходить. Чтобы реализовать фичу "махонький треугольник на > махоньком треугольнике с блендом". Это вообще какая-то абсолютно ортогональная проблема, но про нее тоже интересно поговорить. Я думал, там какая-то накапливающаяся очередь на ROP есть, нет? Т.е. есть небольшой промежуточный "layer cache", где висят уже посчитанные, но еще не пробленденные пикселя. Короче, неинтересно самим фантазировать. |
|
look4awhile
Posts: 37 |
to: CEMEH, 2008-11-25 22:21:22
| reply!
> > Ну смотри, почему это может быть не так.Вот представь старое-старое железо, > которое умеет текстурные стадии. Те самые комбайнеры. Представь, что на > перестройку стадий надо тратить некоторое фиксированное время. Чтобы превратить > конкретный instruction pointer в бандл инструкций - ту самую настройку > комбайнеров. И чтобы зафлашить прежние вычисления, с другими настройками > конвеера. Вплоть до того, что надо зафетчить шейдер из памяти :|. > > > > Впрочем, конкретно тут только мои домыслы. На вопрос "так ли это" один > человек в теме ответил "да, именно так". Второй, с такой же уверенностью "оно > совсем не так". > > Странно это все, вроде warp'ы в этом смысле и так каждые два такта > переключаются, а шейдер фетчить надо что при переходе к следующей инструкции, > что к другому шейдеру. > > Надо короче специалиста звать. Боря, ау! ну зачем мы обсуждаем старое железо с комбайнерами-то? новое вовсе без комбайнеров. а проблемы "переключения" лечатся очень просто. делается не одна карусель, а несколько. оперция "зафетчить инструкции и построить из них настройки комбайнеров" - асинхронная > > А что за форум-то? Линк? |
|
look4awhile
Posts: 37 |
to: IronPeter, 2008-11-25 22:23:56
| reply!
> Ну да. Основная идея - то что данных очень много. А собственно живых ALU > меньше. Данных должно быть не просто много, чтобы скрыть регистровые > латентности, а дофига, чтобы скрыть латентности памяти. скрыть латентность - это такая логическая бомба. проще и понятнее говорить расширить throughput. и тогда проблема "мало данных" уже не проблема латентности, а проблема utilization. т-е как если-бы железо работало не с максимальной эффективностью - что мы и имеем возможность наблюдать скажем в nvperfhud. чем шире throughput, тем хуже загрузка на типичных данных. |
|
CEMEH
Posts: 123 |
to: look4awhile, 2008-11-26 02:58:29
| reply!
> а проблемы "переключения" лечатся очень просто. делается не одна карусель, а > несколько. оперция "зафетчить инструкции и построить из них настройки > комбайнеров" - асинхронная Вот чо-за карусель-то имеется ввиду? Карусель - это если оно крутится по очереди. Ну вот как в пейпере про Larrabee, их карусель файберов - все по очереди зафетчили, потом в такой же очередности считают. Здесь же оно скачет туда-сюда, нет? То на этом ворпе зафетчились данные, то на другом, выполняется в правильном порядке готовности. Я похожу все как-то слишком радужно понимаю? :) |
|
CEMEH
Posts: 123 |
to: look4awhile, 2008-11-26 03:01:00
| reply!
> скрыть латентность - это такая логическая бомба. проще и понятнее говорить > расширить throughput. и тогда проблема "мало данных" уже не проблема > латентности, а проблема utilization. т-е как если-бы железо работало не с > максимальной эффективностью - что мы и имеем возможность наблюдать скажем в > nvperfhud. чем шире throughput, тем хуже загрузка на типичных данных. А-а-а-а-а-а, термояд, Боря снова с нами!!!! |
|
look4awhile
Posts: 37 |
to: CEMEH, 2008-11-26 07:49:02
| reply!
> > а проблемы "переключения" лечатся очень просто. делается не одна карусель, а > несколько. оперция "зафетчить инструкции и построить из них настройки > комбайнеров" - асинхронная > > Вот чо-за карусель-то имеется ввиду? Карусель - это если оно крутится по > очереди. Ну вот как в пейпере про Larrabee, их карусель файберов - все по > очереди зафетчили, потом в такой же очередности считают. там комбайнеры. их настроить - ненулевое время. хуже - получить из шейдера настройки - ненулевое. > Здесь же оно скачет туда-сюда, нет? То на этом ворпе зафетчились данные, то на > другом, выполняется в правильном порядке готовности. проходами, очевидно. подумай проще - что бывает при переключении между шейдерами. или когда пикселей мало. > > Я похожу все как-то слишком радужно понимаю? :) ага |
|
IronPeter
Posts: 127 |
to: look4awhile, 2008-11-26 08:26:47
| reply!
> чем шире throughput, тем хуже загрузка на типичных данных. Да, фраза "расшить латентности" работает в случае, когда данных бесконечно много. В реальности все действительно хуже. Страшно думать, что бывает, когда треугольники размером в пару пикселей. И при этом друг над другом. С блендингом. Как сходят с ума эти карусели, ROP мержеры. Ну а что делать. Или мы делаем такие локальные алгоритмы, которые по своей сути состоят из зависимых кусков. Или реализуем абсолютно юниформный алгоритм в стиле "лучик летит по сцене и утыкается, утыкается, утыкается". При этом огребаем проблемы нелокальности. Я вот честно пытался на SPU написать хороший zonly растеризатор. В идеальных условиях - тайл и треугольники в LS. Хуй там. Не получается юнифморино победить одновременно большие треугольники и мелочь. И это в простейшем алгоритме. |
|
Dragon
Posts: 10 |
to: CEMEH, 2008-12-24 22:41:23
| reply!
Новые презентации по Larrabee http://sa08.idav.ucdavis.edu/ Хотя там практически нет ничего нового. |
|
CEMEH
Posts: 123 |
to: Dragon, 2008-12-29 09:46:55
| reply!
> Новые презентации по Larrabee > http://sa08.idav.ucdavis.edu/ > > Хотя там практически нет ничего нового. > Я кстати почитал, там детальней рассматривается схема с файберами. Называются конкретные цифры - 2-10 fibers per HW thread. Типа, файбер страртует асинхронный tex fetch и переключается на следующий. С Hyper-threading на 4 это становится 8-40 и типа растаскивает latency от 100 тактов фетча. Не знаю, не знаю. Надо пробовать на практике. |
|
IPv6
Posts: 25 |
to: CEMEH, 2008-12-30 02:55:22
| reply!
> > Новые презентации по Larrabee > > http://sa08.idav.ucdavis.edu/ > > > > Хотя там практически нет ничего нового. > > > > Я кстати почитал, там детальней рассматривается схема с файберами. Называются > конкретные цифры - 2-10 fibers per HW thread. Типа, файбер страртует > асинхронный tex fetch и переключается на следующий. С Hyper-threading на 4 это > становится 8-40 и типа растаскивает latency от 100 тактов фетча. Не знаю, не > знаю. Надо пробовать на практике. |
|
IPv6
Posts: 25 |
to: CEMEH, 2008-12-30 02:55:30
| reply!
> > Новые презентации по Larrabee > > http://sa08.idav.ucdavis.edu/ > > > > Хотя там практически нет ничего нового. а кто нибудь кроме интела пытается/лся делать нечто подобное? лараби конечно первый блин комом... но не хотелось бы чтобы новый виток загнулся на старте! :) |
|
IronPeter
Posts: 127 |
to: IPv6, 2009-01-08 10:23:17
| reply!
> а кто нибудь кроме интела пытается/лся делать нечто подобное? > лараби конечно первый блин комом... но не хотелось бы чтобы новый виток > загнулся на старте! :) > Делали. Суперы от Крея фактически такие были. Очень широкий регистровый файл, DMA, независимые функциональные устройства, связанные по быстрой шине. Так что тот же cell ( или современные GPU ) - это возрождение суперкомпьютеров 20 летней давности на современных технологических нормах. Единственно с тех времен изменилось соотношение по скорости (загрузка-выгрузка)/(flop). Было 1 : 1, стало 5:1 или местами 10:1. То есть на одну загрузку выгрузку сейчас можно сделать 10 бесплатных flop32 операций. |
|
Loyso
Posts: 46 |
to: IronPeter, 2009-01-08 11:51:34
| reply!
> Так что тот же cell ( или современные GPU ) - это возрождение суперкомпьютеров > 20 летней давности на современных технологических нормах. Да что уж говорить, это возрождение и НЕ-суперкомпьютеров 20 летней давности. Те же транспьютеры задумывались как дешевый many-core. То, что тогда проект оказался коммерчески неудачным, проблемы не отменило. Просто тогда выгодней и дешевле было пойти по наращиванию мегагерц. |
|
IronPeter
Posts: 127 |
to: Loyso, 2009-01-08 13:36:35
| reply!
> > Так что тот же cell ( или современные GPU ) - это возрождение > суперкомпьютеров 20 летней давности на современных технологических нормах. > > Да что уж говорить, это возрождение и НЕ-суперкомпьютеров 20 летней давности. > Те же транспьютеры задумывались как дешевый many-core. То, что тогда проект > оказался коммерчески неудачным, проблемы не отменило. Просто тогда выгодней и > дешевле было пойти по наращиванию мегагерц. Да. Транспьютеры ( много истории можно найти в гугле ) - это Larrabee. Суперы от Крея - это cell/gpu. Впрочем, транспьютеры и в суперах использовались. |
|
Loyso
Posts: 46 |
to: IronPeter, 2009-01-09 01:45:00
| reply!
> Да. Транспьютеры ( много истории можно найти в гугле ) - это Larrabee. > Суперы от Крея - это cell/gpu. Впрочем, транспьютеры и в суперах использовались. Есть одно огромное различие. Транспьютеры дали толчок математике в виде process calculi и формальных языков (и языков программирования, на них основанных). А у Intel рекламный лозунг: "Larrabee можно будет программировать ДАЖЕ на C++!". Поколение П. |
|
MatriX
Posts: 6 |
to: Loyso, 2009-03-24 19:27:37
| reply!
Интринсики larrabee http://software.intel.com/en-us/articles/prototype-primitives-guide/ |
|
Dragon
Posts: 10 |
to: MatriX, 2009-04-01 19:27:22
| reply!
> Интринсики larrabee > http://software.intel.com/en-us/articles/prototype-primitives-guide/ > > А вот презентация с GDC http://translate.google.com/tr...tm&sl=ja&tl=ru&history_state0= |
|
IronPeter
Posts: 127 |
to: Dragon, 2009-04-02 08:08:28
| reply!
> > Интринсики larrabee > > http://software.intel.com/en-us/articles/prototype-primitives-guide/ > > > > > > А вот презентация с GDC > http://translate.google.com/tr...tm&sl=ja&tl=ru&history_state0= Typical texture operations, including decompression, anisotropic filtering Интересно бы на интерфейсец глянуть. В интринсиках вроде нету ничего такого. |
|
Dragon
Posts: 10 |
to: IronPeter, 2009-04-02 15:14:09
| reply!
> Typical texture operations, including > decompression, anisotropic filtering > > Интересно бы на интерфейсец глянуть. В интринсиках вроде нету ничего такого. > > Да я тоже все пытался найти как воспользоваться этим модулем, но никакой информации так и неудалось найти. |
|
IronPeter
Posts: 127 |
to: Dragon, 2009-04-03 08:40:01
| reply!
> Да я тоже все пытался найти как воспользоваться этим модулем, но никакой > информации так и неудалось найти. Странно, он там на картиночке один для всех ядер. Как-то стремно туда-сюда гонять по шине текстурные координаты. Это float2 + float mip level. Что сильно больше, чем типичный char[4] результат. В обычном железе есть специальная магия, которую мы не видим. Магия по вычислению мип уровня и по анизотропной фильтрации. Работает эта магия за счет того, что запросы на текстурное чтение идут блоками. Скажем, 2x2. Тут что, тоже quad из пикселей будут запрашивать? |
|
clamky
Posts: 16 |
to: CEMEH, 2009-04-06 01:49:21
| reply!
http://www.ddj.com/architect/216402188 |
Common forum | 1 | 2 | next »» | Create new thread
