Лидеры

Для теста видеобуферов набросал максимально упрощенный рендерер для майноськи. Без поддержки изображений, прозрачности и транзиций - оставил лишь суровые прямоугольники и цветной текст: Плюсы: расход RAM упал до 25% на полностью инициализированную систему с загруженными (но не отрисованными) иконками. Для слабых машин это очень хороший показатель, и освободившиеся ресурсы можно было бы направить на прикладной многозадачный софт. Минусы: оно лагает сильнее, чем софтверное решение с графоном!11 Но, будем честны, я натягиваю сову на глобус. Концептуально фича крайне сочная, API удобное и не ломает старые проекты, написанные под прямую работу с GPU. Думаю, она будет идеальным решением для узкозадачных юишных софтин типа мониторилок реакторов, кнопочных контроллеров для умного дома, текстовых чатов или рисовалок - иными словами, для всего, что могло слегка подлагивать из-за прямой отрисовки. И если раньше надо было извращаться с порядком операций, экономя каждый тик, то теперь можно кодить гораздо комфортнее. Хотя мне все равно чуточку обидно. Но лишь чуточку.

Думаю Сделать Свою новую ОС На основе моей настоящей только она на виндовс 98 а эта будет типо того же только Для Опен Компьютерс Пока Идёт Разработка ядра В планах GUI оболочка Редакторы и магазин приложений https://github.com/daniilfigasystems/FigaOS Первая АльФа Уже доступна!

