Консорциум Khronos, занимающийся разработкой графических стандартов,
опубликовал (https://www.khronos.org/news/press/khronos-group-releases-vu... спецификацию Vulkan 1.1 (https://www.khronos.org/vulkan/), определяющую API для доступа к графическим и вычислительным возможностям GPU. Новая спецификация вобрала в себя накопившиеся исправления и ознаменовала включение в основной состав расширений (https://www.khronos.org/registry/vulkan/#apispecs), подготовленных за два года с момента публикации первой версии API. Драйверы с поддержкой новой версии Vulkan уже выпустили компании Intel (https://lists.freedesktop.org/archives/mesa-dev/2018-March/1... AMD (AMDGPU-PRO (https://support.amd.com/en-us/kb-articles/Pages/Radeon-Softw... и AMDVLK (https://github.com/GPUOpen-Drivers/AMDVLK)) и NVIDIA (https://developer.nvidia.com/vulkan-driver). Поддержка Vulkan 1.1 также принята в кодовую базу Mesa для драйверов RADV (https://lists.freedesktop.org/archives/mesa-dev/2018-March/1... (карты AMD)) и ANV (https://lists.freedesktop.org/archives/mesa-dev/2018-March/1... (Intel).
Основные новшества (https://www.khronos.org/assets/uploads/developers/library/ov...:
- Представлена новая спецификация SPIR-V 1.3 (https://www.khronos.org/registry/spir-v/), определяющая универсальное для всех платформ промежуточное представление шейдеров, которое может применяться как для графики, так и для параллельных вычислений.
SPIR-V подразумевает выделение отдельной фазы компиляции шейдеров в промежуточное представление, что позволяет создавать фронтэнды для различных высокоуровневых языков. На основе различных высокоуровневых реализаций отдельно генерируется единый промежуточный код, который может использоваться драйверами OpenGL, Vulkan и OpenCL без применения встроенного компилятора шейдеров;- Защищённый контент (Protected content) - возможность ограничения доступа и копирования ресурсов, используемых для рендеринга и отображения, а также возможность организации воспроизведения и отображения защищённого мультимедийного контента;
- Операции с подгруппами (Subgroup) - предоставляют эффективный механизм для организации работы с параллельно вызываемыми шейдерами, взаимодействующими между собой. Под подгруппой подразумевается набор вычислительных задач, выполняемых на GPU. Для применения предоставлена коллекция различных моделей параллельных вычислений.
- Multiview (K_KHR_multiview (https://www.khronos.org/registry/vulkan/specs/1.1-extensions... - в рамках одного прохода рендеринга может одновременно отрисовываться несколько изображений, что может применяться для отрисовки одним вызовом левой и правой частей изображения для шлемов виртуальной реальности или для отображения шести сторон на кубической раскладке текстуры;
- Device Groups (VK_KHR_device_group (https://www.khronos.org/registry/vulkan/specs/1.1-extensions... - для организации однородных вычислений для высокопроизводительных игр или шлемов виртуальной реальности на системах с несколькими GPU, таких как AMD CrossFireX и NVIDIA SLI. Для приложения взаимодействие с Device Group производится как с одним GPU, независимо от того сколько фактически GPU входит в группу;- Совместный доступ к ресурсам между процессами и API (Cross-process и Cross-API Sharing) - позволяет использовать блок разделяемой памяти и примитивы синхронизации между несколькими приложениями или разными API в одном приложении. Например, можно получать изображения для композитинга для вывода на одном экране
из разных приложений Vulkan и OpenGL ES- Расширенные возможности для вычислений: поддержка чтения и записи 16-разрядных величин, хранящихся в памяти GPU, и обращения к структурам данных, используя урезанную форму указателей. Значительное расширение поддержки вычислительных ядер GPU;
- Поддержка языка программирования шейдеров HLSL (https://ru.wikipedia.org/wiki/HLSL), разработанный Microsoft для DirectX. Поддержка HLSL позволяет увеличить гибкость блочной компоновки элементов при сохранении старой раскладки данных в памяти и обеспечить возможность использования одних HLSL-шейдеров в приложениях на базе Vulkan и DirectX, а также упростить трансляцию из HLSL в SPIR-V;
- Поддержка текстур, оформленных с использованием цветового пространства YCbCr (https://ru.wikipedia.org/wiki/YCbCr). Полезно для организации композитинга видеопотоков и их смешивания с другим графическим контентом.
Напомним, что API Vulkan примечателен (https://www.opennet.dev/opennews/art.shtml?num=43887) кардинальным упрощением драйверов, выносом генерации команд GPU на сторону приложения, возможностью подключения отладочных слоёв, унификацией API для различных платформ и применением предкомпилированного промежуточного представления кода для выполнения на стороне GPU. Для обеспечения высокой производительности и предсказуемости, Vulkan предоставляет приложениям средства для прямого управления операциями GPU и встроенную поддержку многопоточной обработки команд GPU, что минимизирует накладные расходы, вносимые драйвером, а реализуемые на стороне драйвера возможности заметно упрощаются и становятся более предсказуемыми. Например, такие операции, как управление памятью и обработка ошибок, реализуемые в OpenGL на стороне драйвера, в Vulkan вынесены на уровень приложения.
Vulkan охватывает все доступные платформы и предоставляет единый API для настольных, мобильных систем и Web, позволяя использовать один общий API для различных графических процессоров и областей применения. Благодаря многослойной архитектуре Vulkan, подразумевающей создание инструментов, работающих с любыми GPU, производители оборудования могут использовать при разработке типовые инструменты для проверки кода, отладки и профилирования. Для создания шейдеров предлагается новое переносимое промежуточное представление SPIR-V, основанное на LLVM и использующее общие с OpenCL базовые технологии. Для управления устройствами и экранами в Vulkan предлагается интерфейс WSI (Window System Integration), решающий примерно те же задачи, что и EGL в OpenGL ES. Поддержка WSI из коробки доступна в Wayland - все приложения, использующие Vulkan, могут запускаться в окружении немодифицированных серверов Wayland. Возможность работы через WSI также обеспечена для Android, X11 (c DRI3), Windows, Tizen, macOS и iOS.
URL: https://www.khronos.org/news/press/khronos-group-releases-vu...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48227
Кардинальное упрощение, в 1.1 уже кучу всего добавили, а к 4.5 какой-нибудь будет тот еще монстр.
Нет. OpenGL изначально задумывался как stateful api и был заточен на сильно другую модель вычислений, господствовавшую в 90х.
Упрощение драйверов, но усложнение пользовательского кода
Тогда уж усложнение кода движков, а не пользовательского кода.
Именно пользовательский код, для получения выигрыша производительности нужно оптимизировать готовый проект. Простое включение низкоуровнего апи в 3д-движке даст штраф к призводительности в сравнении с классическими апи.
> Простое включение низкоуровнего апи в 3д-движке даст штраф к призводительности в сравнении с классическими апи.Это предположение такое или был опыт?
Осталось лишь xbill портировать.
Основные улучшения: DRM и поддержка поделки MS в качестве стандартного высокоуровневого шейдерного языка. Чувствую, не пойдет он, не пойдет...
Что ещё за поделка M$?
>Поддержка языка программирования шейдеров HLSL, разработанного Microsoft для DirectX
Без этого и не пойдёт. А так, универсальный инструмент.
Где не пойдёт? У вас? Почти уверен, что так и будет. Будете по новой свои вайны распиливать.
А чему тут не идти? Считай hlsl на любой тостер с поддержкой vulkan 1.1 завезли.
Такая параша этот DRM все элементарно снимается платой захвата, которая к тому же стоит копейки.
Жаль маловато статей с похороникса переводят. Я бы еще добавил вулканих новостей:
1. Открыт MoltenVK. И через MoltenVK работает шустрее чем openGL
2. с версией 1.1 появилась возможность написать wayland композитор чисто на вулкане. Без всяких EGLStreams, GBM..
>с версией 1.1 появилась возможность написать wayland композитор чисто на вулкане. Без всяких EGLStreams, GBM.Осталось найти видеокарты, которые полноценно поддерживают vulkan 1.1, а то чуть копнешь, оказывается GTX 6xx и GTX 7xx даже 1.0 поддерживают частично.
>>с версией 1.1 появилась возможность написать wayland композитор чисто на вулкане. Без всяких EGLStreams, GBM.
> Осталось найти видеокарты, которые полноценно поддерживают vulkan 1.1, а то чуть копнешь,
> оказывается GTX 6xx и GTX 7xx даже 1.0 поддерживают частично.3dfx вообще отлетает
И все интелы. Intel ANV есть, но там далеко не всё.
>> GTX 7xx даже 1.0 поддерживают частично.Это хреново, но хреново также и то, что эти карты и DirectX 11 не полностью поддерживают, а ведь он появился впервые на 400 серии.
>>с версией 1.1 появилась возможность написать wayland композитор чисто на вулкане. Без всяких EGLStreams, GBM.
> Осталось найти видеокарты, которые полноценно поддерживают vulkan 1.1, а то чуть копнешь,
> оказывается GTX 6xx и GTX 7xx даже 1.0 поддерживают частично.Осталось найти бабосы, что бы приобрести все эти новомодные видеокарты.
>> оказывается GTX 6xx и GTX 7xx даже 1.0 поддерживают частично.
> Осталось найти бабосы, что бы приобрести все эти новомодные видеокарты.Работать+копить пробовали..?
Айфон у тебя точно последний?
Geforce 1030 стоит от 5к новая, да и какую-нибудь 950 можно на барахолке взять.
Ну и МП, поддерживающую PCI-E 3.x, к ней проц на новом сокете + память, скорее всего. При этом нужно не забыть про блок питания, который также придётся заменить. Если, конечно, у вас изначально не было БП с запасом мощности в +300 Вт только для видяхи...И посути всё это только для того, чтобы показывать вам wayland композитор на чистом вулкане. :-\
Ну не знаю... Ваши деньги, вам решать куда их тратить. Мне как-то через традиционные иксы всё зае..сь показывается. :-) Так было 20 лет назад, на S3 Savage/Virge, так есть сейчас. :-) Да и лишних денег, чтобы покупать не нужные мне железяки у меня нет. :-\
> Ну и МП, поддерживающую PCI-E 3.xНе надо.
> При этом нужно не забыть про блок питания, который также придётся заменитьТоже не надо. Она жрёт то, что-то в районе 30 ватт. Тоесть добротного 300 ватного блока питания хватит.
Wayland не работает на чистом вулкане, просто есть такая возможность запилить композитор, которой может быть даже не займутся разрабы (надеюсь займутся)
Надо быть кем чтобы видеокарту за 5к покупать? Вы в своём мкаде совсем...
> Надо быть кем чтобы видеокарту за 5к покупать? Вы в своём мкаде
> совсем...Да не про это речь. Понятно, что где-то, например у меня на Урале, это реально ползарплаты (есть такие места, где платят по МРОТ). Суть ведь в том, что это навязанная гонка апгрейдов и реальной необходимости в GNU/Linux в ней нет. А в GNU/HURD и в *BSD и тем паче. :-\
>с версией 1.1 появилась возможность написать wayland композитор чисто на вулканетеоретически да, но на практике там пока много ограничений, и на полноценную замену GBM оно не тянет. Ждем Vulkan 1.2 и т.д.
Новых аппаратных возможностей GPU не потребуется? Типа как при переходах от DX9 к DX10 и потом к DX11.
Вроде нет. Да рано пока отрубать.
С версией 1.0 поддерживались этак GPU с 2012 года.
Пока ещё не мамонтовый того самого камень.
так написали же - для возможности использовать Vulkan 1.1 на GPU Intel необходимо наличие чипов Intel Broadwell "Gen 8" и более новых
броадвэл это пятое а не восьмое
> Поддержка языка программирования шейдеров HLSL, разработанного Microsoft для DirectXОни его уже открыли?
> Они его уже открыли?Ты на LFS что ли сидишь? Наберёшь `apt-get install mms-hlsl` и всё заработает, какие проблемы. Вот у rust есть исходники, и что с них? Чтобы собрать всё равно надо скачать блоб с сайта мозиллы. Ну и много с этих "исходников" проку?
>Вот у rust есть исходники, и что с них? Чтобы собрать всё равно надо скачать блоб с сайта мозиллыВот у gcc есть исходники, и что с них? Чтобы собрать всё равно надо скачать блоб с сайта $DISTRONAME
Ты про бутстрап (не путать со страпоном) что-нибудь слышал, анонимный брат?
> Вот у gcc есть исходники, и что с них?Вас таких нарожали а обучить забыли?
Вы точно прочитали то, на что отвечали? Суть моего поста сводилась не к тому, чтобы устроить перепись тех, кто слышал про бутстраппинг но неправильно его понял. А к тому, что для таких как вы (в том числе) исходники не нужны. Вы набираете `apt-get install чтототам`, а остальное за вас делают волшебники-мейнтейнеры. Вас вообще не волнует, что и как у них там происходит, и появление всяких openjdk и rust, которые невозможно собрать, не имея УЖЕ СОБРАННОЙ версии их самих, - лучшая демонстрация этого подхода. Оно там как-то поставилось, кто-то как-то это собрал, галочку "есть исходники" поставили, вам и достаточно. А вы всем остальным начинаете плести какие-то оправдания про бутстраппинг и прочее. Не надо.
Если завтра в вашем дистрибутиве начнут поставлять файрфокс не собранный мейнтейнерами, а просто скачанный с сайта мозиллы и перепакованный, вы даже не заметите. Если ещё через год мозилла закроет исходники, вы не заметите тоже. Стоит ли кричать про "открытые исходники" в таком случае? Зачем кому-то давать вам исходные коды, если вы ими не пользуетесь?
С исходников gcc мне то, что если у меня есть компьютер, то там уже есть С/C++ компилятор, которым эти исходники можно собрать. Мне НЕ НУЖНО качать с сайта gcc его бинарник, чтобы его самого же собрать. Могу собрать силангом или микрософтским компилятором или тем что уже есть.
C/C++ сегодня есть в каждой системе, это основа современного софта. Если вы пишете на C/C++, ваш софт можно собрать (возможно с хаками) для любой архитектуры и для любой операционки. А если вы придумали свой новый язык, для сборки компилятора которого нужен он сам, то со своим аутизмом вам лучше показаться профильному специалисту, а не хвастаться этим на форумах. И заметьте, gcc написан не на rust, который вообще неясно как и где брать для архитектур, отличных от мейнстрима; gcc написан на стандартном для такого рода софта языке - на C/C++.
>[оверквотинг удален]
> же собрать. Могу собрать силангом или микрософтским компилятором или тем что
> уже есть.
> C/C++ сегодня есть в каждой системе, это основа современного софта. Если вы
> пишете на C/C++, ваш софт можно собрать (возможно с хаками) для
> любой архитектуры и для любой операционки. А если вы придумали свой
> новый язык, для сборки компилятора которого нужен он сам, то со
> своим аутизмом вам лучше показаться профильному специалисту, а не хвастаться этим
> на форумах. И заметьте, gcc написан не на rust, который вообще
> неясно как и где брать для архитектур, отличных от мейнстрима; gcc
> написан на стандартном для такого рода софта языке - на C/C++.Браво, Вася! Держи + за характер!
Вы что сказать вообще хотели? Действительно... где вас таких рожают.
> С исходников gcc мне то, что если у меня есть компьютер, то там уже есть С/C++ компилятор, которым эти исходники можно собрать. Мне НЕ НУЖНО качать с сайта gcc его бинарник, чтобы его самого же собрать. Могу собрать силангом или микрософтским компилятором или тем что уже есть.Т.е. всё отличие в том, что этот блоб для сборки GCC тебе уже всунули и не надо его качать? Тебя это успокаивает?
Компиляторы эти (силанг, мсовский или тем что уже есть) ты собирать будешь? Или расхотелось? Чем ты лучше набирающих апт-гет инстал?
> всё отличие в том, что этот блоб для сборки GCC тебе уже всунули и не надо его качать? Тебя это успокаивает?По сути да. Но не просто "уже всунули", а "уже всунули в любой существующий компьютер" и "если всунутый не работает, можно взять другой". Чувствуете разницу? Например, sbcl для сборки требует установленный компилятор common lisp. Но не требует СЕБЯ. То есть я могу взять систему, на которой НЕТУ собранного sbcl и собрать его под неё (например, собрав сишным компилятором clisp, а уже им собрать sbcl). Это и есть бутстраппинг. А не требование скачать уже собранный дядей блоб для сборки бинарника самому.
Когда раст будет иметься в ЛЮБОЙ существующей системе, у меня претензий больше не будет. Проблема в том, что согласно рассуждающим об IT-эволюции, этого никогда не будет. Сейчас модно постоянно переделывать основы, выкидывая существующий софт и пиша к нему недоношенные замены, которые потом снова выбрасываются. И большинство таких, как iPony, этому рады. Раст помрёт раньше, чем будет перенесён на другие системы (в смысле, не на ТРИ другие системы, а на ВСЕ другие системы).
> Компиляторы эти (силанг, мсовский или тем что уже есть) ты собирать будешь?
Буду, если будет нужно. И в отличие от раста, у меня ЕСТЬ такая возможность. Для сборки же раста мне НЕОБХОДИМО качать блоб без возможности его сборки (и уже им собирать себе бинарник).
> Чем ты лучше набирающих апт-гет инстал?
Не испытываю иллюзий насчёт "а у него исходники открыты?". Ещё раз для пропустивших начало обсуждения: я не говорю, что я лучше, я спросил зачем конкретно тому человеку исходники микрософтской приблуды, будет ли он их реально использовать, или просто очередной кукаретик, пользующийся apt-get-ом. Раст просто в тему оказался.
Я в общем согласен, но, как ни крути, полный бутстрап с нуля сейчас делают разве что для развлечения. А "для архитектур, отличных от мейнстрима" собирают обычно всё же кросс-компиляцией.
Это же настолько надо обдолбаться, что слов нет...> C/C++ сегодня есть в каждой системе, это основа современного софта.
Суть эволюции в IT и состоит в том, что основы - это не намертво вбитое, дарованное с не бес что-то без недостатков.
> Суть эволюции в IT и состоит в томРаскройте, пожалуйста, мысль, что такое эволюция в IT и в чём она проявляется. А то судя по вашему комментарию может создаться впечатление, что эволюция - это когда всё устаревает каждые два года, и всё приходится делать по-новому, так что опыт (ценный в других профессиях) ничего не стоит, и каждые два года люди с опытом оказываются на равных с только что закончившими школу.
Кроме того, есть следующие способы написать компилятор экзотического языка:
1. написать его на другом языке, повсеместно распространённом,
2. написать его на повсеместно распространённом языке, собрать бинарник, потом переписать на самом себе, попутно убрав возможность сборки нормальным компилятором, и заставлять всех качать себе этот блоб для сборки самого себя "из исходников",
3. то же, что и п.2, но оставить возможность сборки распространённым компилятором,
4. распространять его только в бинарной форме, пользователям всё равно, а мейнтейнеры будут вынуждены использовать этот блоб, если переписать на нём что-нибудь популярное, например половину всех современных браузеров (читать как "файрфокс").Можете расположить их по увеличению степени IT-эволюционности и объяснить свой выбор, пожалуйста?
> судя по вашему комментарию может создаться впечатление, что эволюция - это когда всё устаревает каждые два года, и всё приходится делать по-новому, так что опыт (ценный в других профессиях) ничего не стоит, и каждые два года люди с опытом оказываются на равных с только что закончившими школу.Да, именно так. Это плата за скорость эволюции, которая продолжает экспоненциально зависеть от времени. В середине XX века знания устаревали лет 30, в конце XX века, время устаревания знания было где-то в районе 10 лет, сейчас знания устаревают менее чем за пять. Уже давно ценятся не столько знания, сколько способности эти знания обретать по необходимости. Но это что, то ли ещё будет, по мере приближения к точке технологической сингулярности. Уже сейчас мы видим стонущих айтишнегов, которые явно не справляются и отстают от паровоза. Со временем их будет всё больше и больше. А если этот экспоненциальный рост экстраполировать в будущее подальше, то мы придём к ситуации, когда никто не сможет поспевать за прогрессом. А это гарантия, что скучно не будет. Будущее обещает нам быть весёлым и увлекательным -- не просто унылым многократным повторением прошлого, а чем-то новым, неизведанным и несущим новые возможности.
> Кроме того, есть следующие способы написать компилятор экзотического языка:
Если мы говорим про rust, то надо добавить п.5:
> 5. написать его на _экзотическом_ языке, собрать бинарник, потом переписать на самом себе, попутно убрав возможность сборки экзотическим компилятором, и заставлять всех качать себе этот блоб для сборки самого себя "из исходников"
Первый компилятор rust'а был написан на OCaml'е.
> Уже давно ценятся не столько знания, сколько способности эти знания обретать по необходимости.Нет. Это только разговоры. Об обретении знаний речи не идёт - кому это надо, если потраченное на "обретение знаний" время по сути будет выкинуто в утиль? Сейчас ценится способность сделать кое-как но быстро. По сути, способность достигать результата, не имея знаний.
> Уже сейчас мы видим стонущих айтишнегов, которые явно не справляются и отстают от паровоза.
Причина стонов не в "не справляются", а в том, что их выкидывают из зоны комфорта. Они привыкли в случае проблем разбираться, почему что-то не работает, и на основании этого накапливать опыт и становиться более профессиональными и высокооплачиваемыми сотрудниками. А тут их заменяют вчерашними студентами, потому что сделать по инструкции из гугла много ума не надо, а в случае малейших проблем просто удаляется виртуалка, создаётся новая и система восстанавливается из бэкапа. В крайнем случае их пригласят, они починят проблему за час, а вся честь достанется студенту, соорудившему неработающего монстра.
Кроме того, жаль осознавать, что всё хорошее, чем ты жил и к чему стремился, объявлено ненужным и заменяется полурабочими дешёвыми альтернативами.
Но! Есть надежда, что это ненадолго. Хипстеры привыкли создавать полурабочие решения на базе проверенных временем отлаженных надёжно работающих, да к тому же часто бесплатных, и продавать свои недоделки за большие деньги. Но что они будут делать, когда основа, на которой строят они, станет того же качества?
Пример из жизни: берём рабочий, отлаженный, бесплатный похапе, костылим монструозный полурабочий битрикс, продаём за миллионы. И всё было хорошо, пока недавно руководитель битрикса не напоролся на таких же, как он сам, овноделов. Когда оказалось, что весь их Битрикс24, якобы надёжно резервированный вторым облаком, накрылся медным тазом, включая резервное облако, потому что у хостера оба облака подключались через ОДИН канал и упал железка, отвечающая за этот канал. Рыжиков на овно исходил в фейсбуке, визжа как истеричка, после чего в истерике мигрировал на другого хостера.
> Первый компилятор rust'а был написан на OCaml'е.
Я пропустил этот пункт, так как сам OCaml собирается из сишных исходников, и тут проблемы никакой нет.
> Но! Есть надежда, что это ненадолго. Хипстеры привыкли создавать полурабочие решения на
> базе проверенных временем отлаженных надёжно работающих, да к тому же часто
> бесплатных, и продавать свои недоделки за большие деньги. Но что они
> будут делать, когда основа, на которой строят они, станет того же
> качества?Перепишут основу. Вон недавно в новостях проскакивало про Atom, который оказался слишком тормозным, и поэтому гугел переписал критические для производительности части c js на rust'е, чтобы они работали быстрее.
> Пример из жизни: берём рабочий, отлаженный, бесплатный похапе, костылим монструозный полурабочий
> битрикс, продаём за миллионы. И всё было хорошо, пока недавно руководитель
> битрикса не напоролся на таких же, как он сам, овноделов. Когда
> оказалось, что весь их Битрикс24, якобы надёжно резервированный вторым облаком, накрылся
> медным тазом, включая резервное облако, потому что у хостера оба облака
> подключались через ОДИН канал и упал железка, отвечающая за этот канал.
> Рыжиков на овно исходил в фейсбуке, визжа как истеричка, после чего
> в истерике мигрировал на другого хостера.Именно поэтому хипстеры не используют битриксы, они больше по всяким там RoR тащились, затем по node.js, и я не удивлюсь, если в обозримом будущем они пересядут на rust или go.
Это именно так и работает -- строится полурабочая система, но большая и сложная, позволяющая набрать опыт работы с такими большими и сложными системами. Затем с учётом обретённого опыта строится более рабочая система, затем ещё более рабочая, а затем всё доходит до... До уровня rust'а, например -- я тут заглянул в тему веб-программирования на rust'е, поскольку мне потребовался сайт на три странички, с большим количеством client-side кода и тупеньким сервером. Ну и не буду же я писать всё это на js? Нет конечно, и к похапэ я не прикоснусь. А как ещё это можно сделать? Нормальный язык компилируемый в WebAssembly и что-нибудь нормальное же для сервера. Ну и в силу увлечённости rust'ом я взял rust для всех этих целей.
Выводы. Rust ещё не дорос до Ruby on Rails: нет того уровня интеграции компонентов, кое-какие вещи (скажем возможности тестирования веб-приложения, которые есть в Rails) отсутствуют, плюс не хватает "отполированности" -- когда ошибка компилятора о несовпадении SQL-схемы и rust'ового типа для описания строки таблички выглядит как два экрана 80x25 плотно забитых символами без переводов строк и практически без пробелов -- это конечно ни в какие ворота не лезет.
Но в общем вектор развития и скорость его, наводят на мысль, что лет через пять rust вполне сможет конкурировать с RoR не только сложностью освоения, но ещё и удобством и функциональностью. При этом сложность освоения, в случае rust'а, на мой взгляд меньше, поскольку статическая типизация позволяет находить ошибки на более ранних этапах.
То есть, я к чему, хипстерские подходы были отработаны в RoR, node.js и пр, и сейчас они доросли до уровня, когда их можно реализовать на статической типизации, на статическом управлении памятью и на т.н. zero-cost абстракциях. И именно это и происходит сейчас.
Гуманитарий обнаружен. Простыня и ноль конкретики. Такие люди обычно и пользуют гном и рассказывают про прогресс
> экспоненциально зависеть
> точке технологической сингулярности
> экстраполироватьМахровый технарь.
С таким долбанутым мозгом ты бы мог оставаться в времена до C. Действительно нафига что-то придумывать и пытаться улучшить если тебе всунули уже B/ASM/etc нафига тебе C?То что тебе в дистрибутив всунули gcc/clang не значит что он есть везде и уж тем более не значит что тебе на нём(С/С++) должны писать и остальные языки.
Развелось укурков без мозгов.
> не значит что он есть вездеНазовите, пожалуйста, 2-3 системы, на которых нет сишного компилятора.
> Назовите, пожалуйста, 2-3 системы, на которых нет сишного компилятора.за примерами далеко ходит не надо. винда и os x
По всем дистрам не спец, но в debian он не входит в список необходимых пакетов и дистрибутив может быть развёрнут без него. Полагаю в абсолюбном большинстве не source based дистрибутивов он может быть либо выпилен либо не идти в поставке, а ставиться при надобности.
> винда и os xНу конечно, две системы, написанные на сях и большая часть софта для которых написана на сях, не имеют сишного компилятора. Такие две системы, скорее, - KolibriOS и Redox. И для протокола: имхо сишный компилятор для redox должен быть будет написан на расте, так как там раст будет тем же, чем для нынешних систем является си. Или, по крайней мере, бутстрапиться из чего-то, что может быть собрано растом.
А если говорить про дебиан, то вернёмся к тому, с чего началась эта дискуссия: если в дебиане компилятор не входит в список необходимых пакетов, то и ms-hlsl можно будет установить, даже если у него нет открытых исходников. И тогда вопрос, зачем вообще этот исходник нужен.
В колибри есть TCC и сишная библиотека.
>Ну конечно, две системы, написанные на сях и большая часть софта для которых написана на сях, не имеют сишного компилятора.Внезапно огромное количество софта под винды пишется на том же C# И прочих MS only технологиях. У OS X вообще ObjectiveC если говорить о родном платформе софте.
И вообще написание системы на каком либо языке не имеет никакого отношения к тому что в поставке будет компилятор. Да обе системы написаны на C, но что бы что-либо собрать нужно отдельно установить компилятор. Так что никто вам ничего не должен.
>А если говорить про дебиан, то вернёмся к тому, с чего началась эта дискуссия: если в дебиане компилятор не входит в список необходимых пакетов, то и ms-hlsl можно будет установить, даже если у него нет открытых исходников. И тогда вопрос, зачем вообще этот исходник нужен.
Вы такое чувство что не понимаете зависимости/взаимосвязи. Если пакет будет требовать выполнения компиляции и внутри него зашьют сценарий который запустится при установке, то в зависимости внесут зависимость от компилятора, но дебиан это бинарный дистр. Вся пакетная база по умолчанию предоставляется в готовом бинарном виде собранная до вашей машины. Так внимание вопрос зачем бинарному собранному пакету компилятор? Н е нужен. Исключение составляют пакеты для девелоперов и пакеты которые сами используют компилятор в своей работе. Насколько помню у AMD LLVM используется к примеру для компиляции тех же шейдеров. Так что если пакет с шейдерами требует для своей работы компилятор это никак не связано с тем на чём система написана или что там у кого стоит.
> то и ms-hlsl можно будет установить, даже если у него нет открытых исходников. И тогда вопрос, зачем вообще этот исходник нужен.
Представьте себе есть пакеты у которых нету исходников. А можно ли будет установить гипотетический ms-hlsl без компилятора зависит от тех кто его писать будет. Могут написать как AMD с использованием LLVM.
А исходник нужен если ты хочешь проверить бинарник(воспроизвести сборку и проревьювить код) или сам модифицировать и собрать свой бинарник.
----
Админы:
Серъёзно? https://clip2net.com/s/3SxL8iS
> Серъёзно?Да. Учи альтернативные термины. В твоём случае "не имеющий практической уенности"
Производить действия лопатой - это не зака<CENSORED>, а зарывать.
Первопроходец, а не пио<CENSORED>
Не уби<CENSORED> продукт, а прекратить существование/лишить поддержки
И так далее...
> компилятор для redox должен быть будет написан на растепир духа
Простите, вырвалось.
> С таким долбанутым мозгомХорошо, что у вас закончились аргументы. Значит я действительно могу быть прав.
> не значит что тебе на нём(С/С++) должны писать и остальные языки
Это уж как авторы свой язык позиционируют. Если как хипстерскую игрушку, которая помрёт через 5 лет, то можно и не на С/C++, а хоть на брейнфаке. Если как серьёзную вещь, то я лично альтернатив не вижу. А вы можете что-то предложить, аргументированно?
> Развелось укурков без мозгов.
Вы уж разберитесь: без мозгов или с долбанутым мозгом? Даже если у вас не хватает способностей сформулировать свои мысли в одиночку и поэтому вы пишете вдвоём, всё равно выработайте единое мнение, которое и озвучивайте.
>Хорошо, что у вас закончились аргументы. Значит я действительно могу быть прав.А я не пытался аргументировать. Потому что у вас очень замкнутый кругозор если всё сошлось на C.
>Это уж как авторы свой язык позиционируют. Если как хипстерскую игрушку, которая помрёт через 5 лет, то можно и не на С/C++, а хоть на брейнфаке. Если как серьёзную вещь, то я лично альтернатив не вижу. А вы можете что-то предложить, аргументированно?
То есть авторы разрабатывающие язык системного программирования который должен потеснить или(мало ли) заменить C/C++ должны его писать на C/C++, а не на нём самом? Это что за логика такая?
Если они его позиционируют как серьёзного соперника C/C++ в первую очередь они должны написать компилятор его самого на нём же, но никак не должны писать его на C/C++ ради того что бы пара ленивых использовали свой gcc который им любезно подсунули мэйнтейнеры ихнего дистрибутива.
> Потому что у вас очень замкнутый кругозор если всё сошлось на C.Ну, не такой широкий, как у пишущих операционки на php и прочем яваскрипте.
> То есть авторы разрабатывающие язык системного программирования который должен потеснить или(мало ли) заменить C/C++ должны его писать ...
так, чтобы он присутствовал на том же перечне платформ (как минимум), что и C/C++. А этого на данный момент можно достичь только одним способом.
Возможность сборки самим собой могли бы оставить как приятную фишку. Или собирать сями базовую версию раста, а ей уже - полноценный компилятор. Сами-то почему-то первую версию писали на Ocaml (как выше упомянуто), а не сразу на расте? Что же так?
>> То есть авторы разрабатывающие язык системного программирования который должен потеснить или(мало ли) заменить C/C++ должны его писать ...
> так, чтобы он присутствовал на том же перечне платформ (как минимум), что и C/C++. А этого на данный момент можно достичь только одним способом.Уж точно не написав компилятор на C. Ибо это как раз не при чём.
> Возможность сборки самим собой могли бы оставить как приятную фишку. Или собирать сями базовую версию раста, а ей уже - полноценный компилятор.
Ещё раз с какого перепугу сам же Rust должен быть написан на C? Вы поражаете. Rust даёт целую пачку фишек для избежания багов и почему это разработчики компилятора не должны этими фишками пользоваться в самом компиляторе? То что внезапно Rust будет собираться каким-нибудь gcc популярности ему не прибавит, а наоборот создаст только проблемы. Да для старта нужен готовый бинарник раста, но это не трагедия вселенского масштаба как вы пытаетесь это обрисовать.
> Сами-то почему-то первую версию писали на Ocaml (как выше упомянуто), а не сразу на расте? Что же так?
По той же причине по которой первый компилятор C был написан на асемблере.
> То что внезапно Rust будет собираться каким-нибудь gcc популярности
> ему не прибавит, а наоборот создаст только проблемы.В теме о языке Nim с пеной у рта доказывалось, что если язык не собирает себя сам, то это недоязык. Если язык сам себя собирает, то с пеной у рта доказыватеся, что это недоязык, потому что бэкенд недостаточно высокоуровневый, то есть обязательно должен быть бэкенд в виде С или С++ и обязательно JavaScript, чтобы запустить в браузере. Иначе это неразвитый недоязык для маргиналов, когда нормальные, гармонично развитые, программисты должны иметь возможность программировать прямо в браузере, и обязательно на современных платформах типа Electron.
Хотите узнать, что скажет аноним если Rust этим всем обзаведется?
И бутстрап из JavaScript (бутстрап обязательно должен производится в браузере, потому что он у всех есть) в блоб под любою платформу. И JavaScript должен быть не выхлопом фронтенда компилятора, а вручную спроектированным, на худой конец (так уж и быть разрешим) портированным из исходных сырцов с комментариями и зеркалом на ГитХабе. Причем разработчики должны поддерживать перенос внесенных на JavaScript коммитов -=Сообщества=-! в основную ветку, а лучше основной сразу сделать ветку c JavaScript, а шизики пусть сами потом с нормальной LingvaFranka портируют в свою маргинальную поделку
Вот тогда мы будем уважать Rust!!!
Да. Компилятор открыт.
список игр на Vulkan 1.0 в студию!!!!!
Держи дядь Вить
https://en.wikipedia.org/wiki/Vulkan_(API)#Software_that_sup...
топы переходят на вулкан. круть!
О, дум поддерживает Вулкан. Не удивительно, учитывая что его на чём только ни запускали, даже на 8 бит. Но зачем?
Так это новый Дум. Старый, "тот самый" Дум либо еще не портировали, либо я что-то проспал. Хотя я ожидал, что его портируют одним из первых.
DotA 2
https://pcgamingwiki.com/wiki/Property:Vulkan_versions+ c развитием всяких vkd3d, dxvk, ... к ним добавятся еще и те что сейчас на dx9/11/12
> список игр на Vulkan 1.0 в студию!!!!!Спрашивали - отвечаем.
http://fte.triptohell.info/Порт Ку1 и ещё некоторых, переключабельно на сабж v.1.
>Защищённый контентобидно, что авторы апи для гпу прогибаются под копирастов. Интересно, как обстоят дела с данной фичей на свободных дровах
Тебе же объявили список поддержки. Там нечего читать между строк.
>>Защищённый контент
> обидно, что авторы апи для гпу прогибаются под копирастов. Интересно, как обстоят
> дела с данной фичей на свободных дровахЧерез микрокоды, ваш кэп.
А микрокод подписан? Потому что без hardware root of trust копирастов всегда можно слать на суд. А единственная сила hardware root of trust в том, что дорогое оборудование (видеокарта) портится (и в большом количестве, и для этого нужно ещё намного более дорогое оборудование и расходники, у нищебрoдов денег нет, а у кого есть - тех легко по ним и закупкам/арендам и доступу к оборудованию отследить и посадить). Это если в чип не зашит уникальный идентификатор. Если же зашит - то вообще дело дрянь, ключ от одного чипа к другому не подойдёт, покупателя легко отследить по номеру чипа, как и шпионить за каждым арендатором видеокарты, пошли они с такими чипами, когда же будет десктопная видюха с mali?
Вернее чушь я смолол. В чипе же публичный ключ, чтобы его модиифицировать и заливать свой микрокод надо сделать чип неработоспособным.
Да нормально всё.
Щас уже Intel засаживает HDCP
https://www.phoronix.com/scan.php?page=news_item&px=HDCP-2.2...
Скоро сможешь 4K с Netflix на линуксах смотреть (может быть)
> 4K с NetflixЧто ето и для чего надо? Ощущаю отпечаток копыта зомбоящика...
из линейки 480-12K, всё ещё совместимо с 486SX25/Trident512K, только mencoder'ом подаунрейтить надо
Как зачем? Чтобы ты отвалил 35 тысяч рублей за 4к телевизор, модели от гнусмаса с тизер стоят от 65к, магазин из этой покупки оплатит налоги государству все счастливы все в выигрыше.
https://www.khronos.org/registry/vulkan/specs/1.1-extensions...
Пункт 10.2.3 "Protected Memory". Если я не ошибаюсь, оно обращается к прошиве GPU в обход всего ("must not be visible to THE HOST", то есть - даже не другому ПО, а любому АО системы), а весь программный стек обязан не давать пытаться скопировать, а тем более - анализировать, данные между прогой и чипом. Если стек позволяет, то GPU виснет. Конечно, прогой может выступать пузырь, скачанный через HTML5 EME. То есть, по этим новомодным "открытым стандартам" удалённые пузыри могут нагибать локальные системы на 100% открытом ПО.
Ради того всё и затевалось.
звучит как подарок для вирусописателей чот
Xbill скоро на вулкан переведут?
>XbillЭто типа Xlib для Винды?
xbill это такая игра, невежда.
> Опубликован графический стандарт Vulkan 1.1А я как-то ещё даже на 1.0 не перешёл.
Nvidia 387 driver под Linux пока не все расширения, но примеры работают. Драйвера под Linux всегда немного отстают от windows . там опять проблема с новым ядром под него модуль собирается только от проприетарного 387. а в репозитории лежит 390 так под ним Open GL не фурычит.
>в репозитории лежит 390 так под ним Open GL не фурычитЧего?!
390.25, всё работает.
Либо ты что-то не то говоришь, либо ментейнер пакета накосячил. Проверь наличие libglvnd (/usr/lib64/libglvnd) прежде всего. Переустанови пакет средствами дистрибутива. Можешь с сайта nvidia установить, но только если знаешь, что делать при смене ядра и драйвере, установленном не из реп. Если не знаешь, то не надо тебе это — в повседневном использовании разницы между 387 и 390 нет.
А на мою northern islands опять прибор положили.
"Защищённый контент (Protected content) - возможность ограничения доступа и копирования ресурсов, используемых для рендеринга и отображения, а также возможность организации воспроизведения и отображения защищённого мультимедийного контента;"DRM прямо в драйвере, зааамечательно.
Под вендой в дотку на невидии с опцией -vulkan совсем играть стало не возможно все лагает и дёргается, причем раньше год назад все работало на уровне -dx11.
Винда не в приоритете, DX11-DX12.1 не в приоритете пусть будет как есть...