http://en.wikipedia.org/wiki/Open_graphics

http://en.wikipedia.org/wiki/Open_graphics А такая открытая видеокарта не тоже самое вроде старый проект... НАверное и опенгл работает там

Ты хочешь чтобы игры не шли на железе поддерживающем OpenGL 3.3 ?

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

Поддержат ЧТО? DirectX как бы и была попытка выкинуть отстающий opengl на свалку и сделать приличный API для игр - вот его и поддерживают.

Формальный критерий в языке программирования высокого уровня. Компилятор оптимизирует программу не нарушая прямо то что написано явно. Места где компилятор может переставить инструкции, например, четко определены стандартом (С++). Не нарушая спецификаций компилятор может делать все что угодно.

Вот тут и начинается проблема. Ключевой момент оптимизации - как раз момент генерации EDIF. Современные FPGA имеют неоднородную структуру, в них 2-3 вида LUT и куча вспомогательных блоков. «Свернуть» обратно в такие блоки произвольный EDIF в общем случае очень тяжело, это NP-полная задача. Поэтому все синтезаторы всегда в курсе архитектуры, под которую EDIF делается.

Размещение, строго говоря, задача, неотделимая от синтеза. На стадии синтеза делается значительная ее часть.

Ну я же не предлагаю генерить какой-то абстрактный нетлист, а только с примитивами которые есть в конкретной FPGA, даже размещение можно организовать с помощью LOC-констрейнтов для Xilinx. Другое дело, что почему-то это не особо кого интересует, видимо сложность задачи и доступность бесплатных средств разработки приводят к тому, что никто особо не рвётся заниматься этим. Кстати заметил еще одну вещь: несмотря на наличие свободного софта для трассировки pcb (gEDA,KiCAD), нигде нет нормального автотрассировщика с констрейнтами (чтобы выровнять, например, длины проводников в группе), и никто даже не пытается этим заниматься, видимо тоже отпугивает сложность задачи.

А такая открытая видеокарта не тоже самое

Тоже открытая, но на этом сходство кончается.

НАверное и опенгл работает там

Не работает. Они до OpenGL не дошли.

вроде старый проект

Да, старый. Где-то с 2004 года работали. В 2010 году осилили, наконец, выпустить PCI-карты с видеовыходом и ПЛИС, которые могли бы программировать все желающие, после чего всякая активность на сайте прекратилась.

Вот тут подробнее обо всех проблемах проекта: http://en.wikipedia.org/wiki/Talk:Open_Graphics_Project#is_it_dead.3F.3F

Формальный критерий в языке программирования высокого уровня. Компилятор оптимизирует программу не нарушая прямо то что написано явно. Места где компилятор может переставить инструкции, например, четко определены стандартом (С++). Не нарушая спецификаций компилятор может делать все что угодно.

Язык С, например, определяется в стандарте в терминах абстрактной машины. Как он будет преобразован в целевой язык, стандарт не специфицирует, важно только то, чтобы результат выполнения исходной программы на абстрактной машине совпадал с результатом выполнения продукта компиляции на целевой машине. Замечу, что нигде (по крайней мере я не нашёл, если кто укажет пункт в стандарте, готов признать свою неправоту) даже не требуется, чтобы результат компиляции имел одинаковую асимптотическую сложность на всех целевых машинах, в качестве примера могу предложить рассмотреть регистровую машину с произвольным доступом к памяти и машину с памятью в виде ленты, типа машины Тьюринга. В последнем случае выборка значения ячейки памяти по адресу n будет O(n), а в первом случае O(1). Поэтому, если речь идет, например о функции сортировки без побочных эффектов, то компилятор имеет полное право заменить алгоритм сортировки на любой другой, который выдает те же результаты, что и исходный.

Очень классно, если это путь к открытой графической карте.

главное чтобы не бросили! ,если денег надо - сделали проект на кикстартере,, объеденились с другими опенсорс разрабами, Столманом, китайцами

Кстати Столман в курсе?

Им нечего бросать. Напишут они свой диплом, добрая фирма примет их на работу, разработку закроют, и будут они проектировать закрытую графику для встраиваемых систем. Черта с два будет там открытая видеокарта.

Частота современного жефорса - 900mhz. Разница всего в 18 раз. Так что не в частоте дело :)

Да, дело не только в частоте. У современных видеокарт куча конвееров, работающих одновременно.

В стандарте естраь понятия точки синхронизации. Это моменты, когда состояние машины в точности соответствует тому, что представляет в голове программист. Асимптотическая же сложность считается в абстрактных инструкциях, например присваивание, получение данных из памяти и арифметические операции.

С тем же успехом его можно скомпилировать в маски для изготовления микросхемы.

Одним движением руки? Под какой процесс?

Если при этом возникнут какие-то проблемы, это вина корявого компилятора производителя чипов, а не HDL-описания.

Да, да, да... Именно компилятор во всём виноват.

За ORSoC будущее как и за линукс. Невероятные возможности открываются для тех кто в теме. Открытые архитектуры всегда будут лучше закрытых. Просто этот проект совсем еще молодой(старт дан в 2001), но в последнее время развивается по экспоненте.