PRERELEASE система вышла из бета, и вошла в пререлиз, убедильная просьба, все кому не лень хорошо протестировать likeOS и liked, о багах и ошибках репортить в тему, в лс тоже можно, то тогда другим людям не будет что почитать)) так что лучше в тему создания прошивки для робота на ядре likeOS скачиваем файлы likeOS добавляем файл main.lua(это будет основной файл прошивки) так же можно добавить файл реестра по умолчанию(например на случай, если нужно запретить работу recovery) /system/registry.dat так же можно добавить свой логотип, который будет отображаться при загрузке и printText, для этого скопируйте файл /system/core/logo.lua в /system/logo.lua и отредактируйте его как вашей душе угодно выводить состояния можно методом printText, если нужен более продвинутый режим, то используйте api graphic для понимания масштабов PRERELEASE чекаем коммиты: https://github.com/igorkll/likeOS https://github.com/igorkll/liked фишки ос оболочка отдельно от ядра ос, вы можете поставить только ядро и добавить туда автозагрузочный скрипт, а можете поставить дистрибутив liked много поточность мульти мониторность(относиться скорее к дистрибутиву liked) очень малый расход оперативной памяти, зачёт того что многие функции операционной системе лежит на hdd и подгружаться только в момент использования оптимизированные функции getDeviceInfo и getKeyboards(потому что ос использует их очень часто) авто выгрузка некоторых библиотек liked сможет работать на планке t2,5 даже с двумя мониторами этот gui дистрибутив который использует api graphic ядра для работы с графикой в liked предусмотрен dev mode для создания собственных приложений, для его активации задержите стрелку вверх в магазине liked есть irc клиент! как работает мульти мониторность дистрибутив liked выводит рабочий стол только на мониторы начиная с уровня 2 на разным мониторах ос будет работать почти как разным компьютеры для работы не требуется несколько видео карт, хотя это желательно вы сможете запустить разные программы на разных мониторах ос сама разберётся какую gpu к какому монитору подключить, и когда подбиньдить отличия dev mode от user mode dev mode при переименовании файла расширения не переходит от пред идущего при создании текстового файла ему автоматически не присваивается расширения txt вы можете присвоить расширения папке вы можете указать расширения при переименовании файла вы получаете доступ к корню диска вы получаете возможность заходит внутрь пакетных приложений вы получаете возможность редактировать lua скрипты user mode вы не можете указывать расширения сами, оно везде присваивается автоматически при переименовании расширения переходит от старого имени вы не можете изменить расширения установка ос: для начала необходимо создать установочную дискету, запустив команду wget https://raw.githubusercontent.com/igorkll/likeOS/main/installer/openOS.lua /tmp/asd -f && /tmp/asd в openOS затем необходимо загрузиться с дискеты на том устройстве на которое желаете поставить likeOS - liked так же вы можете загрузиться туда через улититу install обычный openOS, просто установить дискету как обычную, но вместо установки компьютер после выбора дискеты туда загрузиться выберите online mode/offline mode(первый загружает ос из интернета, второй с самой дискеты) выберите дистрибутив(liked это графический дистрибутив, core only это чистая likeOS которая нечего не выведет на монитор а просто крашнеться с ошибкой computer halted) выберите диск согласитесь подождите ос установлена предупреждения внимания подгруздка библиотеки thread может привести в увеличению расхода энергии! у ос очень большое потребления энергии в целом, планшет высаживает на щитаные минуты рекомендации liked на скорость рендера, очень сильно влеяет уровень процессора, и видеокарты, но не монитора, по этому по возможности лучще будет установить видеокарту t3 даже в планшет/компьютер с вторым монитором, и процессор t3 фишки дистрибутива liked возможность поставить иконку на любую папку(создайте картинку с именем icon) смена обоев рабочего стола смена цветовой палитры монитора показ реального времени в углу в планах сеть библиотека likenet создана программа для перебрасывания файлов и папок между устройствами (частично реализовано в виде программы чат) проверка на вмешательства в системные файлы возможность поставить обои отдельно для конкретной папки клиент для ocelot online структура файловой системы /init.lua - инициализационный файл, скоро будет содержать recovery menu для восстановления любого устройства с likeOS на основе(если recovery menu не будет отключено в реестре(реестр скоро будет добавлен)) /system - файлы дистрибутива /system/core - файлы ядра /system/autoruns - автозагрузка дистрибутива(для скриптов не требующих взаимодействия) /system/main.lua - тоже автозагрузка, но предназначена для программ выполняемых в бесконечном цикле /systen/bin - программы дистрибутива /system/lib - библиотеки дистрибутива /system/calls - hdd функции дистрибутива /system/core/boot,lua - загрузчик ос структура _ENV(может быть сложно для понимания новичкам, сложно для понимания новичкам, читать не обязательно) _ENV в большинстве ситуаций личная, а _G общая, исключения hdd функции в которых _ENV и _G это одна таблица, и так же исключениям является рабочий стол liked который делит _ENV между рабочими столами на разных мониторах соответственно глобалы созданные таким образом (value = 2) будут личными, а таким (_G.value = 2) общими функция printText функцию не будет работать если в реестре есть ключ disableLogo! данная функцию выводит строчку на экран c использования логотипа ос выводит изображения на все подключённые мониторы, однако использует не api graphic а прямую запись в мониторы функцию выполняется долго, так как "рисует" одной видеокартой функция НЕ будет работать если вы переконфигурируете графическую системму идеально подойдёт для вывода состояния устройства прошивка которого создана на базе likeOS core реестер: нужен для быстрого сохранения хранения параметров на жесткий диск, которые в последствии смогут быть использованы в других программах или же самой ос например добавив ключ реестра disableRecovery вы отключите возможность войти в recovery, а кличем disableLogo запретите работать функции printText редактирования реестра осуществляется с использования библиотеки ядра registry, самый простой способ использования, это использовать ее как таблицу и писать значения прямо в таблицу библиотеки, а она сама запишет это на жесткий диск RECOVERY MENU это меню есть в ядре likeOS в следствии чего его можно будет использовать почьти во всех дистрибутивах для входа в меню нужно нажать R при старте это меню можно отключить добавив в реестер(lua табличка на жестком диске(/data/registry.dat)) пару ключ значения (disableRecovery = true) в нем можно стереть данные прошить afpx архив(главное чтоб он лежал не на сис. диске и имел расширения afpx) запустить lua script, api из opencomputers + gpu. заранее сконфигурированная уже лежит в _ENV посмотреть логи системы документация(пока что не полная): api calls calls.call - вызов функции лежащей на hdd calls.load - погрузка функции лежачих на hdd calls.loaded - кеш функций, сам не заполняется, но может быть использован в некоторых случаях calls.paths - таблица с путями по которым идет погрузка api package _G.require - подключить библиотеку package.loaded - кеш библиотек package.paths - тиблица с путями по которым идет подгрузка библиотек api graphic graphic.findGpu(screen) - ишет gpu для нужного экрана и подкючает ее, искать gpu нужно заного после кажного прерывания, так как она может быть "украдена" graphic.createWindow(screen, x, y, sizeX, sizeY):windown- создает НЕ буферизированое окно на нужном экране window:clear(color) - залить окно нужным цветов window:write(str) - запись данных в окно window:read(x, y, sizeX, background, foreground, preStr, crypto) - стения данных из окна, если ввод был отменен вернет true window:uploadEvent(eventData:table):eventData:table - загружает event в окно и возврашает измененный ответ или nil window:set(x, y, background, foreground, data) - записать строку window:fill(x, y, sizeX, sizeY, background, foreground, char) - заливка window:copy(x, y, sizeX, sizeY, offsetX, offsetY) -- копирует участок окна window:setCursor/window:getCursor тоже есть, и управляют функцией write все цвета нужно брать из таблицы gui_container.colors иначе их поведения будет неправильным(актуально для liked(gui_container это главная системная библиотека liked)) интерфейс liked

