d
я планирую на каждый ЦП держать по потоку и раздавать им асинхронные таски
Size: a a a
2020 November 28
d
ну и один поток будет основным, крутить UI и прочие потокозависимые вещи
TG
Что можно почитать по реализации PCSS? А то что-то херня какая-то получается с размером полутени
если найдёшь что-то скинь сюда, я только пару статей встречал, одну от NV, вторую в GPU Gems или Pro
TG
обе так себе
M
Увы, нашёл ещё только какую-то кривоватую имплементацию на glsl - пришлось шаманить руками
2020 November 29
A
я планирую на каждый ЦП держать по потоку и раздавать им асинхронные таски
А как решаешь то что таски могут сильно отличаться?
d
А как решаешь то что таски могут сильно отличаться?
это создаёт какую-то проблему?
A
это создаёт какую-то проблему?
Ну в целом да? Например могут быть тупые таски в духе исполнить лямбду где то. А могут быть таски с ожиданием, хотя ты мог от таких избавиться. Ещё например io таски. Или наоборот cpu bounded. В общем для части задач может получиться, что создание твоей обобщенной таски вносит приличный оверхед в сравнении с наивным вариантом для простых тасок. Ну в том же folly предлагается по дефолту два экзекутора, а у тебя как я понимаю строго один к которому привязана реализация тасок
AP
Что можно почитать по реализации PCSS? А то что-то херня какая-то получается с размером полутени
Кстати реально, у меня с тенями ужас. Они пиксельные, наивный pcf просто делает пиксельные полутени. Ещё все постоянно скачет при движении камеры, так как направленные карты теней привязаны к её позиции
M
Ну приятный результат у меня получился только на 128 семплах с выборкой по пуассону, что дичайший треш. Но для моей задачи приемлемо
AP
128? Чёт для риалтайма реально какой-то треш
M
Ну я для обливиона прикручивал PCSS. Можно позволить и такую - всё равно гпу там больше девать некуда
A
потоки специализированы и наверняка некоторые из них будут простаивать, потому что у них будут очень простые задачи
Ну и в целом ничего плохого кроме того что стек занимает память в том что несколько потоков простаивает нет. На мой взгляд иметь для специализированных задач свой поток или тредпул вполне нормально. К тому же это может давать больше возможностей в плане оптимизации синхронизации.
Можно конечно делать тредпул фиберов/корутин, но не факт что получиться лучше.
Можно конечно делать тредпул фиберов/корутин, но не факт что получиться лучше.
d
Ну в целом да? Например могут быть тупые таски в духе исполнить лямбду где то. А могут быть таски с ожиданием, хотя ты мог от таких избавиться. Ещё например io таски. Или наоборот cpu bounded. В общем для части задач может получиться, что создание твоей обобщенной таски вносит приличный оверхед в сравнении с наивным вариантом для простых тасок. Ну в том же folly предлагается по дефолту два экзекутора, а у тебя как я понимаю строго один к которому привязана реализация тасок
таски которые которые ждут должны быть в await состоянии, т.е. чтобы их можно было повторно запланировать (например, по окончании IO), и они продолжили с того места где остановились (например, подали запрос на IO)
d
Ну и в целом ничего плохого кроме того что стек занимает память в том что несколько потоков простаивает нет. На мой взгляд иметь для специализированных задач свой поток или тредпул вполне нормально. К тому же это может давать больше возможностей в плане оптимизации синхронизации.
Можно конечно делать тредпул фиберов/корутин, но не факт что получиться лучше.
Можно конечно делать тредпул фиберов/корутин, но не факт что получиться лучше.
я и хочу тредпул корутин
A
я и хочу тредпул корутин
А ты хочешь stateless?
d
ещё у меня есть задумка с примитивами синхронизации для пулов, что-то вроде co_await mtx.lock()
A
А ты хочешь stateless?
Мне кажется без 20 стандарта убого очень будет.
A
ещё у меня есть задумка с примитивами синхронизации для пулов, что-то вроде co_await mtx.lock()
Ну да тебе нужны свои, иначе как оно работать будет
d
А ты хочешь stateless?
вообще у меня можно любые, даже скостыленые на switch, главное поддерживать контракт с пулом