Он вроде мега-теорему миллениума доказал на тему топологии. Там всё упиралось в некие «сигарообразные отростки» в 4D. На голых цифрах и леммах такое сложно вывезти, только имея представление в голове.
«Описать» и «Представить» — разные вещи. По второму пункту даже 4D не всем удаётся (на этом Перельман выехал). Всякие тессеракты, шары с шаром-бликом внутри, бутылки кляйна и т.п. как-то не очень работают, это всё аналогии. От своей нейронки скажу, что ближе всего дорога в 4D — представить 4 пересекающиеся в одной точке прямые и потом долго упорно убеждать мозг, что они друг другу перпендикулярны.
Я слышал, что безопаснее всего в хвосте — были преценденты даже в маза рашше. Тупо собираешь всех креслами, кто спереди. Дурной экспериенс, но мало ли.
Еще не забываем, что HDMI определённых версий «читерит», сжимая контент с компрессией по 2-пикселя на оттенок (как в NTSC), поэтому либо HDR, либо 4/8k, либо 100Hz, либо компромисс между этими тремя параметрами. Банально bandwidth Gb/sec не хватает (ситуация могла измениться за последние пару лет).
Я думаю, Intel пролетел с Itanium из-за наличия на рынке Sun SPARC со всем Solaris обвесом. Сейчас история могла бы быть другой. Плюс сейчас докеры, cpp-to-js-to-llvm-to-whatever, opensource-with-cmake, железо всё меньшую роль играет в vendor lock-in.
Если мир туда покатится, то вкупе с планами nVidia закоротить SSD напрямую в GPU (как NVMe в сторону CPU) — есть повод создать стартап по написанию BIOS'ов/UEFI/whatever для GPU bootloader'ов :) ru.wikipedia.org/wiki/Larrabee
Ну оно так себе «интегрировано», просто вплотную interposer влепили прямо к чипу, если вот эти синенькие фиговины — чипы памяти. Зато решили вопрос с нагревом :)
На XBox One, на сколько помню, диалект DirectX 11.1 (Durango) с некоторыми доп-фишками на Map/UpdateResource для UMA. На PS4 примерно та же песня на свой ляд (забыл название API). На Win10 DirectX12 давно уже работает что на встроенных в проц, что на внешних видяшках.
Вроде не только docs.microsoft.com/en-us/windows/win32/direct3d12/memory-management-strategies
Технически, по идее, не должно быть препятствий, чтобы писать в ту память хоть прямо из user-space (окромя concurrency с другими приложениями). Ну и если не из user-space, то в любом случае это будет kernel memcpy, а не проброс по PCI-E.
Перевод, вроде, нормальный. У меня больше нарекания по исходному контенту.
0. Интегрированные видяшки на x86 тоже UMA (unified memory architecture).
1. Intel/AMD — тоже SoC. Южные мосты вроде как в прошлом (т.е. в чипе).
2. Почти всё начало статьи подаётся как будто в x86 нет out-of-order-execution.
3. Ничего не сказано про просуперскалярность — тут было бы к месту.
4. Ничего не сказано про branch prediction — тоже было бы к месту.
5. Ощущение, что местами hyper-threading перепутан с out-of-order-execution.
6. Но главное, что добило:
Если мы запишем результат 03 перед тем, как начнет выполняться операция 02, то вторая операция получит неверные входные данные
Есть такое понятие как 'registry file' — r1 в первых двух командах и r1 в третьей технически будут разными 'r1' (этих «слотов» в современных процессорах как бы не 128-1024, точных цифр не знаю).
По итогу — кроме fixed-instruction-length на декодерах разницы вроде и не видно.
Там вроде бэкграунд тоже параллаксится. Мне что в глаза бросилось — слишком ранний culling символов. К примеру, слэши синих конусов в фоне исчезают, когда становятся незаметны лишь частично, а не целиком.
ru.wikipedia.org/wiki/Larrabee
docs.microsoft.com/en-us/windows/win32/direct3d12/memory-management-strategies
Технически, по идее, не должно быть препятствий, чтобы писать в ту память хоть прямо из user-space (окромя concurrency с другими приложениями). Ну и если не из user-space, то в любом случае это будет kernel memcpy, а не проброс по PCI-E.
0. Интегрированные видяшки на x86 тоже UMA (unified memory architecture).
1. Intel/AMD — тоже SoC. Южные мосты вроде как в прошлом (т.е. в чипе).
2. Почти всё начало статьи подаётся как будто в x86 нет out-of-order-execution.
3. Ничего не сказано про просуперскалярность — тут было бы к месту.
4. Ничего не сказано про branch prediction — тоже было бы к месту.
5. Ощущение, что местами hyper-threading перепутан с out-of-order-execution.
6. Но главное, что добило:
Есть такое понятие как 'registry file' — r1 в первых двух командах и r1 в третьей технически будут разными 'r1' (этих «слотов» в современных процессорах как бы не 128-1024, точных цифр не знаю).
По итогу — кроме fixed-instruction-length на декодерах разницы вроде и не видно.