LINUX.ORG.RU
ФорумTalks

[Qt5][Gallium3D] На llvmpipe (софтварный рендеринг) теперь запускается Gnome Shell


0

3

Сабж.

тык

Для тех, кто в танке: llvmpipe — новый софтварный рендерер opengl (в mesa), использующий llvm и архитектуру gallium. Призван, наконец, нормально реализовать поддержку OpenGL там, где его нет (старое/не поддерживаемое оборудование, виртуальные машины, etc.). В игры на нём не особо поиграешь (хотя, говорят, на хорошем процессоре openarena сносно работает). И версия поддерживаемого OpenGL не такая дохлая, как в старом софтварном рендеринге, а соотвествует поддерживаемой Mesa.

В идеале он даст возможность забить на всё и при написании программ рассчитывать на то, что OpenGL есть везде.

Например, compositing в kwin, compiz, и т.д. (Кстати, имхо, всё идёт к тому, что kwin со временем тоже будет требовать OpenGL ES и режим без него убьют).

Ещё (оправдывая тэг [Qt5]), в Qt всеръёз раздумывают над тем, чтобы в Qt 5 оставить только OpenGL ES для отрисовки (выкинуть raster), чтобы не плодить свой растеризатор, а использовать унифицированный OpenGL ES. В llvmpipe куча оптимизаций (есть и планируется), так что можно ожидать, что даже на софтварном рендеринге OpenGL ES через llvmpipe отрисовка в итоге будет всё равно быстрее, чем на собственном растеризаторе Qt.

Кто не понял, повторюсь: llvmpipe — быстр. Намного быстрее простой софтварной растеризации «в лоб». Как вы думаете, если вы на простой софтварной растеризации того же Qt напишите что-то вроде OpenArena, оно вообще заработает со сносной скоростью хоть на одном десктопе? Так что даже с софтварным рендерингом OpenGL всё будет быстрее, чем сейчас.

P.S. И да, с отрисовкой всего на свете через OpenGL ES, надеюсь, исчезнут вопли про нужность тормознутого и древнего как говно мамонта протокола отрисовки иксов (используемого в Qt native engine). Кому надо — прогонит OpenGL по сети и будет счастлив.

P.P.S. WebGL — OpenGL ES 2.0. Да-да. Может, когда всё созреет, кому придёт в голову написать на основе этого удалённый отрисовщик окон прямо в браузере клиента.

★★★★★

Может, когда всё созреет, кому придёт в голову написать на основе этого удалённый отрисовщик окон прямо в браузере клиента.

уже есть ненужный gnome3 broadway

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

По примеру него. Он всё равно много пиксмапов гонит, если я правильно понимаю. А OpenGL хорош и продуман.

ChALkeR ★★★★★ ()

Ну у меня kwin давно на софтваре работал более менее сносно. Без желейных окон конечно, но таки не сильно медленее, чем макось в софтварном режиме.

Gorthauer ★★★★★ ()

Тогда GNOME3 совсем не нужен будет, т.к. на Fallback забьют.

anonymousss ★★ ()
Ответ на: комментарий от anonymousss

Если Gnome2 был нужен, а Gnome3 с какой-то версии вдруг станет совсем не нужен, то не волнуйся, форкнут.

P.S. Mate Desktop — курам на смех.

ChALkeR ★★★★★ ()
Ответ на: комментарий от ChALkeR

GNOME3 и так не нужен, но есть возможность хотя бы (почти) нормальную панель использовать.

anonymousss ★★ ()

> И версия поддерживаемого OpenGL не такая дохлая, как в старом софтварном рендеринге, а соотвествует поддерживаемой Mesa.

так вроде в обоих случаях 2.1?

cvs-255 ★★★★★ ()

> и при написании программ рассчитывать на то, что OpenGL есть везде.

Хочется взять, и убить, за такую диверсию.

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

Потому что на слабых системах без графического ускорителя это будет тормозить, что п*здец. И вообще, совать GL куда не надо, например в DE, это один из верхов рукожопия.

cvs-255 ★★★★★ ()
Ответ на: комментарий от anonymousss

> (почти) нормальную панель использовать.

Это убожество, а не панель

cvs-255 ★★★★★ ()

про нужность тормознутого и древнего как говно мамонта протокола отрисовки иксов

А это ничего, что этот ваш OpenGL гонится поверх того самого ДКГМПО иксов??? :-)

no-dashi ★★★★★ ()
Ответ на: комментарий от cvs-255

Она у тебя на старом софтварном рендеринге хоть когда-нибудь работала на полноценный 2.1?

ChALkeR ★★★★★ ()
Ответ на: комментарий от cvs-255

Обоснуй. Если OpenGL ES будет везде быстр, а где его не будет — будет быстрый же fallback на процессор (шустрее ручного рендеринга, вроде Qt Raster), то чем это будет плохо?

ChALkeR ★★★★★ ()
Ответ на: комментарий от anonymousss

> Согласен, но вот шелл еще хуже.

потому и перешел на fbpanel + fvwm + gvfs + xfce-power-manager

cvs-255 ★★★★★ ()
Ответ на: комментарий от ChALkeR

> хоть когда-нибудь работала на полноценный 2.1

Не проверял. Но mesa заявляет, что 2.1. Если это не так, то это уже грубое вранье.

cvs-255 ★★★★★ ()
Ответ на: комментарий от Novell-ch

>>умеет и уже очень давно

gearsongallium.blog.com/wp-content/blogs.dir/00/03/88/98/3889805/files/gog/snaps...

я день назад пробовал запускать mutter на китайпаде с месовским GLES. тормоза тормозочки. перерисовка окна секудн 10-20. хотя glxgears с swx11 GL дают 54-64 fps.

exception13 ★★★★★ ()
Ответ на: комментарий от Novell-ch

>>умеет и уже очень давно

меса самасобраная или дистрибутивная? дистр какой? у меня тоже 7.11 но рендер Mesa X11

exception13 ★★★★★ ()

Проприетарные дрова ведь не могут в OpenGL ES. Оно не будет на них работать?

Yareg ★★★ ()

> И да, с отрисовкой всего на свете через OpenGL ES, надеюсь, исчезнут вопли про нужность тормознутого и древнего как говно мамонта протокола отрисовки иксов (используемого в Qt native engine). Кому надо — прогонит OpenGL по сети и будет счастлив.

Да прогнали уже давно. Не пропускай прием лекарств.

tailgunner ★★★★★ ()
Ответ на: комментарий от ChALkeR

>>шустрее ручного рендеринга, вроде Qt Raster
Шустрее, чем Qt на фреймбуфере? Я в это не верю. Фреймбуфер можно юзать и на 50 МГц процах, llvmpipe там, думаю, сольёт.

GAMer ★★★★★ ()
Ответ на: комментарий от ChALkeR

> Ты про какой конкретно драйвер говоришь?

Который Software Rasterizer

OpenGL version string: 2.1 Mesa 7.11

cvs-255 ★★★★★ ()
Ответ на: комментарий от Yareg

OpenGL ES — подмножество обычного OpenGL некоторой версии, в крайнем случае враппер будет.

PolarFox ★★★★★ ()
Ответ на: комментарий от tailgunner

> прогонит OpenGL по сети и будет счастлив.

Привет тормозная сеть

cvs-255 ★★★★★ ()
Ответ на: комментарий от exception13

ну из крупных дистрибутивов вроде еще никто не предоставляет llvmpipe из коробки, это пересобраная меса для моего дистра, и валяется в репах суси.

Novell-ch ★★★★★ ()

>Кто не понял, повторюсь: llvmpipe — быстр

А еще толст и требует лишние сущности.

devl547 ★★★★★ ()

Немного цифр:

Oxygen, Qt 4.8.rc1, qtperf, меса, qt, и драйвера — из пакетов, железо — нетбук c AMD С-50 (видеокарта интегрирована в процессор).

  • Oxygen, native (X11) — 7.21856 msec
  • Oxygen, raster — 0.754944 msec
  • Oxygen, opengl + llvmpipe (софтварный) — 1.65817 msec
  • Oxygen, opengl (хардварный) — 2.31933 msec
  • Plastique, native (X11) — 0.639 msec
  • Plastique, raster —0.178667 msec
  • Plastique, opengl + llvmpipe (софтварный) — 0.263111 msec
  • Plastique, opengl (хардварный) — 0.293722 msec

Пока что raster всех рвёт, но это я не ставил llvmpipe (про который речь в сабже) из гита. Туда всё впиливают фичи и оптимизации.

opengl + llvmpipe обогнал аппаратный opengl за счёт нескольких тестов, в большинстве из них аппаратный opengl чуть быстрее.

Да, что всё работает под всеми режимами правильно — не гарантирую, но сама возможность провести бенчмарки требовала запуска qtperf в этих режимах, и он выглядел и работал нормально в каждом из них. В режиме opengl + llvmpipe есть небольшой глюк с выпадающим меню.

