The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Представлен новый видеодрайвер для чипа Apple M1, поддерживающий Vulkan 1.3"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Представлен новый видеодрайвер для чипа Apple M1, поддерживающий Vulkan 1.3"  +/
Сообщение от opennews (?), 05-Июн-24, 21:28 
Алиса Розенцвейг (Alyssa Rosenzweig) из компании Collabora, развивающая OpenGL-драйверы Panfrost для GPU Mali и Asahi для GPU Apple AGX, представила новый Vulkan-драйвер  Honeykrisp для графического процессора, поставляемого в чипах Apple M1. Несмотря на то, что драйвер разрабатывается всего месяц, он уже  признан консорциумом Khronos, как полностью реализующий спецификацию Vulkan 1.3 на оборудовании Apple c чипом M1. Honeykrisp  стал первым драйвером для чипов Apple, имеющим сертифицированную поддержку графического API Vulkan...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=61318

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от бух. (?), 05-Июн-24, 21:28   +10 +/
В таких новостях я бы хотел видеть присказку что такое Вулкан и чем он знаменит. Как в новостях про раст и безопасную память.

А то не ясно чем вулкан от опенгл отличается и зачем он нужен.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #73

3. Сообщение от Hck3r (?), 05-Июн-24, 21:43   +10 +/
Почему нет отдельного абзаца
«Драйвер написан на Си. Выбор языка позволил сделать разработку в кратчайший срок»?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #18, #51, #102

6. Сообщение от Bklrexte (ok), 05-Июн-24, 22:03   +6 +/
Короче, OpenGL - это высокоуровневый API для написания графических приложений людьми напрямую. Vulkan - это очень низкоуровневый GPU API, который создан именно для того, чтобы служить бекендом/таргетом для разных движков и так далее. Он не создан для обычного хобби использования напрямую (если хочется, то можно, но больно и нет смысла). Vulkan вообще не только про графику, он именно про GPU, так что его можно использовать и для реализации всяких нейронных сетей и так далее, как CUDA.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8

7. Сообщение от Аноним (7), 05-Июн-24, 22:07   +1 +/
Плюсую про быстроту. На Си можно быстро набросать идею, проверить, набросать новую, проверить, улучшить. На расте придётся сразу писать правильно. Идея не подошла – переписываем, снова тратим время на борьбу с "правильным строгим компилятором".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #20, #49, #50, #61

8. Сообщение от Аноним (8), 05-Июн-24, 22:13   +1 +/
Ты забыл упомянуть, что OpenGL уже несколько лет как умер.

> Vulkan вообще не только про графику, он именно про GPU

Неверно, этим он вообще от OpenGL не отличается. Вычислительные шейдеры были и в OpenGL. Ты должно быть спутал c OpenCL.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #16, #42

11. Сообщение от Аноним (11), 05-Июн-24, 22:21   +1 +/
За чей счёт банкет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #68

16. Сообщение от NV (??), 05-Июн-24, 22:58   +/
>> OpenGL уже несколько лет как умер

Да что ты такое несешь черт побери? Эта штука бессмертна к ней только и будут всякие вулканы прикручивать

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #53, #118

18. Сообщение от Bottle (?), 05-Июн-24, 23:01   –1 +/
Потому что это правда для прототипов на Python. Сишка, мягко говоря, для быстрого прототипирования не подходит, из-за медленной компиляции (спасибо хедерам) и неопределённого поведения. Питон обладает просто гигантским количеством библиотек, имеет удобную стандартную библиотеку "из-коробки", и компиляции не требуется - код запускается мгновенно. Вот когда базовую идею отработал, драйвер может рисовать, вот тогда нужно и на Си переписать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #25, #32

20. Сообщение от Аноним (20), 05-Июн-24, 23:06   +2 +/
С таким подходом далеко не уйдёшь. "Кое-как набросал и в продакшон" приводит к тому, что кодобаза становится неподдерживаемой настолько, что даже рефакторинги не помогут. Алсо на Си то с отсутствием вменяемых генериков и ООП очень быстро пишется код, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #21, #29, #31

21. Сообщение от Аноним (7), 05-Июн-24, 23:08   +3 +/
> Кое-как набросал и в продакшон

Не перевирай, я такого не писал.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #22

22. Сообщение от Аноним (20), 05-Июн-24, 23:10   –2 +/
К этому и приводит всё. Я не защищаю раст тащемто, вопрос в том, что Си тут не пример для подражания. И да, борров чекер не будет пытать ошибками если к нему привыкнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #47

25. Сообщение от Аноним (25), 05-Июн-24, 23:41   +/
Что, прототип видеодрайвера на питоне? Да вы фантазёр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26, #48

26. Сообщение от Аноним (29), 05-Июн-24, 23:55   +/
Библиотеки помогут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

29. Сообщение от Аноним (29), 06-Июн-24, 00:26    Скрыто ботом-модератором–1 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

30. Сообщение от Аноним (7), 06-Июн-24, 00:40   +1 +/
Это же не раст программисты с КоКами и фондами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #70

31. Сообщение от Ivan_83 (ok), 06-Июн-24, 00:42   +1 +/
Вы не понимаете того как живёт индустрия, а живёт она так же как в реальном биологическом мире - естественным отбором.
Нет проблемы в том чтобы там была неподдерживаемая кодовая база, потому что если идея годная и востребованная то перепишут с нуля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #34, #38, #39, #80

