Board.KolibriOS.org

Даже программная прорисовка не может так проседать из-за курсора, там что-то не так.

Есть функция 18, подфункция 14 в Колибри API (wait for screen retrace).
Можно попробовать использовать её.
Например:
Я создаю второй буфер в RAM (бэкбуфер) и рисую в него изображение.
Затем жду обновления экрана.
Как только он обновится я начинаю копировать из бэкбуфера в LFB.
Затем строю в бэкбуфер следующее изображение, а когда произойдет следующий рейтрейс то он выведет скопированное в начале цикла первое изображение.
То есть копирование будет происходит сразу после обновления экрана, что должно гарантировать что копирование успеет завершится до следующего обновления.
Возможно будет небольшая латентность, из-за того что получается задержка в 1 кадр, но при хорошем FPS наверное незаметно (в D3D например по нескольку кадров наперёд буферизируется).

а примерный список этих 3D приложений можешь дать? как раз перед началом копирования можно блокировать прерывания, а по завершении активировать, тогда и попробовать словить эффект vsync можно с минимальными затратами на буфер, а латентность можно даже сделать настраиваемой. вердикт: качай исходник, смотри, делай

Да все 3D приложения которые в папке rd/1/3D.
Например демо с шестерёнками при разрешении 1024x768 (VirtualBox, 1 ядро выделено, 2.2 ГГц) дают 55-60 FPS, а если начать непрерывно двигать мышь будет 30 FPS.

Блокировка прерывания на обновление экрана?
То есть можно запретить обновлять данные экрана считыванием из LFB, пока я туда записываю?
Это делать функцией из KolibriAPI или как-то через VESA сразу?
Я думал что видеокарта выводит данные из LFB прямо на экран и если LFB заблокировать то ничего выводиться просто не будет, или после LFB есть ещё какие то буферы?

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

Ок, попробую.

По ходу работы в Колибри словил несколько багов:
* Когда я передал неправильные параметры в функцию 4 (которая строки выводит) и запустил из под отладчика mtdbg, приложение зависло с pages fault, и его невозможно было убрать через kill process, система при выключении тоже не смогла завершить его и так и не выключилась.
* Если в eolite file manager переименовывать файл и набрать имя существующего файла, то существующий удаляется и на его место записывается переименованный. Я таким образом потерял солидный кусок кода. Корзина была бы весьма кстати. Вообще же я считаю переименовывание ни при каких обстоятельствах не должно менять данные файлов, нужно просто запретить называть имена файлов тем же именем, даже не спрашивать пользователя о замене. Для изменения данных файлов есть другие операции.

Это проблема исключительно Eolite. И к сожалению известаная, но подзабытая. Постараюсь профиксить на днях.

_________________
я лишь учусь

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

А вот ещё вопрос: как адресовать присоединённые страницы?
Вот я выделил две страницы через кучу. Адрес первой сохранил в переменную. При обращении внутри неё всё нормально работает. Как только я пишу что-то вроде mov dword [ pFirstPage + 4096 ], 0xffffffff, то есть пытаюсь записать в то место где должна быть следующая то получаю page fault. Как я понимаю физически она может находиться и в другом месте, но виртуальная адресация ОС должна быть сплошной, так?
Или у меня что-то в понимании ассемблера неправильно?

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

получается, что прибавил 4096 к адресу переменной pFirstPage, а не к адресу который лежит в этой переменной,. И да, не факт, что новая страница выделилась после предыдущей, а не в любом жругом участке памяти.

_________________
я лишь учусь

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

Однако насчёт страниц: всё таки приложение использует виртуальное адресное пространство, а значит даже если вторая страница будет в другом месте, всё равно я смогу обращаться к ней как если бы она была сразу за первой. В стандартной реализации страничной адресации именно так.

Но в моём случае я хочу выделить 300 страниц под буфер изображения. И вот тут мне бы хотелось чтобы страницы действительно физически были друг за другом, т. к. если память будет фрагментирована, будут происходить кеш-промахи. Можно ли как-то принудительно заставить систему реорганизовать размещение страниц? Насколько мне известно всякие malloc и new в с/с++ умеют выделять физически непрерывный кусок памяти. Просто в описании функций Колибри нет информации где выделяются страницы, может они и так подряд выделяются.

Мне кажется нужно делать такую логику:
1. Для двух разных запросов выделения памяти можно выбирать разные физические адреса страниц.
2. Для одного запроса нужно по возможности выделять физически целый блок, если такого нет -- возвращать ошибку.
3. Пользователь может попросить реорганизовать расположение страниц в памяти чтобы освободился большой пустой кусок, эту операцию сделать отдельно от п. 2, чтобы пользователь решил стоит ли тратить время или предпринять что-то другое (например запросить меньше памяти), т. к. Колибри ориентирована на скорость.
4. После реорганизации снова попытаться запросить выделение памяти.

Сегодня Колибри заглючила/зависла. Пропала панель задач внизу, пропал курсор мыши, на устройства ввода никакой реакции, отображался только рабочий стол. Работали два TextEdit'а, компилятор fasm, mtdbg и моё приложение с выводом графики.
Могло ли такое поведение быть результатом неправильной работы моего приложения?
Как в таких ситуациях поступать? Колибри не знает что в ней что-то сломалось и получается что нету ни bsod'ов, ни крэш-дампов.

Вполне возможно. Повторить не пробовал?

_________________
я лишь учусь

В любом случае нужен лог board, для этого запусти board чере run и в качестве параметра путь к файлу на внешнем накопителе куда будет писаться лог.

_________________
я лишь учусь