P.S. Напоминаю, что в текущий момент стоит использовать raster.

P.P.S. Да, oxygen — тормознее, но он красив. Если хотите ещё быстрее (чем просто после установки raster) — ставьте plastique или другой простой стиль.

ChALkeR ★★★★★ ()
Ответ на: комментарий от Novell-ch

>>ну из крупных дистрибутивов вроде еще никто не предоставляет llvmpipe из коробки, это пересобраная меса для моего дистра, и валяется в репах суси.

кинь в меня что надо поенаблить для такой сборки.

exception13 ★★★★★ ()
Ответ на: комментарий от tailgunner

Я знаю про всё это. Но в систему по умолчанию оно не ставится, и никто его широко не использует.

ChALkeR ★★★★★ ()
Ответ на: комментарий от cvs-255

Он нормально работает? Когда я его видел последний раз, на нём neverball не работал. То есть работал, но выглядел как будто его только что пережевали и назад выплюнули, а про тормоза и не говорю. Но это было давно.

Как его нынче включить проверить?

ChALkeR ★★★★★ ()
Ответ на: комментарий от ChALkeR

> Я знаю про всё это

Я верю, что ты много знаешь. Но ты очень ловко это скрываешь.

tailgunner ★★★★★ ()
Ответ на: комментарий от exception13

нужно llvm-devel и собрать месу примерно так
--prefix=/usr \
--with-dri-drivers=i915,i965 \
--with-gallium-drivers=r300,r600,nouveau,swrast \
--enable-texture-float --enable-debug --enable-shared-dricore --enable-gallium-egl --enable-openvg --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-gallium-gbm --enable-shared-glapi --enable-gallium-g3dvl --enable-xorg \
--enable-xcb \
--enable-gles1 \
--enable-gles2 \
--disable-glw \
--disable-glut

главное оставить
--with-gallium-drivers=swrast
--enable-gles1
--enable-gles2

Novell-ch ★★★★★ ()
Ответ на: комментарий от GAMer

Я привёл цифры. Сейчас llvmpipe тормознее, но там будут оптимизации. И режим opengl в Qt и llvmpipe в месе активно пилят.

По сравнению с той глубокой жопой, где находится X11 (native), разница между софтварным opengl+llvmpipe и raster даже сейчас не столь велика.

ChALkeR ★★★★★ ()
Ответ на: комментарий от cvs-255

Схренали? Ты знаешь, сколько команд opengl нужно на кадр в том же glxgears, к примеру?

ChALkeR ★★★★★ ()
Ответ на: комментарий от Novell-ch

похоже в моем случае для ARCH != x86 нет --enable-gallium-llvm. надеюсь для armel llvm функционален. примаунтил dev environment по nfs на китайпад, сейчас попробую пересобрать.

exception13 ★★★★★ ()

ChALkeR> кому придёт в голову написать на основе этого удалённый отрисовщик окон прямо в браузере клиента.

Про GTK слышал?

Quasar ★★★★★ ()
Ответ на: комментарий от ChALkeR

> Как его нынче включить проверить?

запусти с драйверов fbdev

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

Обманываешь ты меня. LIBGL_DRIVERS_PATH надо крутить тут.

У меня без танцев с бубном не выйдет, к сожалению.

В арче /usr/lib/xorg/modules/dri/swrast_dri.so это ссылка на галлиумовый /usr/lib/xorg/modules/dri/swrastg_dri.so, старого swrast просто нет.

ChALkeR ★★★★★ ()
Ответ на: комментарий от cvs-255

>>Потому что на слабых системах без графического ускорителя

Где? Где такие системы, покажи.

Behem0th ★★★★★ ()
Ответ на: комментарий от cvs-255

Что-что? Цифры посмотри, я выше приводил. На сраном нетбуке opengl+llvmpipe (софтварный!) шустрее, чем native (X11) и даже сейчас сравним с raster.

ChALkeR ★★★★★ ()
Ответ на: комментарий от ChALkeR

> Обманываешь ты меня. LIBGL_DRIVERS_PATH надо крутить тут.

А что же по твоему я проверил?

cat: /usr/lib/xorg/modules/dri/swrast_dri.so: Нет такого файла или каталога

cvs-255 ★★★★★ ()
Ответ на: комментарий от ChALkeR

это старая меса походу, уже давно swrastg_dri.so нет, llvmpipe компилится в swrast_dri.so и заменяет собой остальные.

Novell-ch ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.