Как можно говорить об открытости железа, если в итоге получаются проприетарные FPGA?

Это может быти и ASIC. Исходники то открыты. Сам можешь сделать netlist(на вполне свободных программах) и по твоему заказу тебе изготовят «непроприетарных» микросхем. Чего непонятно?

В стандарте естраь понятия точки синхронизации. Это моменты, когда состояние машины в точности соответствует тому, что представляет в голове программист.

Это понятие (sequence point) введено для описания семантики абстрактной машины как таковой, сгенерированный компилятором код не обязан полностью следовать семантике абстрактной машины внутри одной единицы трансляции:

5.1.2.3 Program execution

1 The semantic descriptions in this International Standard describe the behavior of an
  abstract machine in which _issues of optimization are irrelevant_.

9 Alternatively, an implementation might perform various optimizations within each translation unit, such
  that the actual semantics would agree with the abstract semantics only when making function calls across
  translation unit boundaries. In such an implementation, at the time of each function entry and function
  return where the calling function and the called function are in different translation units, the values of all
  externally linked objects and of all objects accessible via pointers therein would agree with the abstract
  semantics. Furthermore, at the time of each such function entry the values of the parameters of the called
  function and of all objects accessible via pointers therein would agree with the abstract semantics. In this
  type of implementation, objects referred to by interrupt service routines activated by the signal function
  would require explicit specification of volatile storage, as well as other implementation-defined
  restrictions.

Асимптотическая же сложность считается в абстрактных инструкциях, например присваивание, получение данных из памяти и арифметические операции.

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

Собирают на выпуск дешевой ASIC для народа. Все, кому надо здесь и сейчас, уже и так сами и на FPGA и в ASIC OR1200 клепают.

Я думал, что для FPGA нужно писать специфичный код.

Для FPGA нужно писать специфичный код. Но OR1200 достаточно переносимый и от фичей конкретных FPGA не зависит. Препроцессор в verilog вполне годный.

А ты случайно сам не пробовал заводить OR1200 на плисине?

Мсье тупой? До сих пор из юзабельных открытых движков был только MilkyMist One, а теперь их как минимум два.

Пробовал, гоняю orpsocv2 на Atlys.

Скажи. Сколько существует живых и активных проектов по созданию открыто-свободного 3D-ускорителя?

Только MilkyMist One, но там от 3D куцый огрызок, и исправлять это они не собираются.

Xilinx - жаль. А то я чегой-то adv_debug на альтере завести не могу.

Почему нельзя реализовать OpenCL для него

Полноценная реализация OpenCL - на пару порядков сложнее чем железка, которая потянет полноценно OpenGL ES. Одна только иерархия памяти чего стоит (private/local/global/constant).

Код на HDL достаточно высокоуровневый. Разумеется, непосредственно перед синтезом можно какие-нибудь мелочи подоптимизировать под конкретный компилятор.

Недостаточно. Как минимум для разных FPGA надо подгонять размеры используемых block memory. Есть и сильно высокоуровневые фичи, которые компилятор не распознает (те же DSP cores).

А то что на видео это его максимальная скорость / возможности ?

Скорость зависит от железа, на котором это дело реализуешь. Virtex7 был бы в разы шустрее, ASIC на 22нм вообще на порядки. Пока в память не упрешься, естественно.

MilkyMist One

Спасибо за информацию. Но это устройство не очень похоже на дискретную видеокарту :)

но там от 3D куцый огрызок, и исправлять это они не собираются.

Значит с точки зрения создания свободной замены Нвидии этот проект тоже неактивен :(

А то что на видео это его максимальная скорость / возможности ?

Нет. Перечитай всю тему :) Авторы обещают выложить видео, из которого можно оценить предельную скорость, когда допишут магистерскую.

И да, на обещанном видео будет скорость на 50 МГц ASIC. То есть реализация в железе (если сделают) будет на частоте на порядок выше.

Асимптотическая сложность сгенерированного кода - понятие бессмысленное совершенно. Там уже нужно считать абсолютную сложность в тактах для конечных объемов данных.

То что компилятор не превращает пузырек в быструю сортировку (и скорее всего никогда не будет превращать) имеет свои причины: быстрая сортировка требует больше памяти, пузырек обычно пишется стабильным, а большинство быстрых сортировок нестабильны. Тем не менее, компиляторы умеют сворачивать циклы в SIMD инструкции.

Как можно говорить об открытости железа, если в итоге получаются проприетарные FPGA?

Ага. И как можно вообще делать открытое железо, если фабрики проприетарны, оборудование проприетарно, и деньги за компоненты и труд платятся через зверски проприетарные банковские системы? Ужас и печаль.

Недавно был небольшой шум про незакрытый JTAG в военных FPGA. Так что проблема реально есть. Для софта создана полностью свободная инфраструктура (инструменты, компиляторы, ядро), и она замкнутая (gcc собирается gcc, все остальное им)

Асимптотическая сложность сгенерированного кода - понятие бессмысленное совершенно.

Почему? Чем так выделяется абстрактная машина x86_64, например, среди множества других абстрактных машин? После того как компилятор изготовил программу на целевом языке, к этой программе можно применять точно такие же методы анализа, как и к любой другой.

Насчет пузырька согласен, конечно, это был просто пример. Этот пример кстати показывает, что у компилятора в общем случае нет всей информации для выполнения хорошей оптимизации (в данном случае отсутствует информация о типичных входных данных), поэтому еще долго будет оставаться необходимость ручной оптимизации программ (там где это оправданно, естественно).

компиляторы умеют сворачивать циклы в SIMD инструкции.

Уметь то они умеют, вот только результат сильно зависит от конкретного цикла, чтобы цикл эффективно свернулся, он должен быть написан определенным образом, причем нет никаких гарантий, что на другом компиляторе он тоже эффективно свернется. Так что пока я предпочитаю писать SIMD для критичных мест руками на ассемблере, да и не только я.

Асимптотическая сложность сгенерированного кода - понятие бессмысленное совершенно. Там уже нужно считать абсолютную сложность в тактах для конечных объемов данных.

Кажется понял, что ты имеешь ввиду: конечный объем памяти. Так что да, вообщем-то понятие в этом случае действительно бессмысленное. Хотя и в абстрактной машине С объем памяти тоже конечен, просто стандартом не фиксируется.

Реальную программу можно запустить и посчитать такты. Кроме того, «асимптотическая» означает при n->бесконечности. Когда отсортируешь бесконечный массив пузырьком, отпишись о результатах.

Для оптимизатора главное не оптимизировать, а не насажать новых багов. Пару раз натыкался на баги компилятора в msvs, их отвратительно сложно искать.

А какая ЦА у этого ускорителя ? Реальное применение или для гиков ?

embedded, где высокой производительности не надо, но разгрузить основное ядро от задач вывода на экран не помешает.

Для SoC на FPGA, например. Реальней некуда.

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

формальный критерий различия алгоритмов? Наздоровье: время выполнения в O(f(размер входных данных)) форме.

А оптимизированная программа это та, что меняет время исполнения алгоритма в пределах o(f(размер входных данных)), то есть не меняет класс эквивалентности.

А если ты напишешь компилятор, который меняет класс эквивалентности, то тебе нобе^W пулю дадут.

В последнем случае выборка значения ячейки памяти по адресу n будет O(n), а в первом случае O(1).

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

могу предложить рассмотреть регистровую машину с произвольным доступом к памяти и машину с памятью в виде ленты, типа машины Тьюринга. В последнем случае выборка значения ячейки памяти по адресу n будет O(n), а в первом случае O(1). Поэтому, если речь идет, например о функции сортировки без побочных эффектов, то компилятор имеет полное право заменить алгоритм сортировки на любой другой, который выдает те же результаты, что и исходный.

то есть ты предлагаешь сделать компилятор, который заранее распознает алгоритм переписывает код? Не надо нам такого. Это никому не нужно, а даже вредно.

Частота чипа - 50mhz. Чтобы было быстрее - нужно реализовать «в железа», а не на FPGA.

Частота чипа на Spectrum-48 была 3,5MHz. И этого хватает не только чтобы трехмер обсчитывать, но и игровую логику реализовывать.

А тут что?

а только с примитивами которые есть в конкретной FPGA

Для этого надо хотя бы знать эти примитивы и основные ограничения на их применение (количество, примерные возможные соединения). Эта информация у Xilinx частично открыта/расхакана, у остальных закрыта полностью.

Кстати заметил еще одну вещь: несмотря на наличие свободного софта для трассировки pcb (gEDA,KiCAD), нигде нет нормального автотрассировщика с констрейнтами (чтобы выровнять, например, длины проводников в группе), и никто даже не пытается этим заниматься, видимо тоже отпугивает сложность задачи.

Не сложность. Как это делать, многие (в т.ч. я) знают. Нет серьезного практического применения. Производства дешевых плат такого класса под любительские цели не существует. Некуда потом использовать. А серьезного любителя не напрягает купить хотя бы Eagle, а то и студенческую версию чего побольше.

Коммерческие автотрассировщики для любительских целей работают часто очень плохо. Любители из экономии (или для ЛУТ, или для ручной пайки) делают точность пониже, дорожки пошире, вот тут вот автороутер и захлебывается.

то есть ты предлагаешь сделать компилятор, который заранее распознает алгоритм переписывает код? Не надо нам такого. Это никому не нужно, а даже вредно.

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

Если программисту нужно повлиять на компилятор, для этого существуют атрибуты. Можно явно зафиксировать некоторые специальные параметры, например привязку переменных к регистрам или памяти, обращение к функции через call (без инлайна) и т.д.

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

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

Да и не надо это. Компилятор оптимизирует лишь в пределах класса эквивалентности, в лучшем случае.

А если ты напишешь компилятор, который меняет класс эквивалентности, то тебе нобе^W пулю дадут.

Вот не надо тут ля-ля разводить. Почти все компиляторы делают loop fusion, например.

который заранее распознает алгоритм переписывает код?

А всякие там polyhedral optimisations что делают, по твоему?