EmuStudio-ZX

Цитата:

---

Сообщение от Titus

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

---

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

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

Цитата:

---

Сообщение от ZXMAK

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

---

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

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

Цитата:

---

Сообщение от MetalliC

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

---

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

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

Цитата:

---

Сообщение от Titus

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

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

---

дело в том что устанавливая своему процессу realtime приоритет, ты тем самым снижаешь приоритет своих потоков в вызовах которые зависят от ресурсов системы, используют критические секции пересекающиеся с низкоприоритетными потоками или делают вызовы типа Sleep(0).
Это могло бы закончится вообще полным deadlock'ом, но планировщик задач системы достаточно умен, поэтому чтобы такие "хитрые" процессы не завесили систему, он раз в секунду принудительно повышает приоритет низкоприоритетным потокам, которые перестали получать процессорное время.

Можно провести аналогию с ситуацией на дороге, допустим есть мост, на котором может поместиться только одна машина, по правилам встречные машины должны дождаться, пока мост не покинет машина которая по нему уже едет. Но устанавливая realtime приоритет своему процессу ты нарушаешь это правило и въезжаешь на мост несмотря на то что он занят встречной машиной. В итоге обе машины будут вынуждены остановиться и создадут пробку, потому что ни твоя машина с высоким приоритетом, ни встречная машина имеющая низкий приоритет не смогут разминуться. Т.к. ты считаешь что у твоей машины приоритет более важный, а встречная машина не может сдать назад, т.к. сзади скопились другие машины, вы так и будете стоять, пока не приедет гаи и не оттащит тебя с моста несмотря на твои приоритеты, чтобы разрулить пробку.

Также и с приоритетами процессов. Если ресурс уже занят низкоприоритетным процессом, то твой realtime приоритет не даст ему время, чтобы освободить ресурс. В итоге у твоего процесса есть процессорное время, но он не может продолжать работу, т.к. ресурс занят низкоприоритетным процессом. А низкоприоритетный процесс не может освободить ресурс, т.к. у него низкий приоритет и он не получает на это процессорное время. Например Sleep(0) тут не поможет, т.к. отдает время только потокам с приоритетом не ниже твоего. Все что остается либо заснуть всем твоим потокам на несколько квантов времени, чтобы низкоприоритетные потоки получили время и освободили ресурс, либо ждать пока пройдет достаточно времени чтобы планировщик заметил хулиганское поведение твоего процесса и принудительно снизил ему приоритет на несколько квантов времени, чтобы разрулить затор. А это в худшем случае может произойти через 1 секунду. Как результат твой процесс с realtime приоритетом в любом случае теряет кванты времени, которые мог использовать для полезной работы.

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

Ты мне напоминаешь ученого, который с упорством доказывает инопланетянам, что их не существует)

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

Цитата:

---

Сообщение от ZXMAK

Все что остается либо заснуть всем твоим потокам на несколько квантов времени, чтобы низкоприоритетные потоки получили время и освободили ресурс

---

Так у меня и делается, если че)

Цитата:

---

Сообщение от Titus

Так у меня и делается, если че)

---

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

Цитата:

---

Сообщение от ZXMAK

Следовательно, установка приоритета приводит к тому что время любой операции связанной с ресурсами или синхронизацией потоков может доходить в худшем случае до 1 сек (максимальное время приезда гаишников для разруливания пробки на мосту) - это все чего можно добиться установкой приоритета :)

---

Хорошо, будем считать, что в твоей Вселенной мой эмулятор периодически замирает на 1 секунду.
А пойду в него играться в своей Вселенной, где все реалтаймово и красиво)

Цитата:

---

Сообщение от Titus

Хорошо, будем считать, что в твоей Вселенной мой эмулятор периодически замирает на 1 секунду.
А пойду в него играться в своей Вселенной, где все реалтаймово и красиво)

---

Зачем перекручивать? На моей машине в эмустудио звук прерывается с частотой гдето 25-50 гц. Если принудительно поставить приоритет в норму, то звук перестает обрываться так часто - можно услышать до нескольких секунд чистого тона, но обрывы всеже происходят

Цитата:

---

Сообщение от ZXMAK

Зачем перекручивать? На моей машине в эмустудио звук прерывается с частотой гдето 25-50 гц. Если принудительно поставить приоритет в норму, то звук перестает обрываться так часто - можно услышать до нескольких секунд чистого тона, но обрывы всеже происходят

---

Я тебе уже один раз обьяснял, что на твоей машине звук и не может работать нормально, т.к. на вин7 та звуковая система, что я писал для себя вообще работать не должна. Но ты мои слова не услышал)

Цитата:

---

Сообщение от Titus

Я тебе уже один раз обьяснял, что на твоей машине звук и не может работать нормально, т.к. на вин7 та звуковая система, что я писал для себя вообще работать не должна. Но ты мои слова не услышал)

---

Ну в zxmak2 на моей машине звук прекрасно работает - можно слушать хоть минуту -тон идет чистый без срывов. Можно даже размер буфера уменьшить до 3-х кадров - всеравно звук стабильно работает. И без манипуляций с приоритетом процесса, с нормальным приоритетом ;)
Также и другие эмуляторы нормально звук воспроизводят и все с нормальным приоритетом ;)

Цитата:

---

Сообщение от ZXMAK

Ну в zxmak2 на моей машине звук прекрасно работает - можно слушать хоть минуту -тон идет чистый без срывов. Можно даже размер буфера уменьшить до 3-х кадров - всеравно звук стабильно работает. И без манипуляций с приоритетом процесса, с нормальным приоритетом ;)
Также и другие эмуляторы нормально звук воспроизводят и все с нормальным приоритетом ;)

---

И что из этого?
У меня звук написан не так, как у тебя, и то, что он не работает на вин7 никакого отношения к приоритетам не имеет) Если ты хочешь узнать, почему, почитай эту тему с самого начала.