Обновить
4

Пользователь

Отправить сообщение
Я бы еще упоминание apitrace добавил. Не раз выручал меня, несмотря на наличие навороченных отладчиков.
Тоже делал нечто подобное, только в лине напрямую futex`ы использовал еще.
Тогда могу еще посоветовать посмотреть настройки PulseAudio и убедиться что resample-method стоит максимального качества.
Ну к проигрыванию это тоже относится. Современные системы умеют смешивать звук от разных программ, которые не обязательно используют один и тот же sample rate. Так что им приходится ставить микшер и ресамплер, а это лишний процессинг. Так что открытие устройства в эксклюзивном режиме (по принципу кто первый открыл того и тапки) решает эту проблему, там никакого процессинга нет.
Чтобы провернуть это на лине вам может потребоваться остановить pulseaudio\JACK, т.к. это как раз тот звуковой сервис который смешивает. Обычно даже ALSA в системе настроена так ALSA(не эксклюзив)->PulseAudio->ALSA(зксклюзив).
Но вообще я бы не заморачивался, лично я разницы не ощущаю.
Для макс качества надо просто чтобы аудио записывалось в эксклюзивном режиме, помимо всякого аудио процессинга системного (обычно там как минимум ресамплер\микшер стоит чтобы смешивать от всех программ из разных рейтов). На винде тоже так можно, через WASAPI, так же может потребоваться отключить Stereo Mix девайс. На лине просто ALSA в эксклюзивном режиме.
Да нет, про говонокод много где я согласен. Имел опыт вычищать ошибки valgrind из gtk и wxWidgets проектов. И сорсы win2000 утекшие я тоже изучал. Например про то как там сокеты сделаны сбоку к ядерному объекту и что производительность у них не очень. И еще несколько примеров плохого API помню из обоих миров.

Однако есть и примеры хороших по качестку проектов: Qt, skia, fastuidraw…

Вот только в винде все кинулось в дотнет. А базовая winapi платформа так и стоит без изменений, те же сокеты так никто и не оптимизирует. Новость вот недавно была что asp.net core до лимона запросов в сек оптимизировали, ага, много маркетинговой воды, а тех детали что это на 40 ядерном сервере надо еще поискать. Ищем бенчмарки и видим, что ровно на этом же жележе другие фреймворки даже на java дают 6 лимонов. Смотрим сорсы — вау вот же он самый быстрый бенчмарк же, меряет производительность winapi сокетов. Ааа, ну это я и сам мерял недавно, на моем простом железе 60к против 140к rps линух.

Из улучшений winapi с висты могу отметить только QueryProcessCycleTime\QueryThreadCycleTime, ETW API, там еще по мелочи типа CallNtPowerInformation чтобы узнать частоту проца. Причем со своими новомодными UWP приложениями нижнеуровневое апи они порезали. Причем порезали даже важное, вроде GetThreadTimes.

А еще на винде стали часто ломаться утилиты для разработчиков. В XP у меня был рабочий аналог strace, который реально перехватывал SDT. Сейчас максиум хуки или рекомпиляция как в drmemory.
Или вот perf в лине как работал так и работает, с хардварной поддержкой перформанс эвентов от проца. А в винде у меня ломался vtune, потом еще что-то следеющее от интеля. В студии тоже этот драйвер ломался, в 2008, моей любимой студии сломался навсегда. Точность результатов под виндой тоже была хуже.

А еще под виндой началась телеметрия и логины онлайн, микротранзакции. Вот уж что мне нужно было, браво. Итд итп, вот так и живем, чтобы разревирсить виндовую малварь, которая делает напрямую sysenter я уже гружу линух. Пока еще живем, с винды я еще до конца тоже не ушел, но мой интерес к ней уже сильно снизился.
У меня 7 секунд на ssd, да, это дольше чем сусе (и видимо арч).
Вы и правда с чем-то оттуда столкнулись или просто теория?
От некоторых пунктов глаза на лоб едут.

>certain OpenGL features cannot be enabled in Linux due to patents (like S3TC texture compression and floating point textures).
Wat? В проприетарном драйвере все есть
   glxinfo | grep s3tc                                                                                                                                                                       
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
    GL_NV_viewport_array2, GL_NV_viewport_swizzle, GL_S3_s3tc,
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
    GL_NV_viewport_array2, GL_NV_viewport_swizzle, GL_S3_s3tc,
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc,
    GL_NV_texture_compression_latc, GL_NV_texture_compression_s3tc,
    GL_NV_texture_compression_s3tc_update, GL_NV_timer_query,

А float point текстуры я и сам юзаю, там и у mesa все хорошо. А в винде товарищ их не из проприетарного берет? То есть что под виндой опенсорсного драйвера нет вообще это минус линуху?
К тому же расширение это давно никто не использует.

Под линем прекрасно достигается AZDO, для месы я переживаю за GL_ARB_bindless_texture, которого пока нет, а для Vulkan это все вообще уже не важно.

Некоторые пункты конечно вполне резонны. Но вовсе не из разряда что линь не для десктопа, а скорее как хороший роадмап. Вот примерно так можно пункты разделить:
  • Найди железо которое линем плохо поддерживается. Да спору нет, если железо такое, использовать его не стоит.
  • Мелочи-уловки\пугалки вроде s3tc.
  • Спорные\неверные или верные, но не относящиеся к теме вещи.


Можно даже от противного проверить. Предположим убедили, для десктопа рано. Но тогда я должен наблюдать агонию сотрудников DreamWorks и Pixar, не так ли? А на видео они почему то выходят и виртуозно управляются с Fedora. Как так?
Но так нет же, у них все хорошо, и у меня в частности все хорошо. Так что мой вывод по линку: зерна правды там есть, как и неточностей и не правды. Но вывод что линь все еще не для десктопа в корне не верный.
На nvidia нужно включать full composition pipeline. Это особенность драйвера и оптимизации композитинга, для большинства (мощных прежде всего) компов без этой опции он не заметен.
Значит не только) Arch если честно на ssd еще не пробовал, видимо действительно загрузка уже у многих шустрая.
Вы наверно с MESA путаете, без проприетарного драйвера вы и на nvidia последние поколения нормально не погоняете. А с проприетарным у меня все норм было, в свое время для модуля трассировки лучей именно Polaris использовал, т.к. он был более эффективен цена\скорость в этом сценарии. Взгляните бенчмарки Luxmark. А сейчас поддержка появилась и в mesa (но скорость пока хуже, хотя улучшения стремительные и в части сценариев обгон есть).

Кстати на nvidia сталкивался с проблемами проприетарного компилятора оснезависимые, например в модуле траверса BVH мне пришлось вставлять
#pragma optionNV(inline none)

Чтобы производительность не проседала, хрен додумаешься, случайно получилось побороть.

Про 5K не знаю, но ниже 4K у меня нигде нет. Но думаю это возможно, например тут явно больше 4K.

Про pulseaudio имхо шутка уже давно устарела.
Кстати да, Fedora вкупе с SUSE тоже советую. RHEL не зря стандарт де-факто среди проф. графических приложений, а Fedora это тот же RHEL без поддержки.
Возможно исправился. Это один из немногих дистров, который заботится о времени загрузки, вот например, у меня грузится даже быстрее win10.
Я бы OpenSUSE попробовал. С хардварей проблем не было, но дефолтные хоткеи на убунте меня тоже не устраивали, я привык к ctrl-ins shift-ins и в сусе это можно сделать прямо из настроек. Еще у вас в требованиях не указано, но для таких вещей как ffmpeg стоит добавить доп репозитарии. Обычно packman добавляют.
Стим у меня тоже работал, правда долго я на сусе его не использовал.
Это называется rolling release, он есть и у других дистрибутивов. Штука хорошая, да.
Кстати в arch по-моему уже даже в репы включили Far Manager. Так что рабочая лошадка прямо из коробки.
Сейчас провел эксперементы. Соврал я что в GIMP глобальная настройка не будет применяться, все применяется, хардварный LUT похоже все же используется.
«Specifically, if you use a multi-monitor setup with an Nvidia graphics card, you cannot have both 3D acceleration and per-monitor color profiles.» тоже проверил — сейчас все ок на двух мониторах с nvidia драйвером.
А как я описал? В убунту гном, в сусе KDE. Иду в системные настройки, как и на винде, и выставляю icc профиль — все работает.

За все дистрибутивы не скажу, но за Ubuntu\OpenSUSE\Fedora+nvidia я увернен, что цветовые профили работают идеально и для всех приложений.

А какие проблемы изменить для всех? Вы думаете фреймворки будут сами заменять цвета? Еще чего, сейчас везде же композитный менеджер есть (да и до этого только в самом X да gl надо менять), какие пробелмы в нем поменять? На винде с вистой и появлением dwm скорее всего точно так же делается. Все дело исключительно в том хочет ли приложение выполнять коррекцию или нет.

Вы вообще темните, сначала вообще ничего нет, теперь гном с кде якобы не совмещается. Конкретно то что и конкретно где не работает?
Ну дык «Что касаемо оболочек: и gnome и KDE — то они тоже имеют поддержку ICC». Кеды я тоже использую в OpenSUSE, точно так же все работает прямо из системных настроек.
Ремарка на английском — это отсюда? 2011 год? Там и про noveau уже давно устаревшая информация.
Изначально вы вообще говорили что только полузаброшенный гитхаб есть, а реально то у вас что где не работает?
Под убнту — дабл клик на ICC\ICM профиле инсталирует его, потом System Settings->Color и выбираем его. Там же можно посмотреть детали профайла, кривые, тест как он влияет.
Из командной строки тоже можно, вот неплохое общее описание.
А вот из тех проблем что видел — это драйвера видеокарты могут свои индивидуальные фокусы выкидывать. Например винда, nvidia, никаких профайлов нигде не стоит, делаю glReadPixels из 3d проги, вывожу битмап на экран — и вах, цвета разительно различаются. Так же для оверлея делается своя корректировка цвета, но эта настройка уже видна в панели nvidia.

Информация

В рейтинге
5 015-й
Откуда
Россия
Зарегистрирован
Активность