32. Сообщение от Ivan_83 (ok), 06-Июн-24, 00:47   +4 +/
Это у С то медленная компеляция!?
Самые огромные проекты на С собираются минут за 10 на 5950х, а там по 6к .с файлов.
Неопределённое поведение вообще мало кому мешает, и в основном тем кто пишет как попало.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #35, #56, #59, #65, #142

34. Сообщение от Аноним (20), 06-Июн-24, 00:56   –6 +/
Нужно просто силы свои оценивать. Личные проекты вообще лучше на питоне писать - быстро делается, так что не устанешь. Си не подходит ни чтоб писать долговечный, качественный код ни чтоб быстро прототипировать. В обоих нишах есть ЯП лучше. Проблема сишки в том, что пока одни прикручивали ООП и нормальную стандартную библиотеку в комитете ничего не делали. Пока другие придумывали как автоматизировать доказательство безопасности в комитете тоже ничего не делали. Жить за счёт прежних достижений можно, а вот в будущем что? Не надо только про стабильность говорить, стабильность это когда легаси код поддерживается, а новый пишется не опираясь на старые функции. Тут же на лицо стагнация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #37, #57, #139

35. Сообщение от Аноним (20), 06-Июн-24, 01:04   +/
>Самые огромные проекты на С собираются минут за 10 на 5950х, а там по 6к .с файлов.

Вопрос в том почему что-то вообще может собираться 10 минут на 5950х. Скорость компиляции гцц падает с каждым релизом, а скорость кода растёт на какие-то доли процента. 6к же файлов это ничто для современного процессора, он может их все прочитать и распарсить так быстро, что вы и не заметите, скорее всего главным ботлнеком тут вообще будет диск. Вообще, люди пишущие компиляторы часто достигают отметок вроде пары миллионов строк в секунду (Хоть и показатель сомнительный, явно быстрее чем гцц)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #55, #136

37. Сообщение от Аноним (29), 06-Июн-24, 01:15   +1 +/
Си подходит чтоб рубить бабло не слишком просиживая жопы за кампом, потому что пока аноним рассуждает о том, как ему кажется должно было бы быть, существует парадокс. Куча сишного кода, который работает и никуда не собирается. Вот следующая новость про ффмпег, ты думаешь там кто-то питона нюхал, или на крестах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #113

38. Сообщение от Анлним (?), 06-Июн-24, 01:16   +/
> Нет проблемы в том чтобы там была неподдерживаемая кодовая база, потому что если идея годная и востребованная то перепишут с нуля.

Судя по комментариям к любой новости про Wayland или Xorg, у последнего просто умопомрачительная востребованность. Однако переписывание с нуля почему-то не происходит. Видимо, не всё так просто с естественным отбором.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #60

39. Сообщение от Аноним (29), 06-Июн-24, 01:18   +/
Но про шаблончики и клинкод почитай, занимательная литература
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

42. Сообщение от cheburnator9000 (ok), 06-Июн-24, 01:35   +/
Весь линукс десктоп рендерится на OpenGL и его вариациях, как и все браузеры под линуксом. Да. Умер. Много лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #46, #54, #62

44. Сообщение от Аноним (44), 06-Июн-24, 02:55   –2 +/
Вулкан, мммм, в игры из 2007 уже играть можно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69, #103, #123

46. Сообщение от Аноним (8), 06-Июн-24, 04:23   –1 +/
Последний релиз 6 лет назад и больше не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #133

47. Сообщение от Аноним (47), 06-Июн-24, 04:32   +/
Раз ты раст не защищаешь, расскажи трезвым взглядом, почему дровишки для видоса для Asahi сначала написали на питоне, а потом переписали на раст?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

48. Сообщение от Аноним (47), 06-Июн-24, 04:35   +/
Ознакомься плиз https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ раздел "GPU drivers in Python?!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #75

49. Сообщение от Аноним (49), 06-Июн-24, 05:06   +/
не так. Если взяться реализовавывать какой-то сложный проект, то на Си ты напишешь говнокод, в котором придется еще долго ловить баги, UB и прочие уязвимости, но который в целом будет как-то работать.

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

Ну или гибридный подход, которым чаще всего и пользуются растоманы: написать ключевые части, делающие настоящую работу, на Си или C++, спрятать их глубоко в кишках проекта (желательно в другом репозитории, чтобы Github показывал "Rust 99%"), написать на расте тонкую "безопасную" обвязку над ними, и гордо объявить что проект "written in rust".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

50. Сообщение от Аноним (50), 06-Июн-24, 05:48   +/
Раст отличный язык, C старая дырявая шляпа, на которую дрочат маргиналы опеннета  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #58, #87

51. Сообщение от Ф1 (?), 06-Июн-24, 08:09   +1 +/
>Драйвер написан на Си. Выбор языка позволил сделать разработку в кратчайший срок

Драйвер написан методом чуть подправленного копипаста. Выбор копипаста независимо от языка позволил сделать разработку в кратчайший срок.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

52. Сообщение от ryoken (ok), 06-Июн-24, 08:09   +2 +/
>>Поддержка DXVK и vkd3d-proton позволит использовать драйвер Honeykrisp в Asahi Linux на оборудовании с ARM-чипами Apple для запуска Windows-игр при помощи Wine и эмулятора архитектуры x86.

Подскажите, с целью повышения уровня образованности. Где можно про эмуляцию x86 в линуксах на Арме почитать?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78, #128, #130

53. Сообщение от Аноним (53), 06-Июн-24, 09:41   +/
Opengl доживает последние дни в виде легаси, vulkan является прямым развитием и продолжением технологий. И ты в целом ошибаешься, это opengl можно прикрутить к vulkan. Только зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #94, #111

54. Сообщение от n00by (ok), 06-Июн-24, 10:13   +/
Если Linux это ядро, то OpenGL "умер" с включением в состав Mesa драйвера Zink https://docs.mesa3d.org/drivers/zink.html

С того времени производителям железа нет необходимости поддерживать OGL в драйвере, достаточно Vulkan. Из имеющихся драйверов код в ближайшее время может быть и не выкинут, но тенденция ясна.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #116

55. Сообщение от n00by (ok), 06-Июн-24, 10:29   +1 +/
>>Самые огромные проекты на С собираются минут за 10 на 5950х, а там по 6к .с файлов.
> Вопрос в том почему что-то вообще может собираться 10 минут на 5950х.
> Скорость компиляции гцц падает с каждым релизом, а скорость кода растёт
> на какие-то доли процента. 6к же файлов это ничто для современного
> процессора, он может их все прочитать и распарсить так быстро, что
> вы и не заметите, скорее всего главным ботлнеком тут вообще будет
> диск.

Пока боттлнеком является экспертиза. После семантического анализа ("распарсить") транслятор с синтаксическим деревом делает всякие разные штуки, в просторечии называемые "оптимизация". Скорость gcc падает, потому что с каждым релизом этих разных штук всё больше, что бы генерируемый код работал быстрее. Ну а проверить, как влияет "диск", можно самостоятельно, если удастся настроить ccache.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #71

56. Сообщение от n00by (ok), 06-Июн-24, 10:30   –2 +/
> Это у С то медленная компеляция!?

Очевидно, эксперт перепутал с Си++, то есть не видит меж ними разницы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

57. Сообщение от nox. (?), 06-Июн-24, 10:50   +2 +/
> Личные проекты вообще лучше на питоне писать - быстро делается, так что не устанешь. Си не подходит ни чтоб писать долговечный, качественный код ни чтоб быстро прототипировать. В обоих нишах есть ЯП лучше.

Конечно, есть лучше. Называется Visual Basic. То, что медленный - так не медленней Python. Если Python устраивает по скорости, то и Basic сойдет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

58. Сообщение от nox. (?), 06-Июн-24, 10:54   +1 +/
Может и отличный. От других. Но лицензия не позволит для ядра. Так что потаращились, и хорош.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

59. Сообщение от nox. (?), 06-Июн-24, 10:57   +/
> Самые огромные проекты на С собираются минут за 10

Вряд "огромные" проекты собираются разом за один присест. Даже наши скромные проекты (чуть более 100 000 строк) собираем по частям. Так что речь в любом случае идет максимум о десятке секунд.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #76, #137

60. Сообщение от Аноним (60), 06-Июн-24, 11:00   +1 +/
> Wayland
> C 97.1%

Ой, а где Rust?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #63, #66

61. Сообщение от Аноним (-), 06-Июн-24, 11:03   +1 +/
> Плюсую про быстроту. На Си можно быстро набросать идею, проверить, набросать новую,
> проверить, улучшить. На расте придётся сразу писать правильно. Идея не подошла
> – переписываем, снова тратим время на борьбу с "правильным строгим компилятором".

Ну, предыдущий драйвер писался вначале на питоне, а потом переписывался на нормальный ЯП (не на СИшку).
Возможно тут или драчер проще, либо есть уже понимание как оно работает с учетом предыдущего опыта.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

62. Сообщение от Аноним (62), 06-Июн-24, 11:20   +1 +/
Ну он и живой примерно как линукс десктоп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

63. Сообщение от Аноним (-), 06-Июн-24, 11:29   –1 +/
> Ой, а где Rust?

Напр. тут github.com/Smithay/wayland-rs  Rust 99.9%
      тут github.com/YaLTeR/niri         Rust 97.6%

Ну и кроме композиторов есть бары, ланчеры и тд
Вот тебе ссылочка - просвещайся github.com/rcalixte/awesome-wayland

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #64

64. Сообщение от Аноним (60), 06-Июн-24, 11:32   +1 +/
В проде используется Wayland на C от freedesktop, а не поделка от умельца с левого гитхаба.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #67

65. Сообщение от Аноним (-), 06-Июн-24, 11:38   +/
> огромные проекты
> по 6к .с файлов.

Ахаха)) Любители хелоувордов начинают мерятся своими петпроджктами))
6к файлов это просто ни

> мало кому мешает, и в основном тем кто пишет как попало.

Т.е. 99% погромистов на си, включая ядрописак.

> все эти прототипы написанные на петоне не годны к продакшену в принципе.

За использование прототипов в продакшене нужно бить, возможно даже ногами.
И не важно на каком языке прототип был написан.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #138

66. Сообщение от aname (?), 06-Июн-24, 11:49   +/
Там, где ему и место
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

67. Сообщение от Аноним (-), 06-Июн-24, 11:55   –1 +/
Там штук 20 файлов всего.
Если говорить про имплементацию на си, то лучше уже вестон в пример приводи.

Но все равно видно, что wayland на дыряшке написан:
  fix undefined behavior in wl_array_for_each
  Mitigate UAF crashes due to wl_client_destroy reentrancy
  Mitigate UAF crashes due to iteration over freed wl_resources
  avoid calling memcpy on NULL
  fix segfault when accessing destroyed pool resource
  fail on global name overflow
...
и это только первая страница

В общем типиКал си)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #88, #98

68. Сообщение от aname (?), 06-Июн-24, 11:57   +/
Корпорации угощают, как всегда
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

69. Сообщение от aname (?), 06-Июн-24, 11:57   +1 +/
Никто не запрещал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

70. Сообщение от Аноним (70), 06-Июн-24, 12:01   +1 +/
Удивишься, но Asahi — это они самые. Трансгендерные кошкодевочки с КоКами. И основная разработка ведётся на ржавчине.

Просто данный драйвер представляет из себя наскоро перепиленный nvk, поэтому не было смысла переписывать. И феноменальная степень совместимости оттуда же¹, а вовсе не чудеса скоростной разработки.

[1] — https://web.archive.org/web/20240417193247/https://www.phoronix.com/news/Mesa-NVK-Vulkan-Conformant

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #140

71. Сообщение от Аноним (20), 06-Июн-24, 12:09   +1 +/
Про диск я говорил в контексте быстрой реализации, а не гцц. AST строить кстати даже и не обязательно, некоторые компиляторы сразу генерируют байткод/бинарь. Тем не менее необходимость таких медленных оптимизаций сомнительна. tcc вот генерирует код в ~10 раз быстрее чем гцц, но быстрее ли бинарь в 10 раз?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #83

73. Сообщение от leap42 (ok), 06-Июн-24, 12:16   +3 +/
Раньше все видяхи были концептуально разными, прям совсем. Я помню те времена, когда игры выходили под конкретную(!) видяху, а на других не работали. Так появилась нужда в каком-то абстрактном эталоне видяхи. Его то и описывает OpenGL, а разные вендоры реализуют его уже на базе своего железа. Считай виртуальная видеокарта. Удобно для разрабов игр, но жрёт проц даже с учётом всех оптимизаций.

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

Vulkan - простой и тонкий API для отрисовки графики. Он делает то же самое, что и OpenGL (нет конечно, но на уровне профана - да). Работает везде, не грузит проц как OpenGL, упрощает управление железом. С быстрым процом разницы видно не будет, а вот со слабеньким Vulkan может выдать больше фпс, меньше статтеров, ниже среднюю задержку.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #135

75. Сообщение от _kp (ok), 06-Июн-24, 12:27   +1 +/
"большая часть драйвера на самом деле представляла собой просто набор жестко запрограммированных структур"
то есть, фреймворк m1n1 + инициалицация в стиле портянок
"в конце концов мне удалось их исправить и отрисовать треугольник"

"невозможно сделать на Python, верно?!
Оказывается, у Mesa есть нечто под названием drm-shim"
"Когда жуткий ужасный стек драйверов Mesa+Python заработал..."

На этом с "драйвером на Питоне" всё. И далее изучение Rust и переписывание с Си на Rust, и дальнейшее развитие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

76. Сообщение от _kp (ok), 06-Июн-24, 12:56   +1 +/
Конечно по частям.
Но для замера скорости - полная пересборка.
Например вот время сборки ядра Линукс:
https://openbenchmarking.org/test/pts/build-linux-kernel&eva...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #85

78. Сообщение от Аноним (78), 06-Июн-24, 13:02   +/
https://box86.org/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

80. Сообщение от Аноним (-), 06-Июн-24, 13:43   +1 +/
> живёт она так же как в реальном биологическом мире - естественным отбором.

А как это соотносится с взятками, чемоданами кому нужно, санкциями или протекцией внутр рынка...
Не, ну я понимаю, что человек это тоже "биологический мир", но к естественному отбору относится мало.

Я уже молчу про всякие взбрыки великодушных диктаторов, из-а которых мы в ядро получили раст, а не С++.

> если идея годная и востребованная то перепишут с нуля

или будут твердить "работает не трогай", "всего 30 лет коду", "диды на улицу бегали, таз зачем вам канализация"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #82

82. Сообщение от n00by (ok), 06-Июн-24, 13:54   +/
> Я уже молчу про всякие взбрыки великодушных диктаторов, из-а которых мы в
> ядро получили раст, а не С++.

Ключевое слово "получили". Которое следует читать как "не смогли". Но виноват, как всегда, злой дядя.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #96

83. Сообщение от n00by (ok), 06-Июн-24, 13:58   +/
> tcc вот генерирует код в ~10 раз быстрее чем гцц,
> но быстрее ли бинарь в 10 раз?

Опять боттлнек в экспертизе? Я должен проверить за кого-то, что бы что-то доказать сам себе?

> Про диск я говорил в контексте быстрой реализации, а не гцц.

"Скорость компиляции гцц" (ц)

В контекст "неизвестной эксперту реализации" gcc подходит вполне - очевидно, что  Ivan_83 писал о своём опыте с Clang, поскольку у него FreeBSD.

> AST строить кстати даже и не обязательно, некоторые компиляторы сразу генерируют байткод/бинарь.

Да даже понимать, что такое AST, не обязательно. Оно же абстрактное, а не просто синтаксическое.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

85. Сообщение от n00by (ok), 06-Июн-24, 14:15   +/
Так исходно не скорость измеряли, а обосновывали необходимость модулей в С++ "Сишка ... для быстрого прототипирования не подходит, из-за медленной компиляции (спасибо хедерам)". Немного перепутав, с кем не бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #92

87. Сообщение от Гром (?), 06-Июн-24, 14:36   –1 +/
Раст негоден для применения от слова совсем.
Используйте С++ и не парьте себе и людям мозги!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

88. Сообщение от Гром (?), 06-Июн-24, 14:39   +/
Вышеперечисленное говорит о профнепригодности кодописателей, а не недостатках Си. На Ассемблере ещё больше ошибок может быть, что не говорит о том, что язык плох, а говорит о непрофессионализме или невнимательности программеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #95

92. Сообщение от _kp (ok), 06-Июн-24, 15:10   +/
> "Сишка .. для быстрого прототипирования не подходит, из-за медленной компиляции (спасибо хедерам)".

Так в прототипе на Питоне всего пара сотен строк.
Даже игнорируя скорость работы, оно стартует дольше чем Си скомпилирует.

Впрочем автор упомянул, что ему так ошибки при инициализации смотреть удобнее. Выкрутился.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #100

94. Сообщение от leningrib (?), 06-Июн-24, 15:18   +/
понятно, как x11 и как xmpp бггг)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

95. Сообщение от n00by (ok), 06-Июн-24, 15:28   +/
Не всё так однозначно.

util: fix undefined behavior in wl_array_for_each

If a wl_array has size zero, wl_array_for_each computes NULL + 0 to get
to the end pointer. This should be fine, and indeed it would be fine in
C++. But the C specification has a mistake here and it is actually
undefined behavior. See
https://davidben.net/2024/01/15/empty-slices.html

Clang's -fsanitize=undefined flags this. I ran into this in Chromium's
build with wayland-scanner on one of our XML files.

../../third_party/wayland/src/src/scanner.c:1853:2: runtime error: applying zero offset to null pointer
    #0 0x55c979b8e02c in emit_code third_party/wayland/src/src/scanner.c:1853:2
    #1 0x55c979b89323 in main third_party/wayland/src/src/scanner.c
    #2 0x7f8dfdb8c6c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #3 0x7f8dfdb8c784 in __libc_start_main csu/../csu/libc-start.c:360:3
    #4

0x55c979b70f39 in _start (...)

https://gitlab.freedesktop.org/wayland/wayland/-/commit/8a7e...


Сам код:

/**
* Iterates over an array.
*
* This macro expresses a for-each iterator for wl_array. It assigns each
* element in the array to \p pos, which can then be referenced in a trailing
* code block. \p pos must be a pointer to the array element type, and all
* array elements must be of the same type and size.
*
* \param pos Cursor that each array element will be assigned to
* \param array Array to iterate over
*
* \relates wl_array
* \sa wl_list_for_each()
*/
#define wl_array_for_each(pos, array)                    \
    for (pos = (array)->data;                    \
+         (array)->size != 0 &&                    \   // <-- исправление
         (const char *) pos < ((const char *) (array)->data + (array)->size); \
         (pos)++)

https://gitlab.freedesktop.org/wayland/wayland/-/blob/8a7ecd...

Во-первых, UB здесь формальный, о чём указано в commit message и по ссылке (Fortunately, there is hope. Nikita Popov and Aaron Ballman have written a proposal to fix this in C. https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UC...).

Во-вторых, мне не понятно, откуда в (array)->data возьмётся NULL?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #97

96. Сообщение от Аноним (-), 06-Июн-24, 15:50   +/
А кто виноват в тупом заявлении типа "С++ это овно, его в ядре не будет"?
Марсиане? Рептилоиды?
Не, таки злой дядя, который сказал чушь, а потом не хотел признавать, что был не прав.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #99

97. Сообщение от n00by (ok), 06-Июн-24, 15:52   +/
Mitigate UAF crashes due to wl_client_destroy reentrancy

https://gitlab.freedesktop.org/wayland/wayland/-/merge_reque...

> We can probably avoid our crash by being less eager with performing updates that might end up being no-ops - but this doesn't feel like the right fix. We'd like to treat these update methods as idempotent and avoid us potentially introducing another similar crash in the future.

и так далее...

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

98. Сообщение от n00by (ok), 06-Июн-24, 15:53   +1 +/
>[оверквотинг удален]
> Но все равно видно, что wayland на дыряшке написан:
>   fix undefined behavior in wl_array_for_each
>   Mitigate UAF crashes due to wl_client_destroy reentrancy
>   Mitigate UAF crashes due to iteration over freed wl_resources
>   avoid calling memcpy on NULL
>   fix segfault when accessing destroyed pool resource
>   fail on global name overflow
> ...
> и это только первая страница
> В общем типиКал си)))

В общем, понятно, кто набросы делает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

99. Сообщение от n00by (ok), 06-Июн-24, 15:56   –1 +/
Не надо клеветать на Линуса Торвальдса. Он сформулировал иначе. Заявил, что много "бестолковых" программистов. Не заставлял каждого принимать это на свой счёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #107

100. Сообщение от n00by (ok), 06-Июн-24, 16:05   +1 +/
Так в том и дело, что речь о драйвере, где строк мало, а далее вбрасывают про медленную компиляцию вообще всего из левой методички про Си++, подменив язык. Если именно драйвер, да ещё и прототип, и на Си++ быстро соберётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

102. Сообщение от anonymous (??), 06-Июн-24, 16:13   +/
Тогда уж на Python надо писать. Он - чемпион по скорости прототипирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

103. Сообщение от anonymous (??), 06-Июн-24, 16:14   +/
d9vk разрешает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

107. Сообщение от Аноним (107), 06-Июн-24, 17:11   +/
> C++ is a horrible language
> C++ leads to really really bad design choices
> You invariably start using the "nice" library features of the language like STL and Boost
> the whole C++ exception handling thing is fundamentally broken
> hide things like memory allocations behind your back

.
> Note that no one in their sane mind would expect to use all the features
> of C++. Just like we have "kernel C" ... we would have "kernel C++"

А вот это из рассылки текущего года, где Линус не появился. И слова про "their sane mind", а точнее, его отсутствие, как бы переносятся на Линуса: тот побеждал соломенное чучело, чтобы обосновать своё идеологическое (а не техническое) решение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #120

111. Сообщение от _oleg_ (ok), 06-Июн-24, 17:49   +/
opengl это ещё и офигенное api. Чем пользоваться разрабам ПО, если не им? vulkan'ом низкоуровневым страдать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #112

112. Сообщение от Аноним (53), 06-Июн-24, 18:03   +/
А не всё ли равно тебе как пользователю? Хотя у вулкана поменьше багов наберётся наверно. Opengl и так почти не используется в индустрии. Что ты предпочитаешь, чтобы все перешли на directx12, или чтобы все перешли на vulkan? Вообще, прямо сейчас у opengl нет паритета ни с чем, некоторый паритет поддерживается между dx12 и vk.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #114

113. Сообщение от Аноним (-), 06-Июн-24, 18:12   +/
> Си подходит чтоб рубить бабло

... на исправлении своего овнокода годами

> Куча сишного кода, который работает и никуда не собирается.

Еще как собирается. Из того же андроида дропают в основном дыряшечные кода и заменяют на нормальные языки - с++ и rust.

> ффмпег

это древняя куча легаси.
Понятное дело что переписать ЭТО на что угодно - это огромная проблема и никто не хочет в это макаться.
А современные вещи пишут и на си, и на расте.
Напр. rav1d/rav1e вместо dav1d.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #121, #125, #126

114. Сообщение от _oleg_ (ok), 06-Июн-24, 18:17   +/
> А не всё ли равно тебе как пользователю?

  Как пользователю всё равно. А как разрабу нет.

> Хотя у вулкана поменьше
> багов наберётся наверно. Opengl и так почти не используется в индустрии.

  Здрасте. Все игры под linux-based ОС - opengl.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #115, #117

115. Сообщение от Аноним (115), 06-Июн-24, 18:20   –2 +/
Да, все десятка два штук.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

116. Сообщение от cheburnator9000 (ok), 06-Июн-24, 20:12   +/
> Если Linux это ядро, то OpenGL "умер" с включением в состав Mesa
> драйвера Zink https://docs.mesa3d.org/drivers/zink.html
> С того времени производителям железа нет необходимости поддерживать OGL в драйвере, достаточно
> Vulkan. Из имеющихся драйверов код в ближайшее время может быть и
> не выкинут, но тенденция ясна.

Угу. Вон Intel не реализовал поддержку DirectX9 в своих видеокартах Ark, сказал пусть будет DXVK прямо в драйверах. И что? Лютый багадром, глюкодром и треш в DX9 играх.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #119

117. Сообщение от Аноним (53), 06-Июн-24, 20:25   +/
Разработчик никогда не выберет опенгл (если только не намеревается обеспечивать совместимость со старыми телефонами). В итоге, к примеру, игры, портированные на линукс, в основном понерфленные, без части шейдеров/теней/эффектов, с отличающейся производительностью, либо включают различные графические трансляторы и работают с переменным успехом. Все приличные игры под линукс на вулкане. Всё ПО тоже переползает на вулкан, настолько быстро, насколько это возможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

118. Сообщение от Аноним (118), 06-Июн-24, 21:15   +/
> Да что ты такое несешь черт побери? Эта штука бессмертна к ней только
> и будут всякие вулканы прикручивать

Это вы чего-то не понимаете. Из OpenGL невозможно сделать вулкан. Точнее, это - абсолютно бессмысленное занятие.

GL - высокоуровневый интерфейс с кучей внутреннего состояния, делающий дохрена внутри сам. Из этого невозможно собрать низкоуровневый "тонкий" слой абстракций над GPU, by design. Оно совсем не это. То-есть если это попытаться, из-за вон того перфоманс будет полным УГ, потому что GL не про просто и не про быстро - и никакого смысла в этом комбо просто нет. Прелесть вулкана в том что это быстрый и прямой интерфейс к GPU без кривого и устаревшего слоя абстракций которые только мешаются нормальным движкам.

А вот наоборот - сделать из vulkan'а GL - фигня вопрос. Вроде даже уже есть такой драйвер.

TL;DR сделать из низкоуровневой штуки высокоуровневую не вопрос, а вот наоборот - упс.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

119. Сообщение от n00by (ok), 06-Июн-24, 21:39   +/
Это в какой ОС? У них вроде бы не только с DX9 были проблемы по началу.

А вообще, это ничего не изменит в плане отказа от устаревающих API. Интел даже своё железо 5-ти летней давности не поддерживает, и это один из крупнейших производителей железа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #122

120. Сообщение от n00by (ok), 06-Июн-24, 21:52   +/
>> C++ is a horrible language

Умело выдернул цитату из контекста:

It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it.

Если это сложно понять, то вот детская загадка:

Идёшь. Видишь впереди дверь. На двери написано "дуракам вход воспрещён". Что будешь делать?

>> Note that no one in their sane mind would expect to use all the features
>> of C++. Just like we have "kernel C" ... we would have "kernel C++"
> А вот это из рассылки текущего года, где Линус не появился. И
> слова про "their sane mind", а точнее, его отсутствие, как бы
> переносятся на Линуса: тот побеждал соломенное чучело, чтобы обосновать своё идеологическое
> (а не техническое) решение.

А зачем ему появляться? Что бы что? У меня conforming implementation стандартной библиотеки для ядра, то есть поддерживаются исключения и typeinfo. Линус прав, я это не использую, и никто не использует. Оно сделано ради "conforming" и для юзерленда. Два человека взяли и сделали, а тут целое сообщество ноет, какой плохой Линус, какие плохие корпорации внедряют Rust и т.п. И это при том, что на всё это код открыт в gcc!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

121. Сообщение от Аноним (-), 06-Июн-24, 22:25   +/
> Напр. rav1d/rav1e вместо dav1d.

ИЧСХ хотя rav1e теоретически где-то есть, реальная борьба идет между сишным libaom и сишно-плюсатым SVT1 :). А rav1e - ну, я живых юзеров оного не встречал. Хотя он формально и есть.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

122. Сообщение от cheburnator9000 (ok), 06-Июн-24, 23:01   +/
> Это в какой ОС? У них вроде бы не только с DX9
> были проблемы по началу.
> А вообще, это ничего не изменит в плане отказа от устаревающих API.
> Интел даже своё железо 5-ти летней давности не поддерживает, и это
> один из крупнейших производителей железа.

Windows конечно же.

https://www.tomshardware.com/news/intel-xe-arc-swap-to-dx9-e...

Хотя нет ошибся, не DXVK, а D3D9On12. Хотя большинству dx9 игр можно подсунуть dxvk dll файлы прямо в каталог с игрой и оно работает везде по-разному.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #127

123. Сообщение от Аноним (123), 06-Июн-24, 23:30   +/
Да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

125. Сообщение от Аноним (29), 07-Июн-24, 04:05   +/
> ... на исправлении своего овнокода годами

Не обязательно своего, иногда чужого. И что??
Плюсовый код вообще с нуля переписывали не так давно.
А про Раст скорее прикольно поддакивать, типа даа, надо на раст, ах вот если бы на раст, но все понимают что это же шутка и трэшак, никто ничего делать не будет.

Просто вдумайся, открыл gdb, пофиксил багу, потом открыл ютубчик, все довольны :)

Надо что-то новое написать - запилил на сишке и опять все довольны. Чтобы добраться до краша - это надо чтобы сначала проект стрельнул, попал в популярный браузер, всех 10 раз похакали, потом ты за 5 минут одной строчкой это починил, согласился что а вот если бы на раст, и пошёл чайку попить

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

126. Сообщение от Аноним (29), 07-Июн-24, 04:10   +/
> Понятное дело что переписать ЭТО на что угодно - это огромная проблема и никто не хочет в это макаться.

Ещё как хочет, гугли libav-rs или что-то такое, там даже бывшие разрабы самого ффмпега клюнувшие на идею. Вот как раз если хочешь поставь себе на дистр вместо ффмпега, так оно безопаснее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

127. Сообщение от n00by (ok), 07-Июн-24, 09:19   +/
>> Это в какой ОС? У них вроде бы не только с DX9
>> были проблемы по началу.
>> А вообще, это ничего не изменит в плане отказа от устаревающих API.
>> Интел даже своё железо 5-ти летней давности не поддерживает, и это
>> один из крупнейших производителей железа.
> Windows конечно же.
> https://www.tomshardware.com/news/intel-xe-arc-swap-to-dx9-e...
> Хотя нет ошибся, не DXVK, а D3D9On12. Хотя большинству dx9 игр можно
> подсунуть dxvk dll файлы прямо в каталог с игрой и оно
> работает везде по-разному.

Я не вполне понимаю, что такое "Native DX9 hardware support". В Windows DX реализован на уровне драйвера - MS требует, что бы он предоставлял определённое API, а dll пространства пользователя выполняют роль обёрток. Если ОС поддерживает DX12, значит железо и драйвер реализует в первую очередь его (отсюда и возникла вся эта история, почему DX12 очень похож на Vulkan - производители железа объяснили MS, что им проще делать универсальный драйвер под все ОС). Там так или иначе происходила эмуляция предыдущих версий DX (двумерный DDraw7 в какой-то момент начали эмулировать через 3D), просто теперь её окончательно вынесли в пространство пользователя, что бы упростить драйвер. OGL там всю жизнь был обёрткой над DX, кстати.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #134

128. Сообщение от АНОНИМ (?), 07-Июн-24, 10:38   +/
Скорее FEX-Emu.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #129

129. Сообщение от анон (?), 07-Июн-24, 15:26   +/
И зачем нам твой говяный FEX, когда есть богоподобный box64 с кодом на 10/10?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

130. Сообщение от анон (?), 07-Июн-24, 15:27   +/
Еще Розетта, кстати. Она ведь под линуксы тоже есть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #132

132. Сообщение от ryoken (ok), 07-Июн-24, 16:26   +/
> Еще Розетта, кстати. Она ведь под линуксы тоже есть

О... А дайте плз ссылок.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

133. Сообщение от Zenitur (ok), 07-Июн-24, 18:44   +1 +/
Моя точка зрения такова.

Разгребая треды 2000 года на сайте ixbt, я узнал, что выбор между Direct3D 7 и OpenGL 1.4, это выбор между предсказуемостью и фичами. Фичи в Direct3D добавляет Microsoft, и никто больше. Тогда как в OpenGL фичи может добавить вендор.

Вот и встаёт перед разработчиком выбор. Сделать более красивую игру, но тестировать её на всех возможных видеокартах (экспериментальные фичи могут быть на одних картах и не быть на других). Или сделать менее красивую игру, зато одинаково работающую на картах всех производителей.

Потом был DirectX 8 и OpenGL стал проигрывать по фичам. Фичи - главный козырь OpenGL, и проигрыш по фичам привёл к падению популярности самого OpenGL.

К 2004 году OpenGL - всё:
* Half Life 2 вышел без OpenGL.
* В Far Cry вырезали OpenGL в последний момент (можно включить в конфиге, но рендер недоделан, то текстуры пропадают, то модели).
* UT2003/UT2004 поддержку OpenGL сохранил.
* Doom 3 вышел провальной игрой.

Каждый новый релиз Direct3D соотносится с новым поколением видеокарт:

* GeForce FX и Radeon 9700 это Direct3D 9
* GeForce 6/7 это Direct3D 9.0b/c
* GF 8 это D3D 10
* Fermi это D3D 11.

А потом случилась беда. Microsoft анонсировал DX12 во время презентации Windows 8. Даже UT4 показывал от Epic Games. Но... DX12 не вышел.

Это был первый случай, когда вендоры выкатили новое поколение видеокарт, а нового директ3д под него нет! А я напомню, вендоры не могут взять и добавить фичи самостоятельно. Только в OpenGL.

Вот тогда-то и решили откопать стюардессу. На сайте developer.nvidia.com начали публиковать экспериментальные драйверы для разработчиков. Там был OpenGL 2015 и OpenGL 2016.

https://www.phoronix.com/news/NVIDIA-OpenGL-2015-Linux
https://www.phoronix.com/news/OpenGL-2016-NVIDIA-Driver

Там были все фичи, которые появились в новой видеокарте Kepler. На Direct3D 11 они были недоступны.

AMD пошла своим путём, сделав Mantle. Mantle позволял задействовать ВСЕ ядра CPU, а не так, что два работают, а два простаивают (или 4 работают, 4 простаивают). Но сложность написания кода игр выросла (некоторый код, который раньше писали разработчики драйвера, теперь пишет автор игры/движка).

Ну и на базе Mantle был создан DX12. А потом спецификации Mantle передали консорциуму Khronos Group, разработчику OpenGL. И они сделали на основе Mantle - Vulkan, который пришёл на смену OpenGL.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

134. Сообщение от cheburnator9000 (ok), 07-Июн-24, 21:24   +/
Вот и я не понимаю почему Intel Ark самые глючные видеодрайвера (а возможно и видеочипы) на ютубе полно видео сравнения. И при том что кушает оно электричества на уровне Nvidia.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #141

135. Сообщение от cheburnator9000 (ok), 07-Июн-24, 21:43   +/
Статтеры пропали потому что в Vulkan (как и в DX12) появилась асинхронная компиляция шейдеров. В DX9/10/11 для отрисовки шейдера он должен был сперва скомпилироваться в рантайме под комбинацию 3D модель + шейдер + текстура + видеочип + версия драйвера. И если что-то из этой солянки обновляется то кешированный шейдер становится не валидным. Именно так постоянно лагала игра Path of Exile.
Тем не менее DX11 из моего опыта 7 летней давности был самым лучшим, потому что управление видеопамятью делал сам. Но как только пошли видеокарты по 4/6/8/10/11/12+GB vram всем на это стало покласть кирпичи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

136. Сообщение от Ivan_83 (ok), 07-Июн-24, 23:52   +/
+1 к тому что у вас экспертиза хромает :)
Я в tmpfs собираю уже очень давно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

137. Сообщение от Ivan_83 (ok), 07-Июн-24, 23:54   +/
Вы бы скачали quemu да пособирали сами чтобы составить представление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

138. Сообщение от Ivan_83 (ok), 07-Июн-24, 23:56   +/
qemu, samba - не мои проекты, я просто иногда их собираю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

139. Сообщение от Ivan_83 (ok), 08-Июн-24, 00:01   +/
Ну написал ты код, он заработал - дальше что с ним таким делать?
Переписывать под петон 4, потом под петон 5 и так далее?
И попутно разгребать 100500 лефтпад зависимостей разных версий.

Код на С как был лет 30-40 назад так и остался, и собирается и работает.
Можешь вон скачать RFC с MD5 и от туда копипастой собрать референс.


> стабильность это когда легаси код поддерживается, а новый пишется не опираясь на старые функции

Так это вы щас за велосипедостроение топите получается.
Типа не надо старую функцию для md5 использовать, надо ещё раз новую md5 написать :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

140. Сообщение от Аноним (140), 08-Июн-24, 00:22   +/
> Asahi — это Fedora

Фиксанул. То что эти кошкобaбы пишут это капля в море и то на основе опенсорсных наработок от Apple.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

141. Сообщение от n00by (ok), 08-Июн-24, 07:41   +/
Наверное, потому что Intel это в первую очередь понты и политика, приводящая к уходу толковых людей во всякие Zilog-и. Сколько у них было громких пустышек? Penium 60, Pentium Pro, Itanic, P4 NetBurst, Intel 740, Curie... Отдадут Ark на доработку второсортному по мнению менеджмента подразделению, те и выкатят 2-ю версию, работающую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

142. Сообщение от Bottle (?), 08-Июн-24, 17:19   +/
Ты ебaнyтый? У Си - медленная компиляция, ты когда-нибудь ядро пытался скомпилировать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

143. Сообщение от Анонимemail (143), 08-Июн-24, 21:22   +/
а на 4 малину так нормальный vulkan драйвер, выпустиь не могут, который год. инвалиды.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #144

144. Сообщение от анонимус (??), 08-Июн-24, 21:44   +/
малинщики безумцы которые выбрали broadcom вместо процессора, apple в данном случае лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру