Facebook опубликовал код новой графической библиотеки IGL (Intermediate Graphics Library), предоставляющей универсальный низкоуровневый API для управления GPU. Предложенный API охватывает типовую функциональность GPU и позволяет создавать кросс-платформенные приложения, способные работать поверх графических API OpenGL, Metal и Vulkan на системах с Android, iOS, Linux, macOS и Windows. Библиотека также может применяться для отрисовки в Web с использованием WebGL, при компиляции приложения в промежуточный код WebAssembly. Код библиотеки написан на языке С++ и распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59401
А чем их не устраивал пром стандарт OpenGL конкретно?
Один менеджер решил что надо делать своё, получил бонус. Потом другой менеджер решил что не взлетело выложил в опенсорс и тоже получи бонус. Так оно и работает. Проект тупо закрыт. Даю гарантию ни одного коммита в него больше никогда не прилетит.
> Даю гарантию ни одного коммита в него больше никогда не прилетит.Чел, там уже за день 8 новых коммитов...
> пром стандарт OpenGL конкретноКак там на маках с пром. стандартом?
…а также на айфонах и прочих мобилках.
Не говоря уже о том, что на голом OpenGL писать — мазохизм в чистом виде.
Почему же мазохизм? А если мне нужен больший контроль над графикой? Если я хочу под себя что то сделать, например, оптимизацию какую-нибудь?
Оптимизация это точно не про opengl
Ну если использовать версию 4.6 и подход AZDO, то почему бы и нет?
> Ну если использовать версию 4.6 и подход AZDO, то почему бы и
> нет?А если использовать Vulkan то вообще все замечательно. Я недавно сравнил black mesa через proton и dxvk 300 фпс, нативная через opengl на тех же настройках 35 фпс. Вот и нафиг нужны такие нативные игры? Чтобы недалёкие крикуны могли постонать как все плохо с играми под Linux?
Тогда лучше как в старые добрые - каждое приложение будет иметь свой подход к графике и по своему обращаться к видеокарте, без всяких там API.А так, не всем нравится писать этот Vulkan за его низкоуровневость) Ну либо использовать готовый рендерер, как сказали ранее
>dxvk 300 фпс, нативная через opengl на тех же настройках 35 фпсКакая то нехорошая вещь вами описана Разница в 10 раз.Этого не может быть, чудес не бывает, такие показатели близки для СОФТОГО Open gl.Проверте настройки игры,включите диагностику (лог игры).Я не удевляюсь что порт был оптимизирован под Nvidia,а для остальных карточек включал базовое ускорение.
На Linux плохо не с играми, а с дровами под видюху) Это уже всемирно известный факт. Нвидиа просто не умеют писать драйвера для Linux. Причём настолько, что даже DE отваливается и приходится перезапускать её, либо же сидеть на HD графике Intel.
> На Linux плохо не с играми, а с дровами под видюху) Это
> уже всемирно известный факт. Нвидиа просто не умеют писать драйвера для
> Linux. Причём настолько, что даже DE отваливается и приходится перезапускать её,
> либо же сидеть на HD графике Intel.Не знаю у кого там чего плохо, у меня все прекрасно и с DE и с играми
Radeon RX? Речь шла про nvidia
> Radeon RX? Речь шла про nvidiaПоэтому где-то с 19 года у меня вся техника только amd. Качеством драйверов от невидии наелся ещё во времена когда у меня gt560oc. На ноуте вообше не вижу смысла в дискретке, и нынешний ноут на Ryzen 7 5800H c интегратом меня устраивает полностью.
У вас похоже с радиусом кривизны рук все плохо. Точнее тут даже не в руках дело. Проприетарный дров ставится изкоробки и работает. Никаких проблем с производительностью нет и не было.
А потом раз! и нужно переписать всё под Vulkan. А потом клиент с маком появляется.
Готовыми движками не просто так пользуются. Нет, для критических по производительности систем можно всё на самом низком уровне писать, но данная библиотека явно не про то.
Если на OpenGL писать - мазохизм, то на Vulkan - мазохизм в кубе.
> Как там на маках с пром. стандартом?Это проблема маков
Это проблема пром. стандарта. Который по сути превратился в окаменелое, гм, legacy.
> А чем их не устраивал пром стандарт OpenGL конкретно?Потому нет такой вещи, как "стандарт OpenGL" - их тьма. В новости же написано:
> OpenGL 2.x, OpenGL 3.1+, OpenGL ES 2.0+, [...] и WebGL 2.0.
"that works atop native graphics APIs from OpenGL and Vulkan to Apple's Metal."
Это абстракция поверх и OpenGL, и всего остального.
Теоретически, должно снимать затраты на разработку.
А как там на самом деле получилось - а бит его знает.
Судя по тому что открыли -- скорее всего не очень взлетело :)
> Судя по тому что открыли -- скорее всего не очень взлетело :)Ну, скорее всего, да.
А как вы представляете "взлетело" в компании, для которой разработка графических библиотек не относится к основной деятельности примерно никак? Внутри в проектах IGL почти наверняка вполне себе используется.
> А как вы представляете "взлетело" в компании, для которой разработка графических библиотек
> не относится к основной деятельности примерно никак? Внутри в проектах IGL
> почти наверняка вполне себе используется.Всё на уровне предположений.
Судить обоснованно об этом могут лишь те, кто пишет кроссплатформенную графику и пожелают попробовать этот IGL.
И с примерами показать что там с производительностью и удобством.
То, что такие люди будут здесь что-то содержательное писать - не слишком вероятно.
и главное, зачему это сайту на пхп
Поищи современный OpenGL на маках, например. Да и на Android что-то кроме ES и Vulkan есть?
А что с ES не так?И зачем самый самый современный?
Тем более что тут как бы поверх самой древней фигни работает?
ES и есть кастрированный GL
Выложили единым коммитом? Это всё равно что выкинули в мусорку.
А как надо было? Научи.
Ты серьёзно, до тебя реально не доходит? Ты когда-нибудь, хоть какой-нибудь разработкой занимался? Вот тебе первый попавшийся пример в апреле Амазон опубликовал либу https://github.com/aws/aws-lc-rs а там все коммиты начиная с начала проекта. Неужели это так сложно?
> там все коммиты начиная с начала проектаИ? Ты типа будешь сидеть и читать их, что ли? Или кому-то это помешает внести вклад в проект?
> И? Ты типа будешь сидеть и читать их, что ли? Или кому-то это помешает внести вклад в проект?Как сказать "я никогда не делал git bisect", не сказав "я никогда не делал git bisect".
И какая польза для нового контрибьютора в использовании git bisect? Новый человек ведь без понятия, появился ли баг из-за регрессии, или же существовал еще с момента появления фичи?
вы не поверите, но git bisect как раз и нужен чтобы дать понятие на этот самый вопрос
> вы не поверитеЯ к тому, что новичек не станет задавться таким вопросом и делать git bisect, ибо в нем есть смысл только для того, кто уже работал над пректом и знает контекст. То есть как минимум знать дату (в идеале - коммит), когда фича появилась. Ты же в здравом рассудке не станешь делать bisect с самого первого коммита в репе, прересобирая и перезапуская весь проект при каждом шаге bisect.
Новичек просто запустит дебаггер и решит проблему.
В чём проблема делать git bisect с самого первого коммита в репе? Вы этим самым git bisect хоть раз пользовались? Значение слова bisect знаете?
> В чём проблема делать git bisect с самого первого коммита в репе?Т.е. вы всерьез предлагаете в репе из 1000 коммитов пересобирать проект 10 раз? Чтобы еще и обнаружить, что баг существовал изначально? И это вместо того, чтобы использовать дебаггер, как нормальные люди?
> Вы этим самым git bisect хоть раз пользовались? Значение слова bisect знаете?
Ну а вы-то читать умеете? Я же в предыдущем комменте подробно описал, почему bisect в этом случае - тупая трата времени. Теперь вот в этом комменте повторил. И вы все равно не поняли, о чем речь, так ведь? Ну ок, позадавайте мне еще больше риторических вопросов.
Тут проблема в том, что один из спорящих словом "новичёк" называет человека грамотного, но впервые увидевшего проект. А второй - типичного майнтайнера и коммитера CoC.
А меня доканало то, что ни один из спорщиков не написал это слово правильно.
У меня ещё и в слове "майнтайнер" ошибка, правильно "обслуживающий персонал". :)
Новый контрибьютор не обладает квалификацией локализовать баг в коде, а потом найти соответствующий ему коммит в истории, потому ищет его методом научного тыка с половинным делением, что и делает git bisect.
и если баг существовал с момента появления фичи - плачет, и идет в "свободная касса", да?Я тебе больше скажу - чаще всего и неновому проще пофиксить баг чем искать его источник бисектом. Потому что источника может просто и не быть в виде конкретного комита. 12350 как бы намекает...
вот blame - да, иногда полезен - но это когда ты УЖЕ нашел проблему и теперь ищешь того п-са, причем с нехорошими намерениями.
> и если баг существовал с момента появления фичи - плачет, и идет
> в "свободная касса", да?Было бы здорово. А ещё лучше на пляж - собирать пакетики старой лыжной палкой.
> Я тебе больше скажу - чаще всего и неновому проще пофиксить баг
> чем искать его источник бисектом.Ну я и пишу, что новый не обладает квалификацией. Старый, надо полагать, достаточно квалифицирован искать эффективнее чем тупым перебором, раз он этот код писал и более-менее его понимает.
Представь себе в проектах сложнее твоего хеллоуворлда, который ты версионируешь папками 1 2 3 это нужно.
> Ты когда-нибудь, хоть какой-нибудь разработкой занимался?Занимался, и в больших проектах, и в совсем небольших, и менеджментом проектов занимался, за 20 лет в индустрии чего только не было. Но вот в чём ценность истории коммитов для пользователя библиотеки не могу себе представить. Тут про git bisect вспомнили, хороший кейс, но в реальности приходилось им пользоваться два раза всего, и оба раза пользы от этого было мало. Ну вот нашёл ты, что баг появился между коммитами 123 и 789. Между ними изменения в сотне файлов. Как тебе это поможет? Никак, потому что баг нетривиальный, иначе было бы проще исправить, чем искать когда он появился. То, что Амазон выложил с историей, ну молодцы, им видимо так проще было. Но для меня разницы никакой, библиотека либо делает что надо, либо не делает, и история тут никак не поможет и не помешает.
> Выложили единым коммитом? Это всё равно что выкинули в мусорку.А тебе, как конечному пользователю, не все равно?
Как конечному пользователю я хочу продукт, который поддерживается. А не просто лежит как мусор.
А откуда у тебя уверенность, что эту либу не будут развивать?
Тебе уже сказали ты в интеллект не умеешь? Оттуда что его выложили без коммитов как кусок **** "чего-то ненужного".
> Тебе уже сказали ты в интеллект не умеешь?На данный момент в репе уже 8 новых коммитов. Ну, что там с логикой?
Это опенсурс- тут ты этот продукт и поддерживаешь, если ты не забыл ещё, что значит философия опенсурса. А не хочешь- тебя никто не держит, и ты всегда можешь создать свой личный велосипед. Или мотивировать кого- то другого поддерживать.
Ну хоть кто то взялся создать единую универсальную обёртку под этот зоопарк графических API
Этих оберток - как грязи еще с незапамятных времен. Например:
Ой, да с этим bgfx столько проблем. То он не билдится из за каких то ошибок, то приложения на нём после старта намертво виснут независимо от выбранного бэкэнда, то в вулкановском бэкэнде какие то траблы с фреймбуферами. Плюс ко всему ещё этот убогий язык шейдеров, не проще было использовать SPIRV-Cross, который может конвертировать spv в любой язык шейдеров, а в сам spv можно конвертировать всем привычный glsl.
Только зачем? Сейчас достаточно писать только под Vulkan, он уже достаточно универсальный. Работает под Windows/Linux/Android, никаких проблем. А всякие яблочные поделки никому не нужны
> Сейчас достаточно писать только под Vulkan, он уже достаточно универсальный.На нвидиях работает, начиная с 600 серии (и то на ней не очень). Сказать, сколько более старого добра у не-игрунов?
> А всякие яблочные поделки никому не нужныОт линуксоидов это особенно забавно слышать.
Если к этому есть сорцы- наслаждайтесь опенсурсом. Если нет- страдайте.
Вообщем, посмотрел я исходники этой либы, а точнее пример использования. По факту никакого универсального функционала там нет, вам всё равно придётся писать хоть не значительно, но всё же разный код под разный API, который будет работать бэкэндом. Просто сделали под каждый API какое то подобие единой обёртки и сгребли в одну кучу.
Ты только посмотри на человека, который выложил этот код. https://github.com/nlutsenko по его фотографии сразу понятно что он ненавидит всех пользователей и заодно всех людей на этой планете. Он для тебя ничего делать не будет. Ему бы оружие массового поражения разрабатывать.
Какая няша!
И сразу ошибка на его сайте — https://nlutsenko.meНадо писать "Who am I?" или "Who I am".
Сайт ещё и со звуками... Боже мой...
У него что-то с сайтом случилось - пишет: You need to enable JavaScript to run this app.
Да не, это у вас что-то с JavaScript случилось.
О, а вот и телепаты вышли из отпуска...
Что характерно, никто не начал это занятное упражнение по физиогностике с посылки фотографий своего лучезарного облика.
Это всё ещё спасает опеннет
А чем SDL их не устроил?
В SDR дохера лишнего: звуки там, сеть... А кому-то надо как agg
SDL - это библиотека мультимедиа, которая включает в себя не только модуль для работы с графикой(причём, очень высокоуровневый), но и со звуком, изображениями, окнами и т.п. То есть это библиотека, в которой всё собрано для написания игр. Графический API - это немножечко другое. Он включает в себя функции для работы с видеокартой, такие как создание фреймбуферов, отправка drawcallов, создание буферов вершин. Так что немного некорректно сравнивать эти две вещи. И да, графический модуль SDL работает поверх OpenGL, но он абстрагирует всё настолько, чтобы было писать игры и графические приложения без головной боли.
Начнём с того, что SDL это строго 2D. Ну и про веб речи нет.
>Начнём с того, что SDL это строго 2DЧел, ты обкурился :) https://github.com/qninhdt/cybrion
Я в курсе, что куча 3D-игр использует SDL. Для создания окна в основном.
>графический модуль SDL работает поверх OpenGLЗависит от платформы.А так официально в последних версиях вывод графики потдерживаеться через-OpenGL/Direct3D/Metal/Vulkan.
Поддерживать то поддерживается, но это же не значит, что сама библиотека рендерит с помощью этих бэкэндов. Сама она рендерит с OpenGL. Для остальных же бэкэндов эта либа просто умеет создавать окна и не более. Далее ты должен сам написать рендерер.
Вообщет рендерит она как раз в любой output, только вот рендерит она тупо 2D-текстуру размером c viewport. И всё. Больше она ничего не умеет. И так и задумывалось.
Тем, что она не ООП.
Низкоуровневая библиотека работающая поверх низкоуровневой, как минимум становится среднеуровневой.
Некрософт таки доломали гитхаб. Без JavaScript даже листинг директории и исходники с подсветкой не видны. M$, fuck you.
Подите в свой Web 1.0.
"Подите" в пешее.
Так и я вам не на автобусе предлагаю.
А гитхаб никто не ломал. У меня всё работает.
И как же ты, гений, сделаешь подсветку синтаксиса без JavaScript?Разберёшь синтаксическое дерево на html? Код покажи:))
Ка всегда это делалось. server side.
Server side на все хранимые сотни гигабайт исходников и постоянный поток изменений? А если в подсветке ошибка была или даже просто захотелось цветовую тему сменить, всё заново пересчитывать? В том числе и для тех файлов, которые никогда в жизни не будут показаны в браузере пользователям? Знаешь, я тут прикинул копеечку к копеечке, выходит значительно дешевле просто не обслуживать тех, у кого JS отключен. Не нужны такие пользователи. Не приходи больше.
Сервер способен формировать HTML динамически.
Чокнутый что-ли? получил запрос - считал файл - накатил формат - отдал html
с разморозочкой. У вас таймер похоже льдом покрылся и вы проспали лишних лет десять.
Человек, который то ли сам GitHubом никогда не пользовался, то ли балаболит, нас учит. Ещё очень недавно, в этом году, всё прекрасно работало.
Опять эти нестандартные потребности разработчиков
Потребности корпораций.
Без Direct3D не нужно
А сторонникам опенсорса Direct3D нужно?
по исходному коду видно что это тупо очередная обвязка к GLFW. ничего нового, понты.
Копирастам стало не нужно, и они открыли под пермиссивной лицензией. Классика жанра.
Теперь любое открытие кода полезно, так как пополнит знания ИИ. Осталось найти ИИ, которому всё это скормить.
