Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
". Есть у нас нечто общее и известное. Графические API "
-Если API позволяет нам, получить данную информацию в чём проблема?
И где подмена понятий. Я вам сразу про них сказал.
-Тогда уж вы потом, ничего не сказали об API.
«Но это не значит что в этих играх не нужна производительность.» Я так и представляю тебе не хватает нескольких сотен фпс в какой-нибудь террарии, нойте, ваганте, вампайр сурвайвлах и прочих.
Ещё раз я вам же сразу упомянул про UE и Unity. Опять же всё что не А+ тайтл от крупной студии со своим движком, с огромной долей вероятности, будет именно на данных движках. Просто потому, что свой дивжок малые студии не потянут.
При том как раз нет, хороший такой пласт игроков играет именно в сессионки/А+ тайтлы и очень редко вылезает куда-то ещё.
Пару популярных сессионок, типо доты и кс на соурсе тоже без проблем можно добавить. Благо вам 100% пройдутся по всем популярным играм. Господи они их сами используют в своих тестах, наверняка они про них в курсе.
«это определяется за пару микросекунд.» Брехня. Т.к. ты сперва можешь нафиг перегрузить ядро. Я так и представляю этот смачное зависание приложения при запуске тяжёлой задачи. Просто потому, что запустил тяжёлую задачу, на слабых ядрах. А потом, он очухается. Очевидно план надёжный как швейцарские часы.
И да микросекунды, для процессора, это миллионы тактов.
Открою вам маленькую тайну. ОС управляет ровно тем, чем ей дают управлять.
ОС это вообще надстройка! Изначально же вы запускаете даже не Биос, а uefi. Что по сути ОС в миниатюре.
И как я уже говорил, что бы например Виндоус определил лучшее ядро, он сделает это не сам и не напрямую, а через API.
А с чипсетом всё просто, это некоторая логика, такой же микропроцессор, который работает с привычным нам процессором, через внутреннюю шину. У интела оно так же. Как конкретно он работает уж извиняйте не знаю. Но в чем проблема то. Драйвера чипсета, определенно дают нам подобную возможность.
А конфликта не будет очевидно. Ну вот например опять же выбор лучшего ядра, в рамках однопоточного буста. У АМД в райзен мастере можно глянуть, какие ядра считаются лучшими по версии ОС, а какие по факту.
Ведь почему то ситуация с Интел вас не смущает. А у них на минуточку, не просто там какой-то драйвер чипсета, а свой аппаратный планировщик. Ну как то не коефликтуют
По поводу управления, вы может быть забыли, что вы один фиг ничем не управляете. В смысле самим ядром процессора. Это же не VLIW, с его концепцией явного программирования. Где программист управляет ресурсами. У ядра обычно есть декодер и планировщик. Т.е. даже отданную процессору команду, он переведет в свою какую-то внутреннюю. Если правильно понимаю микрооперации.
Ну вообще вы не забывайте, что таки ядра у Айфона пожирнее и по дороже выходят.
Да и само ядро собственной разработки, а не просто сконфигурированное ядро от арм. Очевидно же, что своё ядро, на которое не жалели денег и сил окажется лучше стандартного.
Так что да они и крутые в том числе.
И это при том, что продукция от эпл, это последнее что мне нужно. Но глупо спорить с фактами.
Так и квалкомм вроде для того разработчика ядер купили. (Nuvia)
Вы порядок действий то не путайте сперва игра, потом рендер я сказал. И нет оно немного не так должно будет работать.
Смотрите мы знаем у нас игра. Она в приоритете на конкретном CCX. Очевидно ресурсы данного CCX могут использоваться не полностью.
Всё остальное будет в приоритете на другом CCX. На основе частоты.
Теперь мы запускаем рендер, который достаточно тяжёлый и может утилизировать все потоки. То мы должны получить такую картину.
Игра останется в приоритете на своём CCX. Рендер на своём CCX.
Но при этом, с хорошей вероятностью, рендер сможет получить свободные ресурсы чиплета, на котором сейчас работает игра. Т.к. игра использует весь CCX не на 100%
Мб я плохо объясняюсь, по тому уточню что имею ввиду. Не должно быть жёсткой привязки, что на 1/2 CCX только игра или только рендер и ничего более. Иначе будут потери производительности. Просто игра должна быть именно приоритетной задачей, для данного CCX. Но нет ничего такого, что бы встроить в конвейер вторую задачу. В принципе процессор и так этим занимается. Выполняя на одном ядре разные задачи.
Хорошо, назовите мне игры, современные не на DirectX/Vulkan/OpenGL. А не 10-20 летней давности, где тебе один фиг производительности за галаза. Их хотя бы 1% будет? Пожалйста вы закрыли практически все игры.
Опять же сколько в год выходит у нас ААА игр? Извините, но если они могут эти 1.5 игры оптимизировать в драйвере, то и не составит труда сделать тоже для процессора, в драйвере чипсета.
Ах да ваша логика для интел идиотская. Ибо тебе зачем-то, нужно запустить задачу на малых ядрах. Потом понять ага не те ядра, давай на большие. Нафига? Это примерно при забеге на 100м, ты сперва первые метров десять ковыляешь с костылями, а потом бежишь со всех ног.
А теперь давайте к игре добавим что-то ещё. Тот же рендер. В случае АМД игра останется всё на том же CCX. А вот у интела активная задача будет в приоритете. Откроете игру и рендер может улететь на малые ядра. А вот АМД должно быть пофигу.
Игры априори однопоточны. У них есть выраженный альфапоток. Просто потому, что работа CPU в играх, это задачи которые сложно распараллелить. Иначе бы их в основном считали GPU.
Следственно всё что нужно, это отправить этот альфапоток, на нужный CCX всё.
И да равномерная загрузка ещё ни о чём не говорит. Многие игры тоже распараллеливают задачу как могут и загружают максимально эффективно. Но при том, интересная ситуация. Если взять 2 процессора один 12 поточный, другой 16 поточный. При этом у 12 поточного будет выше производительность на ядро выше, лучше будет 12 поточник. Хотя казалось бы 16 потоков должны быть в многопоточке лучше.
Именно из за этого механизма 12/24 и 16/32 ядерные/поточные процессоры в играх, не дают особого прироста, кроме как за счёт чуть лучшей буст частоты.
«снижать свою частоту и потребление чуть ли не до нуля...»
-Но не до 0. А до 1 ГГц или около того в лучшем случае 3-4 сотни МГц. А отдав задачу на малое ядро, ты можешь отключить (усыпить ядро) полностью. Там ведь нод не только конвейер, но и внутренний планировщик, кеши, регистры всё это отключить(отправить в глубокий сон).
А т.к. больше ядро, простите за тавтологию, больше то отключи его ты как раз и получаешь выигрыш в энергоэффективности.
Ну это по мимо того, что Интел никак иначе не смогли нарастить количество ядер. В рамках того-же потребления и размеров кристалла.
И извините, если они кушают в 3 раза дольше, это как раз проблема аппаратного планировщика интел, который такую задачу должен был исполнять на больших ядрах.
А если определил нагрузку верно, и эти в 3 раза дольше, представляют собой скажем 0.5 секунды и 1.5 секунды, в не интерактивной задаче, допустим распаковка архива (т.е. задача не тяжёлая и не требует отклика здесь и сейчас), то он может кушать в 4-5 раз меньше.
Неа. У E ядер интела немного другая задача. Их смысл всё же в энергоэффективности. Из за чего, задача отправлять лёгкую/фоновую задачу на малые ядра, дабы отправить в сон большие ядра. Но если тяжелая задача оказывается в фоне?)
У АМД иначе. Тебе нужно отправить игры, ну и может круг очень узких задач в лучшем случае, на ядра чиплет с кешем. При том, какая разница в фоне они или нет. Лёгкие или нет. Не имеет значения.
Тут задача схожа обычной работой планировщика. Ведь ему надо определить однопоточные задачи и отправить их на определённые ядра. В случаем АМД ещё и на определённый CCX. Оно уже работает.
Только теперь условие не однопоточные задачи, а игры. И логика та же. Выставляем при виде метки игра. Отправляем задачу на нужный CCX с приоритетом по ядрам внутри оного.
Тебе нужно проработать куда меньше сценариев. Ведь кроме игр, есть комплияция, рендер, работа с браузером, работа с файловой системой и т.д.
У интела. Ну вот например есть рендер, я допустим хочу его отправить в фон, а играть на малых ядрах.
Или другой пример, я хочу распаковать архив на малых ядрах в фоне, пока играю игру на больших.
И вот тебе практически два диаметрально противоположных сценария. И так со всеми задачами надо.
Но они сделали примерно так. Если у нас окно активное, оно уходит на большие ядра. Если задача выполняется в фоне, то на малые.
Из за чего, рендер в фоне и уходил на малые ядра.
У АМД. Логика супер простая.
Если у нас есть ярковыраженная однопоточка, то отправляем её на приоритетные в нужном CCX (допустим 1ый). Если нет, то распределяем нагрузку по всем ядрам. Примерно такая логика сейчас.
И теперь к первому предложения добавляем, «но если у нас игры, при распределяем нагрузку на другой ССХ (допустим 2ой с кешем). Всё.
Если что разночиплетность идёт с её появления! Только раньше разность заключалась в 200-300МГц частоты. Следственно однопоточку нужно было отправлять исключительно на первый частотный чиплет. Как видим работает.
Вообще эту проблему как раз решили подсунув нужные метки.
Но планировщик винды пришлось доделать, что бы нагрузка работала приоритетно в рамках одного CCX. Кто-то почувствовал данную проблему, а главное сколько их?
А теперь даже проще, в рамках уже существующей логики, просто добавить одно дополнительное условие.
Все гениальное просто. В смысле очень простая реализация по идее.
Там же как винда же запрашивает данные через API. А потом уже согласно внутренней логике распределяет нагрузку. Логика работы уже учитывает чиплеты.
на ядра.
И если запускается игра, мы можем например поднимать флаг и после через тот же механизм сообщить сменить приоритетные ядра.
Минимум доработок со стороны винды в том числе. И существенно проще, чем реализация интел с разбиением на кластеры, где логика загрузки малых и больших ядер разная при том во всём софте сразу.
Ибо нужно лёгкие/фоновые задачи на малые ядра, а тяжелые задачи на большие. Ради энергоэффективности.
ААА игры АМД могут например вручную тестировать, на наличие прироста и выставлять нужную метку. В остальном же как отличить игра у нас или нет. Есть у нас нечто общее и известное. Графические API или те же игровые движки UE/Unity и несколько собственных движков крупных студий.
Вы ошибаетесь. Как минимум тогда уж N3P.
А как максимум N(x) это нода. Т.е. некоторые правила проектирования.
При этом на одной ноде обычно реализуют 3 разных тех процесса.
LP(LPP)
HD
HP
Т.е. какой-нибудь N5 HD и N5 LP, вроде и то и то N5, но один имеет более высокую плотность транзисторов, а второй более энергоэффективный.
Т.к. с N3 у нас немного другие правила игры, так что сейчас фиг знает как оно будет.
Ну не совсем. Это по сути расчётная мощность для базовых частот или для буста на одно ядро. Это то что нам традиционно гарантирует производитель.
Но очевидно есть PL2. Есть PPT (Package Power Tracking), данное значение берут с сокета.
Которые дают уже больше.
Есть и PBO который умеет выходит за лимиты TDP.
Вот в ноутах TDP имеет смысл, но проблема в другом, данный лимит на совести производителя. Хотя и в обычных десктопных пк, по сути ситуация похожая, но за то как настроен процессор из коробки, отвечает производитель материнской платы. Например они могут дефолтно выставить PL2.
Тут палка о двух концах. Да тех процессы самсунга хуже. Но решается то вопрос с нагревом просто, снизь частоты. Потребление растёт не линейно. И любая микроэлектроника будет себя так вести, если выйти за оптимальные значения кривой частота/потребления. Т.е. войти в зону экспоненциального роста.
Ведь тем же страдали/ют интел. Особенно когда застряли на 14нм. Начали наращивать ядра + немного частоты и потребление следом разогналось и процессор начал греться.
При том, физически нагрев плохо влияет на энергоэффективность процессора. Т.к. чем выше температура, тем выше токи утечки. Выше токи утечки, выше потребление, выше нагрев.
Кстати именно для того и используют жидкий азот. Хитрость в том, что они сдвигают самую кривую частоты к напряжению. Ибо при тех же параметрах кривой, но без азота, система не заработает, даже если вы способны её охлаждать.
Но тут вылезает вторая сторона медали. Производителям нужно продавать попугаи. А то как то не комильфо, что производительность будет той же. Как объяснить потребителю, которых вы и приучили что больше, значит лучше. Это же ФЛАГМАНСКАЯ платформа.
И тут уже возникают вопросы к конторе. Каким боком у них S23 Ultra = S23 Plus.
Там всё таки разные основные модули камеры.
200 MP, f/1.7, 24mm (wide), 1/1.3", 0.6µm, multi-directional PDAF, Laser AF, OIS
против
50 MP, f/1.8, 24mm (wide), 1/1.56", 1.0µm, Dual Pixel PDAF, OIS
Это говорит нам о том, что баллы не должны быть равны. А по тесту равны.
-Если API позволяет нам, получить данную информацию в чём проблема?
И где подмена понятий. Я вам сразу про них сказал.
-Тогда уж вы потом, ничего не сказали об API.
«Но это не значит что в этих играх не нужна производительность.» Я так и представляю тебе не хватает нескольких сотен фпс в какой-нибудь террарии, нойте, ваганте, вампайр сурвайвлах и прочих.
Ещё раз я вам же сразу упомянул про UE и Unity. Опять же всё что не А+ тайтл от крупной студии со своим движком, с огромной долей вероятности, будет именно на данных движках. Просто потому, что свой дивжок малые студии не потянут.
При том как раз нет, хороший такой пласт игроков играет именно в сессионки/А+ тайтлы и очень редко вылезает куда-то ещё.
Пару популярных сессионок, типо доты и кс на соурсе тоже без проблем можно добавить. Благо вам 100% пройдутся по всем популярным играм. Господи они их сами используют в своих тестах, наверняка они про них в курсе.
«это определяется за пару микросекунд.» Брехня. Т.к. ты сперва можешь нафиг перегрузить ядро. Я так и представляю этот смачное зависание приложения при запуске тяжёлой задачи. Просто потому, что запустил тяжёлую задачу, на слабых ядрах. А потом, он очухается. Очевидно план надёжный как швейцарские часы.
И да микросекунды, для процессора, это миллионы тактов.
ОС это вообще надстройка! Изначально же вы запускаете даже не Биос, а uefi. Что по сути ОС в миниатюре.
И как я уже говорил, что бы например Виндоус определил лучшее ядро, он сделает это не сам и не напрямую, а через API.
А с чипсетом всё просто, это некоторая логика, такой же микропроцессор, который работает с привычным нам процессором, через внутреннюю шину. У интела оно так же. Как конкретно он работает уж извиняйте не знаю. Но в чем проблема то. Драйвера чипсета, определенно дают нам подобную возможность.
А конфликта не будет очевидно. Ну вот например опять же выбор лучшего ядра, в рамках однопоточного буста. У АМД в райзен мастере можно глянуть, какие ядра считаются лучшими по версии ОС, а какие по факту.
Ведь почему то ситуация с Интел вас не смущает. А у них на минуточку, не просто там какой-то драйвер чипсета, а свой аппаратный планировщик. Ну как то не коефликтуют
По поводу управления, вы может быть забыли, что вы один фиг ничем не управляете. В смысле самим ядром процессора. Это же не VLIW, с его концепцией явного программирования. Где программист управляет ресурсами. У ядра обычно есть декодер и планировщик. Т.е. даже отданную процессору команду, он переведет в свою какую-то внутреннюю. Если правильно понимаю микрооперации.
А по с закрытым исходным кодом не смущает?
Да и само ядро собственной разработки, а не просто сконфигурированное ядро от арм. Очевидно же, что своё ядро, на которое не жалели денег и сил окажется лучше стандартного.
Так что да они и крутые в том числе.
И это при том, что продукция от эпл, это последнее что мне нужно. Но глупо спорить с фактами.
Так и квалкомм вроде для того разработчика ядер купили. (Nuvia)
Смотрите мы знаем у нас игра. Она в приоритете на конкретном CCX. Очевидно ресурсы данного CCX могут использоваться не полностью.
Всё остальное будет в приоритете на другом CCX. На основе частоты.
Теперь мы запускаем рендер, который достаточно тяжёлый и может утилизировать все потоки. То мы должны получить такую картину.
Игра останется в приоритете на своём CCX. Рендер на своём CCX.
Но при этом, с хорошей вероятностью, рендер сможет получить свободные ресурсы чиплета, на котором сейчас работает игра. Т.к. игра использует весь CCX не на 100%
Мб я плохо объясняюсь, по тому уточню что имею ввиду. Не должно быть жёсткой привязки, что на 1/2 CCX только игра или только рендер и ничего более. Иначе будут потери производительности. Просто игра должна быть именно приоритетной задачей, для данного CCX. Но нет ничего такого, что бы встроить в конвейер вторую задачу. В принципе процессор и так этим занимается. Выполняя на одном ядре разные задачи.
Опять же сколько в год выходит у нас ААА игр? Извините, но если они могут эти 1.5 игры оптимизировать в драйвере, то и не составит труда сделать тоже для процессора, в драйвере чипсета.
Ах да ваша логика для интел идиотская. Ибо тебе зачем-то, нужно запустить задачу на малых ядрах. Потом понять ага не те ядра, давай на большие. Нафига? Это примерно при забеге на 100м, ты сперва первые метров десять ковыляешь с костылями, а потом бежишь со всех ног.
Игры априори однопоточны. У них есть выраженный альфапоток. Просто потому, что работа CPU в играх, это задачи которые сложно распараллелить. Иначе бы их в основном считали GPU.
Следственно всё что нужно, это отправить этот альфапоток, на нужный CCX всё.
И да равномерная загрузка ещё ни о чём не говорит. Многие игры тоже распараллеливают задачу как могут и загружают максимально эффективно. Но при том, интересная ситуация. Если взять 2 процессора один 12 поточный, другой 16 поточный. При этом у 12 поточного будет выше производительность на ядро выше, лучше будет 12 поточник. Хотя казалось бы 16 потоков должны быть в многопоточке лучше.
Именно из за этого механизма 12/24 и 16/32 ядерные/поточные процессоры в играх, не дают особого прироста, кроме как за счёт чуть лучшей буст частоты.
-Но не до 0. А до 1 ГГц или около того в лучшем случае 3-4 сотни МГц. А отдав задачу на малое ядро, ты можешь отключить (усыпить ядро) полностью. Там ведь нод не только конвейер, но и внутренний планировщик, кеши, регистры всё это отключить(отправить в глубокий сон).
А т.к. больше ядро, простите за тавтологию, больше то отключи его ты как раз и получаешь выигрыш в энергоэффективности.
Ну это по мимо того, что Интел никак иначе не смогли нарастить количество ядер. В рамках того-же потребления и размеров кристалла.
И извините, если они кушают в 3 раза дольше, это как раз проблема аппаратного планировщика интел, который такую задачу должен был исполнять на больших ядрах.
А если определил нагрузку верно, и эти в 3 раза дольше, представляют собой скажем 0.5 секунды и 1.5 секунды, в не интерактивной задаче, допустим распаковка архива (т.е. задача не тяжёлая и не требует отклика здесь и сейчас), то он может кушать в 4-5 раз меньше.
У АМД иначе. Тебе нужно отправить игры, ну и может круг очень узких задач в лучшем случае, на ядра чиплет с кешем. При том, какая разница в фоне они или нет. Лёгкие или нет. Не имеет значения.
Тут задача схожа обычной работой планировщика. Ведь ему надо определить однопоточные задачи и отправить их на определённые ядра. В случаем АМД ещё и на определённый CCX. Оно уже работает.
Только теперь условие не однопоточные задачи, а игры. И логика та же. Выставляем при виде метки игра. Отправляем задачу на нужный CCX с приоритетом по ядрам внутри оного.
Тебе нужно проработать куда меньше сценариев. Ведь кроме игр, есть комплияция, рендер, работа с браузером, работа с файловой системой и т.д.
Или другой пример, я хочу распаковать архив на малых ядрах в фоне, пока играю игру на больших.
И вот тебе практически два диаметрально противоположных сценария. И так со всеми задачами надо.
Но они сделали примерно так. Если у нас окно активное, оно уходит на большие ядра. Если задача выполняется в фоне, то на малые.
Из за чего, рендер в фоне и уходил на малые ядра.
У АМД. Логика супер простая.
Если у нас есть ярковыраженная однопоточка, то отправляем её на приоритетные в нужном CCX (допустим 1ый). Если нет, то распределяем нагрузку по всем ядрам. Примерно такая логика сейчас.
И теперь к первому предложения добавляем, «но если у нас игры, при распределяем нагрузку на другой ССХ (допустим 2ой с кешем). Всё.
Если что разночиплетность идёт с её появления! Только раньше разность заключалась в 200-300МГц частоты. Следственно однопоточку нужно было отправлять исключительно на первый частотный чиплет. Как видим работает.
Вообще эту проблему как раз решили подсунув нужные метки.
Но планировщик винды пришлось доделать, что бы нагрузка работала приоритетно в рамках одного CCX. Кто-то почувствовал данную проблему, а главное сколько их?
А теперь даже проще, в рамках уже существующей логики, просто добавить одно дополнительное условие.
Там же как винда же запрашивает данные через API. А потом уже согласно внутренней логике распределяет нагрузку. Логика работы уже учитывает чиплеты.
на ядра.
И если запускается игра, мы можем например поднимать флаг и после через тот же механизм сообщить сменить приоритетные ядра.
Минимум доработок со стороны винды в том числе. И существенно проще, чем реализация интел с разбиением на кластеры, где логика загрузки малых и больших ядер разная при том во всём софте сразу.
Ибо нужно лёгкие/фоновые задачи на малые ядра, а тяжелые задачи на большие. Ради энергоэффективности.
ААА игры АМД могут например вручную тестировать, на наличие прироста и выставлять нужную метку. В остальном же как отличить игра у нас или нет. Есть у нас нечто общее и известное. Графические API или те же игровые движки UE/Unity и несколько собственных движков крупных студий.
А как максимум N(x) это нода. Т.е. некоторые правила проектирования.
При этом на одной ноде обычно реализуют 3 разных тех процесса.
LP(LPP)
HD
HP
Т.е. какой-нибудь N5 HD и N5 LP, вроде и то и то N5, но один имеет более высокую плотность транзисторов, а второй более энергоэффективный.
Т.к. с N3 у нас немного другие правила игры, так что сейчас фиг знает как оно будет.
Но очевидно есть PL2. Есть PPT (Package Power Tracking), данное значение берут с сокета.
Которые дают уже больше.
Есть и PBO который умеет выходит за лимиты TDP.
Вот в ноутах TDP имеет смысл, но проблема в другом, данный лимит на совести производителя. Хотя и в обычных десктопных пк, по сути ситуация похожая, но за то как настроен процессор из коробки, отвечает производитель материнской платы. Например они могут дефолтно выставить PL2.
Ведь тем же страдали/ют интел. Особенно когда застряли на 14нм. Начали наращивать ядра + немного частоты и потребление следом разогналось и процессор начал греться.
При том, физически нагрев плохо влияет на энергоэффективность процессора. Т.к. чем выше температура, тем выше токи утечки. Выше токи утечки, выше потребление, выше нагрев.
Кстати именно для того и используют жидкий азот. Хитрость в том, что они сдвигают самую кривую частоты к напряжению. Ибо при тех же параметрах кривой, но без азота, система не заработает, даже если вы способны её охлаждать.
Но тут вылезает вторая сторона медали. Производителям нужно продавать попугаи. А то как то не комильфо, что производительность будет той же. Как объяснить потребителю, которых вы и приучили что больше, значит лучше. Это же ФЛАГМАНСКАЯ платформа.
Иначе так можно любым тестом спекулировать. Просто подбирая «удобные» тесты, где надо и когда надо.
???
Там всё таки разные основные модули камеры.
200 MP, f/1.7, 24mm (wide), 1/1.3", 0.6µm, multi-directional PDAF, Laser AF, OIS
против
50 MP, f/1.8, 24mm (wide), 1/1.56", 1.0µm, Dual Pixel PDAF, OIS
Это говорит нам о том, что баллы не должны быть равны. А по тесту равны.