Урааа починил! нужно было файл конфигурации удалить!!!!

В том и дело, что они оверхед этот не имитируют. Там нет никаких преобразований, упаковок и распаковок. Эти функции напрямую работают со стэком значений, не трансформируя что-либо. Слоёв абстракции сильно меньше. Только методы компонентов — из-за общности интерфейса: как со стороны луа, который позволяет передать любые значения и получить любые значения при вызове любого метода любого компонента, так и со стороны скалы, где трансформируются значения, — влекут за собой проход сквозь кучу обёрток, которые сильно роняют производительность. И только их оверхед я считаю существенным. Я вставил дебаг-принты в оцелота в том месте, где изменяется значение оставшегося бюджета вызовов. Каждый get занял 4.656612875245797×10-10 единиц. Это как раз 2-31. Даже миллиард таких вызовов не могут израсходовать бюджет настолько, чтобы компьютер прилёг на один тик. Бюджет — это же просто чиселка, которая уменьшается при каждом прямом вызове и регенится после каждого yield. Какой-либо эффект оно оказывает, только если уменьшается до нуля. При этом во время работы 16к вызовов ниже 1.499999 он даже не опускался. Однако потребление процессорного времени во время прокрутки цикла с 16к гетами стопроцентное.

Я и не утверждал обратного, это уже какая-то нездоровая полемика. Проясню: 1) Я продемонстрировал, что комп умирает на несколько сек при обращении к gpu.get, предположив, что обращение к ненулевому буферу ни разу не бесплатное 2) Ты сообщил, что доминирует некий оверхед, а расход бюджета при обращении к ненулевому буферу должен быть 2-31 3) Я ответил, что значение в 2-31 слишком мало, и бюджета после 16к вызовов должно оставаться с запасом, и проблема явно в другом месте 4) Ты пояснил, что имел в виду под оверхедом, упомянув нативные либы, интерфейс Lua <> Scala и сам бюджет вызовов 5) Я не согласился, приведя пример с 16к вызовами unicode и computer, имитирующими оверхед без расхода бюджета, и работающий незаметно с точки зрения производительности. Поскольку из примера был исключен лишь расход бюджета, а работа нативных либ и прокидывания данных через Lua <> Scala сохранены, я сделал вывод, что к тормозам приводит именно бюджет Разве это не подтверждает тезис о том, что gpu.get кушает сильно больше 2-31 бюджета? Может быть, каждый вызов прямого метода компонента расходует некое константное кол-во бюджета в дополнение к прописанному в @Callback значению?

unicode.sub и computer.uptime — это не методы компонентов, а функции, которые практически напрямую дёргают методы луа и потому несравнимо дешевле. Сравнение нечестное. Проверил в оцелоте: 16к вызовов gpu.get заняли 0.80 секунд (avg 50 μs / call), а столько же computer.uptime — 0.04 (avg 2.5 μs / call). Такое же число вызовов методов других компонентов также занимают около 0.8 секунд. Потребление бюджета вызовов при этом остаётся околонулевое.

Я тоже как раз про него и говорил. И по-прежнему не соглашусь. Заменяешь тело функции throttle из примера выше на любой код уровня Lua ↔ Scala типа unicode.sub("abcdef", 1, 2) или computer.uptime(), вызываешь его 160 * 50 * 2 раз перед выводом графики на экран через bitblt - и ничего не изменится. С позиции наблюдателя никаких микро-задержек не будет, bitblt отработает так же, как и без искусственного замедления, потому что, как ты сам подметил, bitblt скушает в сотни (если не тысячи) раз больше бюджета. А теперь вставляем 16к вызовов gpu.get на ненулевой буфер и наслаждаемся мертвым компом. Поэтому смею предположить, что реальный бюджет обращения GPU к ненулевому буферу сильно значимее 2-32, и практический эксперимент это подтверждает Чекнул, ловлю рантаймовую оплеуху. В кубаче работает, так что фиг с ним

Честно говоря, не очень понял, что имеется в виду. Поэтому на всякий случай проясню, что имел в виду я. Если замена in-Lua буферов на VRAM привнесла задержки на порядок, то виноват, скорее всего, некто из следующих элементов: Lua. Нативные либы собраны с -O0.... и заметно тормозны. Сюда же пойдёт хук для TLWY. Оверхед из-за интерфейса Lua ↔ Scala (об этом ниже). Бюджет вызовов, который могут потреблять прямые вызовы get на ненулевой буфер. Каждый прямой вызов, даже если он бесплатный (а он должен быть практически бесплатным, если активен ненулевой буфер), проходит через слой Lua ↔ Scala. Это значит запаковать аргументы, проверить их, передать в сишную функцию от JNLua, которая для каждого аргумента создаст жвм-объект, найти колбэк по адресу компонента и имени метода, сожрать 2-32 единиц бюджета, произвести диспатч в колбэк, внутри него обработать вызов, потом принять результаты, их нормализовать в поддерживаемые JNLua, отдать в нативную сишную функцию от JNLua, которая каждый принятый жвм-объект преобразует обратно в луа-значения и вернёт их, потом полученные значения запаковать, проверить, распаковать и вернуть. Я надеюсь, что даже при таком длинном описании на деле это займёт не особо длительное время (думаю, порядка сотни микросекунд; источник оценки — потолок), однако если произвести 16 тысяч таких вызовов, то оверхед может стать достаточно существенным. Именно про этот оверхед я и говорил. Я предполагаю, что софтверное склеивание тормозит из-за него. Если гадать ещё безбашеннее, то можно сказать, что хук для TLWY вообще практически бесплатен на фоне него. Аргумент против этой гипотезы: ожидаемая задержка (0.5–1.5 секунд) от полученной (3 секунды) отличается разительно. А bitblt действительно пожирает очень много единиц бюджета вызовов. Если точнее, то для копирования из буфера 160×50 на основной гпу третьего уровня сожрёт 1.5 единиц бюджета (то есть практически точно положит комп на тик). Если копировать из буфера, площадь которого больше максимального основного разрешения соответствующего уровня, комп вообще будет спать несколько тиков. P. S. В довольно древней версии оцелота есть гпу-буферы в том виде, в каком они оказались в OC 1.7.6, и график бюджета вызовов. Можно протестить прогу там.

Разве это не смехотворно малая величина? В таком случае от бюджета серверной стойки в полной комплектации в 1.4 единицы должно оставаться 1.4 - 160 pix * 50 pix * (2 setActiveBuffer + 2 get) * 2-31, то есть 1.3999850988387 Хорошо, предположим, остаток полностью съедают вызовы функций. Пишем для теста любую функцию-заглушку и вызываем её примерно такое же кол-во раз, что и при группировке схожих пикселей: local function throttle() local a = 123 local b = a + 456 local c = a + b ^ a end function screen.update() for i = 1, 160 * 50 * (2 + 2) do throttle() end componentInvoke(GPUAddress, "bitblc", 0) end И... оно работает с той же скоростью, что и в первом примере. То есть на глаз разница не видна, хотя технически она, конечно, есть. Поэтому, имхо, расход бюджета сильно-сильно больше, а хук на вызовы особой роли не играет. Жаль только, что нет фичи вывода значения бюджета через debug.getCallBudgetValue, чтобы знать наверняка Хорошая идея. Закодил, чекнул, скорость действительно чуть возросла, но осталась в пределах ~1 кадра в 3 сек. Вообще мы осознанно убрали bitblc в угоду самописному решению, которое явно проигрывает, так что копать дальше в этом направлении смысла мало. Плюс у нас происходит дублирование вызовов setBackground/setForeground: первый раз во время отрисовки основной графики в буфер, а затем второй раз, но уже в сгруппированном по цветам виде при выводе на экран. Бедная видяшечка, на тайваньских майнинг-фермах и то живется легче (9

Возможно, не бюджет расходуется дико (насколько я понял, каждый прямой вызов в побочный буфер потребляет 2-31 единиц бюджета), а оверхед просто от вызовов доминирует. Кроме того, там можно выделять не два буфера по 160×50, а один на 160×100, например: число вызовов setActiveBuffer вдвое станет меньше. Хотя с таким оверхедом, видимо, не особо это поможет...

Идея занятная, но тормозит люто. Подправил либу, после склейки дело дошло до рендеринга лишь спустя ~5 сек, то есть комп фактически виснет на процессе поиска пикселей со схожими цветами на тоннах вызовов setActiveBuffer/get. У меня вообще зародилось смутное подозрение, что все операции над буферами ни разу не zero cost даже с поправкой на искусственный троттлинг хука вызовов в machine.lua. И ладно бы вывод на экран - сам процесс рисования в буфер через setBackground/setForeground/set явно кушает бюджет. Как говорится, численно доказать не могу, но эмпирически чувствую

К слову, насколько сильно будет тормозить решение, которое перенесёт массивы-буферы из луа в vram, но склеивание операций и рендер будет проводить всё так же в луа, не используя bitblt?

Баги, которые появились в 1.7.6: сломаный брайль, сломаная опенось, сломанная версия — пофиксили в спешном темпе и выпустили 1.7.7.