EmuStudio-ZX

[Titus]

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

Это у меня так. Потому что нет настроек. В переспективе разумеется это должен регулировать юзер.

[Advertiser]

[ZXMAK]

Это у меня так. Потому что нет настроек. В переспективе разумеется это должен регулировать юзер.

изменение приоритета опасно тем, что приводит к т.н. проблеме инверсии приоритетов. Поэтому процесс должен по дефолту запускаться с дефолтным приоритетом - в этом случае планировщик задач обеспечивает минимум конфликтов и как результат большую производительность и лучшее время реакции.

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

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

[Titus]

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

Эта 'собака' - единственный пока что для меня приемлемый способ практически гарантированно отрабатывать каждый кадр все, что я хочу. Иных методов я не вижу. Если ты придумаешь иной, который будет работать на практике не хуже, пожалуйста, я всегда рад перенимать положительный опыт)

[ZXMAK]

Эта 'собака' - единственный пока что для меня приемлемый способ практически гарантированно отрабатывать каждый кадр все, что я хочу. Иных методов я не вижу. Если ты придумаешь иной, который будет работать на практике не хуже, пожалуйста, я всегда рад перенимать положительный опыт)

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

[Titus]

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

Так как работает у тебя - меня не устраивает) Любая активность и бе, ме, все затыкается)
Так как работает у меня - меня устраивает. Почему я должен тебе верить, если теория расходится с практикой?

[ZXMAK]

Так как работает у тебя - меня не устраивает) Любая активность и бе, ме, все затыкается)
Так как работает у меня - меня устраивает. Почему я должен тебе верить, если теория расходится с практикой?

ну у меня затыкается вовсе не от того что приоритета не хватает, а потому что есть пересечения UI потока и потока эмуляции, пересечения закрыты локами, поэтому пока UI выполняет длительные операции, поток эмуляции решивший выдать следующий кадр вынужден простаивать, пока UI поток не освободит блок кода который работает с видеокартой. А UI поток в это время сбрасывает d3d чтобы подстроить размеры backbuffer и ожидает vblank, что занимает прилично времени. Вот я с этим и воюю
Я всячески пытался избежать копирования изображения в новый буфер, чтобы не есть лишнее время процессора. Но сейчас прихожу к выводу что без этого не обойтись. Сейчас поток эмуляции уже изолирован от потока вывода звука, осталось изолировать от рендерера. Тут получается расплата - приходится платить дополнительным выделением памяти и временем на копирование в него ~640 кБ видеоданных, за то чтобы эмуляция была непрерывной и не зависела от того занята ли сейчас видеокарта или нет...

Почитал доки на D3D9, ситуация с ним печальная - у 9-ой версии нет нормальной поддержки многопоточности. Включение флага multithreaded приводит к дополнительному оверхеду и возможным дедлокам, т.к. такие вызовы как Create, Reset, Release очень завязаны на поток в котором работает message pump. Они могут отправлять SendMessage и перехватывать оконные сообщения, что может привести к дедлоку. Что еще хуже - этим-же и Present грешит, особенно опасно при этом нестандартные приоритеты использовать. В D3D11 с этим заметно лучше.

[Titus]

ну у меня затыкается вовсе не от того что приоритета не хватает, а потому что есть пересечения UI потока и потока эмуляции, пересечения закрыты локами, поэтому пока UI выполняет длительные операции, поток эмуляции решивший выдать следующий кадр вынужден простаивать, пока UI поток не освободит блок кода который работает с видеокартой. А UI поток в это время сбрасывает d3d чтобы подстроить размеры backbuffer и ожидает vblank, что занимает прилично времени. Вот я с этим и воюю
Я всячески пытался избежать копирования изображения в новый буфер, чтобы не есть лишнее время процессора. Но сейчас прихожу к выводу что без этого не обойтись. Сейчас поток эмуляции уже изолирован от потока вывода звука, осталось изолировать от рендерера. Тут получается расплата - приходится платить дополнительным выделением памяти и временем на копирование в него ~640 кБ видеоданных, за то чтобы эмуляция была непрерывной и не зависела от того занята ли сейчас видеокарта или нет...

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

---------- Post added at 03:48 ---------- Previous post was at 03:43 ----------

"устраивает" у всех персональное
у меня лично софтины без моего ведома меняющие свой приоритет идут в /dev/null

Большинство людей, как я думаю, если это хобби, пишут софт прежде всего под себя, а затем смотрят, а не мог ли этот софт быть полезен другим? Я любитель 100% видео и аудиоидентичности при эмуляции. Чтобы я мог играться и получать полный эффект присутствия. Если для этого надо так или иначе взаимодействовать с системой (в данном случае задирать приоритет процессу), то я это буду делать, если других эффектных альтернатив не вижу. Для юзера можно сделать настраиваемым - менять приоритет/не менять, но для себя, как мне лучше - я выбор сделал.

В какой-то мере, эту приоритетофобию считаю предрассудком, ибо мои эмуляторы всегда его меняли, и никто никогда не обратил на это внимания)