Просмотр полной версии : Многопроцессорная графическая плата ДВК
Предлагаю уважаемым любителям советского PDP-11 высказать свое мнение о варианте графической платы ДВК с кучей ( ~8 шт. ) вычислительных ядер на ВМ2, под управлением общего ВМ3.
Каждое графическое ядро имеет свое ГОЗУ, сканируемое одновременно с 7-ю другими др. ядрами на видеовывод.
Приоритет ( очередь ) видеовывода ( слоёв графики ) определяется программно.
Например, 1-е ядро управляет текстом, 2-е ядро - машинкой игрока, 3-4 ядра - машинками конкурентов, 5 и 6 ядра - рисуют графитаж обочины шоссе, 7 - управляет облаками, 8 - скроллит саму дорогу - приблизительный вариант для игры "ралли".
Примерный размер ГОЗУ каждого ядра - 640х256х2 бит ( 40 кбайт ), отдельные палитры. И еще 20 кбайт ( на 1 шт. ядро ) для кода, может еще и ЭД какой-нибуть.
На АП ВМ3 каждое ядро сидит как участок общего ОЗУ и доступом по ПДП ( к ОЗУ ядра ) к каждому ядру.
Т.е. для сложных игр общее быстродействие может даже складываться - например, до 8 млн рег-рег. при 1 млн рег-рег для 1 шт. ядра.
такое в zx-poly реализовано на 4х ядрах, вроде как теоретическое вскрытие показывает что подход работает
Вопросов, как обычно, три
- Сколько будет стоить
- Кто это сделает
- Кто под это будет писать (игрухи)
И если что - это риторические вопросы, потому что ответы на них я уже знаю
А про zx-poly - в железе оно уже е? Если нет (эмуляторы не в счёт) - тогда "подход работает" остаётся теоретическим мнением.
CodeMaster
11.04.2019, 07:45
Предлагаю уважаемым любителям советского PDP-11 высказать свое мнение о варианте графической платы ДВК с кучей ( ~8 шт. ) вычислительных ядер на ВМ2, под управлением общего ВМ3.
Это даже не мнение, просто стандартный вопрос: кто будет писать софт?
- - - Добавлено - - -
Hunta, опередил, пока я пошёл чайку налить ;-)
А про zx-poly - в железе оно уже е? Если нет
Железо сейчас уже ничего не решает, только софт.
А про zx-poly - в железе оно уже е? Если нет (эмуляторы не в счёт) - тогда "подход работает" остаётся теоретическим мнением.
нет, так как в железе экономически это было невыгодно делать еще в середине 90-х, что мне и сказал тогда Сергей Зонов который знает толк в деле, я не вижу проблем с эмуляторами, как не вижу проблем когда сейчас многие более сложные и ответственные вещи прогоняют на компах в "виртуальном режиме"
так как в железе экономически это было невыгодно делать
я не вижу проблем с эмуляторами
Основная проблема - программа (а эмулятор - это программа) - это ВСЕГДА последовательное выполнение действий. Даже если у вас многопоточное приложение и несколько процессоров в системе - нельзя записать в одну и ту же ячейку памяти ОДНОВРЕМЕННО данные двумя процессорами - сначала запишет один, потом другой. А железное решение - это ВСЕГДА параллельные действия. И что бы достичь последовательных действий (или часто используют термин - синхронный дизайн) - нужно предпринять определённые усилия. И записать в параллель (по И, ИЛИ или исключающему ИЛИ) данные в одну и ту же ячейку памяти со стороны двух процессоров (на железном уровне) - раз плюнуть. Скажем, в МПИ или QBUS это будет ИЛИ. И что бы не происходило ТАК - реализуются СХЕМНЫЕ решения. Раз до вас это дело не доходит и вы "не видите проблем" - флаг в руки. И попробуйте создать железный zx-poly хотя бы для себя, любимого. Тогда и продолжим разговор
Железо сейчас уже ничего не решает, только софт.
Я немножко про другое - про потенциальную реализуемость в железе. Ибо если его в железе реализовать нельзя или оно будет стоит "бешеных" бабок для основной группы потенциальных пользователей (фанаты и хоббисты не счёт, я скажем, на свои PDP-шные хобби потратил уже, по приблизительным подсчётам под шесть-семь штук и планирую ещё под пару штук) - до софта дело не дойдёт.
просто стандартный вопрос: кто будет писать софт?
Шоб писать софт - уже нужна железка
- - - Добавлено - - -
Hunta, опередил
"Но Кристобаль Хозевич успел раньше. Он любил успевать раньше — всегда и во всем." ;)
Основная проблема - программа (а эмулятор - это программа) - это ВСЕГДА последовательное выполнение действий.
как раз на уровне эмулятора это вполне неплохо эмулируется просто случайным изменением последовательности работы с памятью процессоров на каждом шаге, тут главное иметь качественный эмулятор процессора с чуть ли не потактовой эмуляцией, я на это прилично сил потратил
с чуть ли не потактовой эмуляцией
случайным изменением последовательности работы с памятью процессоров
Не спасёт. И раз вы этого не понимаете - ещё раз - сделаете рабочий железный вариант - тогда и поговорим. Уж для себя то, любимого, можно сделать ;) До этого момента - на эту тему - более не беспокою
Не спасёт. И раз вы этого не понимаете - ещё раз
через 22 года разработки, могу сказать что вполне спасает, если тот кто делает конечно программировать и проектировать умеет, если этого не понимаете, то не поймете
Тут бешеный объём работы... По аппаратной части, нужен целый коллектив специалистов. И цена вопроса, не, ежели спонсор найдётся - сделать можно ;)
Но ведь не найдётся :(
И потом проблема с софтом... Уж с софтом на КЦГД дефицит был, пока у народа разошлось да понаписалось... Там ДВК + КЦГД заменили РС-совместимые.
А уж на такого зверя писать...
Если про любительское творчество - то увы, не реально...
Даже на уровне эмулятора - эмуляции той же КЦГД нормальной нет :-(, а уж такую зверушку...
Нет эмуляции КЦГД, так как софта очень мало и было, а осталось ещё менее :-(
Вот на УКНЦ - эмулятор сделан, но там изначально графического софта сильно более было, смысл был.
через 22 года разработки
Железку в студию
- - - Добавлено - - -
По аппаратной части, нужен целый коллектив специалистов
Фигня. Как раз по аппаратной части не сильно много работы, ибо топикстартёр хочет переложить всё на программную часть. И вот в ней то и начнутся проблемы. Ибо любителей полно, а способных реализовать такое без особой аппаратной (не вижу я её в описании) поддержки - нету.
А со стороны аппаратной основная проблема - как все это (учитывая любовь топикстартёра к рассыпухе) разместить на одной, даже полной плате. Ну или загонять всю рассыпуху в FPGA. Но как то специалистов, могущих такое поднять в FPGA - не наблюдается. Не, может они конечно есть - но успешно шифруются.
В общем, очередной проект из разряда - а давайте забабахаем хрень.
Мне почему-то кажется, что запихнуть всё в FPGA будет проще, чем разрабатывать на куче корпусов низкой интеграции.
Ведь полуплата на ВМ3 с FPGA тут же была представлена, да как я понял - даже рабочая :-)
Проблема только в разработке самой схемы, да составления внятного описания для писателей софта. С этим не важнец :(
Проще какой-то чип VGA. типа Trident 9000 на шину МПИ посадить. Там есть функции блочной пересылки. Результат был бы интереснее.
Лучше вообще шлюз ISA/QBUS сделать, тогда не только видео, а куча прочей периферии станет доступна :-)
Там логику преобразования сигналов шин в FPGA, да драйвера шин. Если постараться, то и DMA и прерывания работать будут. И память будет отображаться в адресном пространстве QBUS(те же видео, звук) :-)
И с софтом сильно проще будет. Примеры уже написанного в сети доступны, правда под х86. Но если есть пример перед глазами, то писать всё сильно легче :-)
Затраты на реализацию сильно менее. А пользы сильно боле :)
Мне почему-то кажется, что запихнуть всё в FPGA будет проще, чем разрабатывать на куче корпусов низкой интеграции.
Мне тоже это кажется, но нужен человек, умеющий работать с FPGA
Ведь полуплата на ВМ3 с FPGA тут же была представлена, да как я понял - даже рабочая
Она не только рабочая, но уже есть (и вроде как тоже рабочая) её вторая версия, где микросхем меньше, а функционала больше.
Проблема только в разработке самой схемы, да составления внятного описания для писателей софта
На самом деле плата в том виде, как описана, ничего не решает ни в плане быстродействия, ни в плане простоты написания софта, ибо пока концепция выглядит как - а давайте соединим 8 процов в некое единое подобие целого, а потом кто-то (программер) заставит ((с) анекдот) всю эту хрень взлететь. Учитывая, что доступных ресурсов (читай - памяти в первую очередь) на вм2 МАЛО (по описанию на момент написания этих строк - 20 кб) - код на ВМ2 должен быть ВЫСОКООПТИМАЛЬНЫМ, а значит все возникающие проблемы общения между участниками НУЖНО решать железом или, возможно, этим будет заниматься ВМ3 - а значит - надо или продумывать железо или найти грамотного программера, который разрулит это дело на ВМ3. В загашнике такой спец-альтруист е? Я пока не вижу (даже я не потяну, несмотря на то, что я ОЧЕНЬ неплохо знаю программирование на PDP-11 - там придётся разруливать железные косяки)
Проще какой-то чип VGA. типа Trident 9000 на шину МПИ посадить
Хорошее описание этого чипа есть? Если нет - те же яйца, вид сбоку - у меня временами впечатление, что народ (из PDP-шников в первую очередь), который бы смог разобраться сам в железке по невнятному описанию и дизассмеблированному биосу - без воплей - КТО ПОДСКАЖЕТ???? каждые пять минут - вымер как класс. И что то мне подсказывает, если внятно описание есть - мы вполне налетим на вторую проблему - "мля... оно же по английски.."
Разобраться-то можно с FPGA, но изначально нужны люди кои смогут разработать с нуля эту схему хотя бы в электронном виде. С этим, как я понимаю ещё хуже :-( Ежели таковые найдутся, то FPGA это технические детали...
По поводу полуплаты...
Ну прогресс не стоит на месте. Мои поздравления разработчику! Дело хорошее и нужное.
По поводу описаний на английском, так ведь большая часть документации именно на PDP-11 на английском :-)
Люди есть... Но их очень мало :-(
Если есть возможность как-то сделать большой шаг вперёд, так это только полнокровный мост ISA/QBUS...
Документация есть на много чего из периферии...
Закройте уже "весенне-осеннюю" тему.
По конструктиву - для 4СПП это всё-таки 2-платная реализация - на 1-й плате - ВМ3 и сканер видео-адресов, блок палитр и приоритетов, а так же собственно выход на моник + 2 узла на ВМ2. На 2-ю плату через плоский кабель передаются адреса МПИ ВМ3 и адреса сканов ГОЗУ, а так же идут цифровые выходы у узлов на ВМ2.
Несложно , кстати , нарастить к-во узлов ВМ2 до ~16 шт, по 128 кбайт СОЗУ на 1 узел.
*
Да, конечно, без софта это просто набор ИС.
... и цена улетает в стратосферу...
fpga сразу убивает весь интерес к такому монстру, потому что даже самая минимальная fpga способна будет обогнать по скорости БЕЗ всяких дополнительных процессоров снаружи любого реального монстра на рассыпухе с частотами до 10mhz... так что fpga тут вообще негодится (разве что для стадии проектирования)
данный монстр сильно жЫрный, поменьше и посложнее надо шото - на РТ2 автомат в стиле ПК8002 Эльф... да врубить его к ВМ3! вот это МЕЧТА! под нее будет грех не писать игрушки
данный монстр сильно жЫрный, поменьше и посложнее надо шото
Да флаг в руки - но воз и ныне там.
А тем временем
http://www.KpXX.Ru/KBAHT4C/Железо/Полуплата
Класс! :v2_clapp: я про полуплату :)
Alex, версия два (кодовое имя МС 1201.2018) едет ко мне - для тестирования и написания драйверов для CF (по крайне мере для RT и RSX). Ну и возможно загрузчик будет изменён - я всё ещё в раздумьях, как сделать разбиение CF карты на части - и что бы гибко было - то есть - хочешь целиком карта - один раздел, хочешь - разбита на части. А тем временем в планах у автора платы - начать сборку плат на продажу :)
Как заместитель кое-где ещё работающих наших клонов PDP-11, возможно пойдёт. Хотя таковых мест становится всё менее и менее.
Возможно, что и часть любителей истории проявит интерес. Вопрос в цене...
Из интересного подвернулось, J-11 аж на шине S-100:
http://www.s100computers.com/My%20System%20Pages/PDP11%20Board/PDP11%20Board.htm
Там на сайте есть множество других интересностей :)
Ну, по крайне мере пока, это делается как замена МС 1201.03-04 для тех любителей PDP-11, у кого есть куда такие платы воткнуть, но, возможно, нет самих плат или они их не устраивают по некоторым параметрам :)
И поскольку здесь тема немного про другое, и поскольку я открыл тему по второй редакции платы, то ... :)
Да флаг в руки - но воз и ныне там.
А тем временем
http://www.KpXX.Ru/KBAHT4C/Железо/Полуплата
проц давно есть (старый, мс1201.03) с видяхой проблема
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot