All streams
Search
Write a publication
Pull to refresh
3
0.1
Виктор Дручинин @Viknet

User

Send message

Скорее всего, речь про аналитическое решение проблемы сферических аберраций https://ru.wikipedia.org/wiki/Уравнение_Акуны-Ромо

Насколько я вижу, они как раз минимизировали вынос контроллеров с внутренней стороны кисти и спереди. Судя по картинкам, для близкого взаимодействия они должны быть даже более удобны, чем первые Oculus Touch, и центр тяжести так же примерно внутри ладони.

Ну и вот сделка завершена и озвучены планы по выпуску ноутбучных чипов:


The first Qualcomm Snapdragon platforms to feature Qualcomm’s new internally designed CPUs are expected to sample in the second half of 2022 and will be designed for high performance ultraportable laptops.

https://www.anandtech.com/show/16553/qualcomm-completes-acquisition-of-nuvia

Вы код видели Corellium? Я, пусть и достаточно бегло, но смотрел. Он нормальный. Ничем не хуже значительной части остального кода в Linux.

Их патчи ломают поддержку других ARM-платформ. Они одноразовые.
А для внутренних проектов и так сойдёт.


это никак не говорит об изначальных намерениях Corellium

Сотрудники Corellium уже 2 месяца не появляются в мейллистах, код на гитхабе ни разу с форка не ребейзился. Для меня их намерения пока очевидны.


Ему просто уступили, так как очень хочется.

Что уступили, простите?


И заодно расскажите, что за такое "приличное сообщество", которое ржёт над Гектором, где оно обитает?

То, что Corellium наклепали на скорую руку, невозможно ни поддерживать, ни интегрировать в апстрим. У них даже документации нет, только инструкция "как попробовать загрузиться и понять, что ничего толком не работает".
Собрали хайпа на основе предыдущих наработок под iOS-устройства, а дальше развивать им не интересно.


То, что делает сейчас Мартин — тщательно документирует все особенности новой платформы и заносит "чистые" патчи в апстрим ядра.

Один из инженеров Apple, работавших над загрузчиком:


It's pretty gratifying to see how quickly this all came together. Some engineers were highly supportive of the alternate-kernel mechanism to nominally enable linux, others were skeptical it would ever get used. I was in the former camp, but I thought it would take a lot longer!

https://twitter.com/XenoKovah/status/1370131505620652038

Во-первых, это была осознанная стратегия — чтобы все обзоры сконцентрировались не на внешнем виде, а на изменениях архитектуры.
А во-вторых, вы забываете про 2xThunderbolt4 и 2xUSB-A, каждый из которых может обеспечивать 10-15 Вт.


Просто так перепроектировать и заново сертифицировать давно беспроблемно работающий блок питания, чтобы он вместо 180 Вт выдавал только 120 — неразумная трата средств, учитывая, что следующие поколения Mac Mini почти гарантированно будут в других корпусах.

Кроме ISA есть очень много всяких вещей: работа с прерываниями, управление частотами и отключением ядер, шедулинг задач с учётом топологии, модель памяти с 16kb страницами, режимы ожидания/сна, управление питанием, GPU и вся подсистема вывода, NVMe контроллер, PCIe контроллер...

там вроде как не в него упирается, по крайней мере для других ГПУ BAR хватало.

Какие другие GPU заводили на Raspberry Pi через PCIe?


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

Я дописал апдейт, где поясняется, на чём остановился проект: https://twitter.com/domipheus/status/1175340360060612608
С архитектурой ARM это никак не связано — проблемы в урезанном PCIe-контроллере и/или драйвере для него.
Собственно, как я и говорил, основная проблема заведения GPU под ARM — найти нормальную плату с полноценным PCIe.

vbios под x86 написан

Это давно решено на уровне ОС: https://news.ycombinator.com/item?id=20401258


это очень редкие исключения где сам производитель ГПУ пошел навстречу, обычно это АМД. Точно так же в приведённых примерах 1-3 адаптированных варианта.

А список поддерживаемых карт тоже ни о чём не говорит?


Есть так же долгая попытка завести карту на последней малинке с PCIe.

Распаивая проводочки по плате и пытаясь добиться стабильного PCIe 1.0 x1? К тому же, по ссылке выше пишут, что в нём просто недостаточный размер Base Address Register, чтобы завести современную видеокарту.
В нормальных системах с полноценным PCIe x8 таких проблем просто нет.


UPD: В конце концов там всё упёрлось в драйвера контроллера


И из свежего на м1 эпловских не работают егпу, не смотря на полноценный болт.

Так драйверов нет. И, скорее всего, не будет — ради 0.5% пользователей entry-level моделей, которые хотят подключить eGPU, никто драйвера под ARM macOS писать не будет.

Что значит "не хотят" и какая им вообще разница, кто по PCIe данные шлёт?


Попробуйте найти именно практически рабочее решение на АРМ.

Пожалуйста: Ampere eMAG 8180. На выбор в комплекте есть разные варианты самых обычных GPU, и можно поставить любую свою карту.
Или вот более старый GIGABYTE ThunderXStation с банальной NVIDIA GeForce GT 710, а тут рассказывают, что тестировали с разными картами NVidia и AMD.

Вопрос ведь был не «что сделано»? Вопрос был «почему сделано»? И больше того — почему сделано именно так? И про М1 та же ерунда.

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


Я же пытаюсь заставить вас копать глубже и уже начать хоть как-то открывать «черные ящики».

Ну давайте, покажите как открыть "чёрные ящики" M1.
На каких принципах там основан предсказатель ветвлений, который стабильно обходит на 20-25% конкурентов от Intel?
Какие алгоритмы ренейминга регистров позволили им успешно утилизировать 8 декодеров?
Как именно они меняют на лету модель памяти с расслабленной (ARM) на более строгую (x86), и не ловят рассинхронизаций кэшей или замедлений?


VHDL/Схемотехника узлов — прилично заляпанной схемой, из которой все равно понятна общая суть. Ровно то, чего добивается ARM, держа свой developer сайт.

Общая суть всех процессоров довольно понятна, они все не очень сильно различаются по набору крупных блоков. Дьявол в деталях.

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


The CPU architecture defines the basic instruction set, as well as the exception and memory models that are relied upon by the operating system and hypervisor.

Архитектура в широком смысле: AArch32 (aka ARM — 32-битный набор инструкций и AArch64 (aka ARM64) — 64-битный ISA. В более узком смысле обозначается конкретная версия архитектуры, например: ARMv7-A, ARMv8.6-A.


The CPU microarchitecture determines how an implementation meets the architectural contract. The microarchitecture defines the processor's power, performance and area by determining the pipeline length, levels of cache and so on.

Микроархитектура — устройство конкретного ядра/процессора, реализующего некоторую версию архитектуры. Примеры: Cortex-X1, Firestorm/Icestorm.


А RISC — это общие принципы, которыми на словах руководствовались разработчики архитектуры.


А где же революционная микроархитектура Apple о которой так много говорили большевики немного выше?

В третий раз привожу ссылку на разбор микроархитектуры Apple: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2

Есть архитектура чипа, узла, системы, здания, города… С разных слоев приставка микро- будет обозначать разное. А раз так, то ссылка на «общепринятое» не канает. Общепринятое — это архитектура. С уточнением, при необходимости, о том какого именно узла архитектура.

Вот вам ссылка на то, как именно определяются понятия "архитектура" и "микроархитектура" для процессоров, от самого ARM Holding: https://developer.arm.com/architectures/cpu-architecture
Можете посыпать голову пеплом.

Смотрите. И уж поверьте — он далеко не единственный.

Cortex-A53 и Cortex-A72 имеют абсолютно одну и ту же архитектуру, просто второй сильно "жирнее" по производительности и потреблению. А 2xCortex-M4F вообще являются тут не CPU ядрами, а просто дополнительными контроллерами, которые могут выполнять разные служебные задачи, и не участвуют в выполнении основного потока инструкций CPU.

Простите, но вы несёте херню тоннами.


Я, например, прекрасно помню ARM926-EJS (на котором Intel и отказался от ARM, решив сосредоточится на x84/x64 продав свою серию PXA). Вполне себе предшественник A7.

Примерено так же как VIA C3 предшественник Intel Core. Из общего у них только то, что их системы команд (разные) были разработаны в холдинге ARM.


Вообще, господа жонглирующие терминами «микроахитектура», а расскажите мне серому (лучше в виде статьи) чем же микроархитектура отличается от макроархитектуры?

То, что принято называть "архитектурой" — это система команд. Она накладывает некоторые ограничения на то, как может быть спроектирован процессор, но не является определяющей.
А вот внутреннее устройство CPU определяется микроархитектурой. Ссылки найдёте в сносках, это настолько общепринятые понятия, что ваше с ними незнакомство выглядит как минимум странно.


Этакий «черный ящик», который у нас лучше, чем у конкурентов. И на вопрос «Чем именно лучше?» всегда дается один ответ: «Чем у конкурентов!». Я не буду называть тех, кто подобным грешит. Думаю, те кто реально работает с нужным уровне их и так знают.

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


Ну очевидно же, что Apple, которая лицензирует ядро ARM, никак не может заставить его работать в разы быстрее, нежели конкуренты.

Они не лицензируют ядра у ARM. Они лицензируют систему команд AArch64, которая была создана во многом под их же влиянием.
Начиная с A6 Apple строит процессоры на своих ядрах. Их разработка началась с покупки компании P.A. Semi в 2008 году, а затем Intrinsity в 2010.
Айфоны с A7 — первым 64-битным ARM процессором в мире — были выпущены на прилавки ещё до того, как ARM Holding завершил проектировать свои референсные ядра "на бумаге", что для остальных производителей ARM решений было серьёзным потрясением.


Почему многоядерные ARMы для промышленных железок (да и для телефонов) очень часто содержат разнородные ARMы (часть ядер 64 разряда, часть 32, а в довесок еще и какой-нить Cortex-M)?

Покажите мне "разнородный" процессор с ядрами разной архитектуры.
Обычно используются ядра с разным энергопотреблением — для разных задач. В M1 есть 4 производительных ядра — для тяжёлых вычислений и 4 энергоэффективных — для служебных процессов, нетребовательных потоков, фоновой работы в режиме "сна".
Intel, кстати, в эту же сторону наконец пошёл — смотрите на Lakefield и Alder Lake.

"Специальные версии" — это интегрированные решения вроде Tegra, там свои заморочки.
А обычные карты от NVidia или AMD работают так же как с x86. Вот линуксовые бинарные драйвера NVidia под ARM32 и ARM64, у AMD драйвера в ядре.


Основная проблема с заведением карт под ARM — найти платформу с PCIe. Например, официальных Windows-on-ARM девайсов с PCIe/Thunderbolt пока не существует, поэтому и драйверов никто не собирал.

Насколько я читал, с thunderbolt носителя макось грузится (с обычного USB пока нет), но чтобы её туда установить надо повозиться.
Всё, что касается загрузки, сейчас активно дорабатывается со стороны Apple, поэтому если эта возможность критична, я бы мониторил macforums и ждал больше успешных историй.

Это не костыль. У разных людей разные требования к количеству памяти, поэтому для рабочих станций вроде Mac Pro имеет смысл память делать расширяемой. Но при этом memory-on-package в любом случае быстрее, и такая гибридная система может иметь смысл.

Задержки до памяти в слотах будут немного выше, чем до on-package.
Но, скорее всего, память будет использоваться именно как память, просто ОС будет прозрачно перемещать активное приложение с данными в память поближе.

Information

Rating
4,118-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity