Главная » Хабрахабр » Мой любимый файл в кодовой базе Chromium

Мой любимый файл в кодовой базе Chromium

Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json

Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. О чём вообще идёт речь? В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). Ага, вот так берём и отрисовываем, конечно.

Языкам и их стандартным библиотекам такие мелочи не интересны. Начнём с того, что в языках программирования почему-то нет из коробки функции «взять и нарисовать вот это на экране». Всякие крутые ААА-игры обходят это ограничение достаточно прямолинейно: «У вас должна быть вот такая приставка или вот такая ОС с видеокартой баксов за 800, тогда кое-как будет работать. Соответственно, универсальный кроссплатформенный код для рисования написать не так-то легко. Спасибо за совет! Наверное». Браузер должен работать всегда и везде. Но браузер — это не игра. С другой стороны, и игроман, отдавший почку за видеокарту, захочет посмотреть в браузере 8к-видео, покрутить 3д-модели, ну и может быть даже плавненько поскролить фейсбук-ленту. Пользователь даже самого убитого ПК, купленного 10 лет назад (и уже тогда — на распродаже) не рассчитывает поиграть в последнего Ведьмака, но будет искренне возмущен, если не сможет открыть в браузере свою почту или погуглить что-нибудь.

Всё это заставляет разработчиков Хромиума буквально разрываться: с одной стороны, они до сих пор поддерживают рисование древними технологиями вроде GDI и DirectX9, чтобы работать на устаревшем оборудовании, но с другой стороны они пилят поддержку последних версий OpenGL, DirectX11 (или уже 12?) и Vulkan — что даёт возможность развернуться по полной современным устройствам (в том числе и мобильным).

Чего совершенно не происходит. Но и это всё было бы ещё полбеды, если бы весь этот зоопарк работал так, как он должен работать согласно спецификации. Но, кроме реального железа и его драйверов у нас ничего другого нет. Реальное железо и его драйвера нарушают всё: маркетинговые обещания покупателям, технические спецификации, общепринятые стандарты, сертификационные тесты, совместимость с ОС, планы по выпуску обновлений и т.д. Вот об этом и повествует вышеупомянутый файл gpu_driver_bug_list.json. Поэтому приходится работать на том, что есть.

Так, при некритичных проблемах, например, с DirectX11, будут произведены попытки отключать определённые части его функционала, жертвуя производительностью, но сохраняя работоспособность. Кстати, заслуживает уважение то, насколько браузер пытается «выжить любой ценой». Ну и при полном отказе системы DirectX произойдёт переключение на GDI — что ударит по процессору и потреблению ОЗУ, но всё же удержит производительность для обычных страниц (без тяжелого видео или 3D) на уровне, при котором пользователь, скорее всего, даже не поймёт, что что-то идёт не так. При более серьёзных багах — DirectX11 будет отключен и браузер перейдёт на DirectX9, где также (при необходимости) будут «отрезаться и выбрасываться» проблемные компоненты. Дух захватывает. Там, где другие программы уже попросят обновить драйвера или сменить видеокарту — Хромиум просто продолжит работать.

Количество отдельных записей в нём: 215 штук. Давайте уже посмотрим на содержание упомянутого мною файла. 215 раз приходилось искать правильную конфигурацию железа и софта для воспроизведения проблемы и находить её решение. 215 раз, когда разработчик железа соврал, поленился, был глуп или пожадничал. Трудно сказать, сколько раз было решено не фиксить проблему — но, поскольку вокруг нас полно людей со старым железом и как-то совсем мало тех, у кого «в Хроме гугл не открывается», можно предположить, что таких случаев было совсем немного.

Выводы отсюда можно делать разные. Следующее интересное наблюдение — распределение по ОС: 89 — android, 44 — macosx, 34 — linux, 26 — win, 8 — chromeos. С другой стороны, не понятно почему они были угроханы в фиксы в кодовой базе Хромиума, а не драйверов или ОС (ведь у Гугла там достаточно высокий уровень контроля всего на всех этапах). С одной стороны, очевидно, что андроид — ключевая платформа для Гугла и в исправление багов на нём были угроханы колоссальные средства. Скорее всего дело во взаимодействии департаментов, когда программисту Хромиума проще исправить проблему у себя в коде здесь и сейчас, чем эскалировать её на 3-4 уровня вверх, потом в сторону, а потом на 3-4 уровня вниз. Исправления там принесли бы пользу всему софту на андроиде, а здесь — только Хромиуму. Людей, которым такое интересно, в любой компании меньше, чем нужно было бы.

Мне казалось, что там всё очень ограничено по железу и вылизано по драйверам. Меня сильно удивило, что багов отрисовки в Mac Os было обнаружено почти два раза больше, чем в Windows. Прямо «Собор и базар» в иллюстрациях. Но вот оказалось, что зоопарк Windows в два раза более живуч и стабилен. Или просто сами разработчики Гугла тестируют код на одних маках?

Не думаю, что софт или железо Интела вот прямо хуже — скорее, сказывается массовость продуктов. Интересно и разделение по вендорам: Nvidia — 22, AMD/ATI — 17, Intel — 30. Баг, случающийся у 0. Каждый, кто не покупает специально «игровой комп», скорее всего покупает что-то с интегрированной интеловской видеокартой. «Большая сила влечёт за собой большую ответственность». 001% юзеров, будет годами жить в видеокарте от NVidia или ATI, но приведёт на форумы и в соцсети кучу разгневанных пользователей в случае с Интелом.

Но это не потому, что OpenGL такой плохой, а DirectX такой хороший. Забавно выглядит разделение по багам OpenGL и DirectX: OpenGL — 16, DirectX — 0. Тут дело в том, что все баги категории «win» (вот те 26 штук) это на самом деле баги DirectX (ну ок, не все, но почти все).

Давайте уже перейдём на личности, а там и до мордобоя, глядишь, недалеко! Но ладно, хватит тут обвинять всех подряд обобщённо.

У людей перестал работать в коде унарный минус и функция арктангенса на некотором железе от Intel и NVidia. Вот, например, запись 211, ссылающаяся на баг 672380. Казалось бы, во что дальше верить? Унарный минус, блин, и базовая тригонометрия! А нет, исправили и работает.

Программист всё сделал верно, все функции отработали и вернули «успех», но вот на экране в результате отображается пиксель не того цвета. Или вот записи о «неправильно отображаемых цветах» вроде №185, 219, 220 и некоторых других. Кстати, вопрос поклонникам теории о том, что тестами можно покрыть всё: как бы вы покрыли тестами вот это? Ах да — только вот на этих видеокартах и этих версиях драйверов.

Ну то есть вышла операционка, всем раструбила, что у неё есть акселерирование декодирования такого-то видео. Вот ещё классная штука, №224: «VPx decoding isn't supported well before Windows 10 creators update». И лучше его отключить. Но на практике оказалось, что оно-то есть, но такое, что лучше бы его вообще не было. «Где мои 60 fps и почему ваш браузер съел 4 ГБ ОЗУ» — знакомый разговор, правда? В результате — разработчик ОС продаёт очередной миллиард платной ОС, а разработчик бесплатного браузера собирает жалобы на то, что видео играет как-то не так плавно, как хотелось бы, хотя, казалось бы, и железо, и ОС должны бы позволять!

Разрабатывали мы, значит, разрабатывали новые поколения процессоров одно за другим, рекламировали, продавали. И сразу её догоняет запись №225: «VPx decoding is too slow on Intel Broadwell, Skylake, and CherryView». Пусть прикладники как-то там костылём подопрут, а мы потом поправим. Но проблемы конечного юзера — это проблемы конечного юзера, кого там они волнуют.

Вот, мол, какой хороший ноутбук с двумя видеокартами — в играх будет всё быстро, а в офисных программах (типа браузера) — будет очень энергоэкономно, ННадцать часов от батарейки проработает! Отдельная песня — так называемая «Switchable graphics», которую очень активно втюхивают продавцы в магазинах. А теперь смотрим на горькую правду жизни: на Windows это приведёт к полному отказу от DirectX11 (запись №100), а на маках будет крешится так часто, что мы не-дискретную карту лучше вообще отключим навсегда (запись №228).

Решение тоже прекрасно: «dont_initialize_uninitialized_locals». Или вот №242: «Code produced by local variable initialization often triggers crashes in Marshmallow Adreno driver». А вот в коде столь массового продукта как Хромиум — приходится жить и с этим. Ну вот какие нормальные люди согласились бы что-то писать под платформу, где локальные переменные нельзя инициализировать при объявлении, потому, что от этого драйвер падает?

DirectX10 был одной из основных фич Vista при релизе, а через какое-то время под неё вышел и DirectX11, я до сих пор помню коробки видеокарт тех времён с гордыми надписями «DirectX11 compatible». №26: «Disable use of Direct3D 11 on Windows Vista». Прошли годы — и вот поддержка DirectX11 (продукт Microsoft) в ОС Windows Vista (продукт Microsoft) оценена на уровне «не поддерживается». А для многих это была вообще единственная причина перехода с привычной и стабильной XP. Прямо признание заслуг!

Ладно, мне надоело выбирать частности, читайте остальное сами — там хорошо описаны и причины багов, и реализованные костыли, плюс ссылки на багтрекер есть (поле «cr_bugs»).

Мораль

Во-первых, все врут. Во-вторых, даже в условиях, когда все врут, всё ещё возможно написать качественное ПО. И в-третьих, в следующий раз, когда кто-то будет вам рассказывать, как современный веб пришел к успеху благодаря «мощи HTML, CSS и прекрасного языка Javascript» — покажите ему эту статью и спросите, как бы оно всё работало и кому бы было нужно без вот этого героического труда невидимых людей в стремлении «взлететь со всей этой фигней».


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Современная веб-разработка: выбери себе приключение

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

Oh, My Code: Как стать успешным в IT

Что нужно, чтобы добиться успеха в IT? Об этом и многом другом мы поговорили в новом выпуске ток-шоу Oh, My Code с Дмитрием Гришиным, сооснователем и председателем совета директоров Mail.ru Group, основателем Grishin Robotics. Не могу не начать наш разговор ...