Независимый разработчик Marek Olšák продолжил (http://lists.freedesktop.org/archives/mesa-dev/2012-November...) оптимизировать узкие места в открытом графическом стеке. На этот раз он решил вынести ряд тяжелых операций в нити (thread offloading). В частности, ведется работа над реализацией асинхронных SwapBuffer-ов, работа с которыми ведется в отдельной нити.
Подобная инициатива позволит заметно увеличить скорость работы программ, которые ограничены производительностью CPU, например таких как игра OpenArena. Общая идея состоит в том чтобы с буферами работала отдельная нить драйвера, а библиотека libGL только инициировала эту операцию и получала уведомление о ее завершении через callback-функцию. К этому моменту можно обработать часть нового кадра не дожидаясь завершения (потенциально длительной) операции с буфером.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTIyOTY
Новость: http://www.opennet.me/opennews/art.shtml?num=35356
>Меса — это вообще не драйвера ни разу.
>Меса — это реализация opengl.Ага, щаз.
Ну уж если к концу 2012 года в головах нет ясности что да как, прочтите
http://habrahabr.ru/post/148954/
А то пишешь всякую чушь
>И для тех кто в теме — опенарена (и все подобные, например смокинганс и этк) указана потому, что её движок был написан ещё в допотоковую эпоху, поэтому жрёт на 100% только один процДа, тогда ещё не было понимания и не существовали Vertex Buffer Object и GLSL
> http://habrahabr.ru/post/148954/По ссылке:
> К чему всё это? К тому, что, например, когда вы запускаете утилиту типа glxgears, она загружает mesa. Mesa загружает libdrm. Libdrm общается с драйвером ядра, используя GEM/TTM
>Mesa загружает libdrmШтука в том, что libgl.so для каждой железяки свой.
И?
брехня.
# ls -l /usr/lib64/libGL.so*
lrwxrwxrwx 1 root root 32 нояб. 15 14:23 /usr/lib64/libGL.so -> opengl/xorg-x11/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 32 нояб. 15 14:23 /usr/lib64/libGL.so.1 -> opengl/xorg-x11/lib/libGL.so.1.2
# ls -l /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2
-rwxr-xr-x 1 root root 405648 сент. 24 00:22 /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2
# equery belongs /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2
* Searching for /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2 ...
media-libs/mesa-8.0.4-r1 (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2)>Штука в том, что libgl.so для каждой железяки свой.
не для железки, а для каждой реализации opengl.
т.е. для меса это будет один файл (см. выше), а для блобов нвидиа — другой.
А теперь правильный ответ: libGL обращается к dri-драйверу, который является реализацией OpenGL для каждой конкретной железяки/семейства, который в свою очередь обращается к libdrm, которая в свою очередь обращается к интерфейсу ядра в доме, который построил Джек/thread
>dri-драйверу, который является реализацией OpenGL для каждой конкретной железяки/семействаболее глупой чуши я ещё не слышал. http://dri.freedesktop.org/wiki/
>Mesa is an open-source OpenGL implementation, continually updated to support the latest OpenGL specification.
>The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa.предложение «The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa.» переводится так:
«Наиболее важное применение DRI — это создание аппаратной акселерации в реализации opengl MESA»DRI — ни разу не opengl. Позволяет задействовать аппаратное ускорение в реализации opengl. а именно в MESA. Хотя меса может использоваться и в software opengl (NoDRI option to xorg.conf)
Вам лучше молчать, чем говорить.
>Позволяет задействовать аппаратное ускорение в реализации opengl.Задача драйвера видеокарты, напомни-ка мне, какая? Это раз.
ДРИ часть месы, это два. Причём dri у каждой железяки свой
ну, шарик, ты вАбще дебил. DRI — не часть mesa. И ДАЖЕ НЕ ПОСТАВЛЯЕТСЯ С МЕСОЙ.
более того, тебе идиоту уже писал, меса может работать без DRI.# grep DRI /var/log/Xorg.0.log
[329069.640] Initializing built-in extension XFree86-DRI
[329069.640] Initializing built-in extension DRI2
[329069.644] (**) intel(0): Option "DRI" "True"
[329070.006] (II) intel(0): [DRI2] Setup complete
[329070.006] (II) intel(0): [DRI2] DRI driver: i965
[329070.006] (II) intel(0): direct rendering: DRI2 Enabled
[329070.368] (II) GLX: Initialized DRI2 GL provider for screen 0
(для дэбилов — built-in!!!!!)
DRI — часть иксов.а интерфейсная часть к железу в:
$ equery belongs /usr/lib64/xorg/modules/drivers/intel_drv.so
x11-drivers/xf86-video-intel-2.20.13 (/usr/lib64/xorg/modules/drivers/intel_drv.so)
$ eix x11-drivers/xf86-video-intel
[I] x11-drivers/xf86-video-intel
Available versions: ~*2.8.1 … {{debug dri glamor (+)sna +udev uxa xvmc}}
Installed versions: 2.20.13{tbz2}(09:57:26 18.11.2012)(dri sna udev xvmc -glamor -uxa)
Homepage: http://xorg.freedesktop.org/
Description: X.Org driver for Intel cards
(для дэбилов — intel_drv.so идёт в x11-drivers/xf86-video-intel)
мде
src/mesa/drivers/dri
а-ха!
это dri-driver, а не драйвер.
интерфейсная часть к dri. по существу плагин.к увеличению скорости (с чего всё и началось) не имеет отношения.
> а-ха!
> это dri-driver, а не драйвер.
> интерфейсная часть к dri. по существу плагин.
> к увеличению скорости (с чего всё и началось) не имеет отношения.мде^2
Да, это DRI. Тот самы драйвер, о котором ты писал:
>DRI — не часть mesa. И ДАЖЕ НЕ ПОСТАВЛЯЕТСЯ С МЕСОЙ.
а DRI — не часть mesa.
и dri-driver всего-лишь (не очень удачное название) интерфейс к dri и сисколам ядра.в любом случае, если ты в экспортируемых символах библиотеки
$ nm -C -D /usr/lib64/mesa/i915_dri.so ( http://pastebin.ru/Cm39CXkL )
найдёшь реализацию opengl, как тут сказано:
>А теперь правильный ответ: libGL обращается к dri-драйверу, который является реализацией OpenGL для каждой конкретной железяки/семейства,и я пожму твою лапу и признаю, что был не прав. :D
правильный ответ такой — в меса поставляется интерфейсная часть для вызова функций аппаратного ускорения (сисколов) в драйверах конкретных видео-карт.
сам интерфейс называется DRI (о чём и говорит I), предоставляется иксами, а драйвера видекарт поставляются отдельно частично в драйверах (например x11-drivers/xf86-video-intel), частично в самом ядре (drm).
всё.
> и dri-driver всего-лишь (не очень удачное название) интерфейс к dri и сисколам ядра.По-моему, вы пытаетесь сказать одно и то же но разными словами. Вот и затупляете на пару.
Ну посмотрите с чего началась ветка.
>> и dri-driver всего-лишь (не очень удачное название) интерфейс к dri и сисколам ядра.
> По-моему, вы пытаетесь сказать одно и то же но разными словами. Вот
> и затупляете на пару.По-моему кто-то просто вилять пытается и представить как будто имел в виду совсем другое, когда говорил(если не сказать как есть: кричал и называл всех несогласных дебилами), что в Mesa нет драйверов и что она не реализует DRI.
> в Mesa нет драйверов и что она не реализует DRI.в меса нет драйверов.
и она не реализует DRI.
:D
>> в Mesa нет драйверов и что она не реализует DRI.
> в меса нет драйверов.
> и она не реализует DRI.
> :DВот видишь, Аноним, он опять за своё, а ты говоришь, что мы об одном и том же.
Ну вот зачем ты виляешь? От одного отмазываешься, в другом сразу закапываешься.
Ну входят в состав Месы драйвера, даже если теперь ты их называешь интерфейсом, это драйвера и всегда назывались драйверами. Для 2D это называется xorg драйверами, для 3D это сейчас DRI драйвера. И в проприетарных видеодрайверах такая же схема: есть драйвер ядра и есть драйвер юзерленд. И нет, это не просто интерфейс, а реально транслирующий код. Посмотри хотя бы на размеры *dri.so и libdricore из Месы.>>>А теперь правильный ответ: libGL обращается к dri-драйверу, который является реализацией OpenGL для каждой конкретной железяки/семейства
>и я пожму твою лапу и признаю, что был не прав.Причем здесь та фраза и моя правость? Это не я писал. Это всего навсего не совсем точный (хабро)?перевод вот этой фразы
"When using direct rendering, libGL loads the appropriate 3D DRI driver then dispatches OpenGL library calls directly to that driver."
отсюда: http://dri.freedesktop.org/wiki/libGL
Под этим могу подписаться.>сам интерфейс называется DRI (о чём и говорит I)
Если бы я как некоторые придирался к словам, я бы сказал , что I говорит Infrastructure.
>а драйвера видекарт поставляются отдельно частично в драйверах (например x11-drivers/xf86-video-intel)
Это вообще 2D Xorg драйвер, который тем не менее тоже может использовать DRI.
>Ну входят в состав Месы драйвера,и не входят. и это что, сложно понять?
>Причем здесь та фраза и моя правость? Это не я писал.а зачем отвечал?
был солидарен с ним, что и дрова в меса есть, и «dri-драйверу, который является реализацией OpenGL»?
угу.
>отсюда: http://dri.freedesktop.org/wiki/libGL
>Под этим могу подписаться.угу. libGL implements the GLX interface as well as the main OpenGL.
совсем забрехался.
>>>а драйвера видекарт поставляются отдельно частично в драйверах (например x11-drivers/xf86-video-intel)
>Это вообще 2D Xorg драйвер, который тем не менее тоже может использовать DRI.и добавить не забудь не вырванное из контекста.
а именно — доступ к оборудованию возможен только через кернел-спейс.
и 80% из экспортируемых этой библой (на которую ты уповал) — это просто вызов drm.
>совсем забрехался.Долгожданная ложка самокритики? Удивлён, но одобряю.
>DRI — ни разу не openglКонечно, ведь тёплое это не мягкое: dri-драйвер в Mesa реализует (аппаратное ускорение) OpenGL, enjoy your ignorance, хабрахомячки
dri-драйвер не в меса. ты читать не умеешь? или тупой?
могу повторить.
http://dri.freedesktop.org/wiki/
>The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa.DRI — часть иксов.
с MESA не поставляется.
>DRI — часть иксов.
>с MESA не поставляется.Доо-о, а тот же r600_dri.so и компания, размером 20+ Мб тоже наверное частью иксов являются, и каталоги /src/gallium/drivers/* в исходниках месы, из которых эти бинарники получаются чисто для отвода глаз? =) Глупые хабра-дети ничему не учатся
да хоть ду-ду-ду, а содержит в основном тэмплэйты к С++ и llvm
>void std::_Destroy_aux<false>::__destroy<__gnu_cxx::__normal_iterator<llvm::InlineAsm::SubConstraintInfo*, std::vector<llvm::InlineAsm::SubConstraintInfo, std::allocator<llvm::InlineAsm::SubConstraintInfo> > > >(__gnu_cxx::__normal_iterator<llvm::InlineAsm::SubConstraintInfo*, std::vector<llvm::InlineAsm::SubConstraintInfo, std::allocator<llvm::InlineAsm::SubConstraintInfo> > >, __gnu_cxx::__normal_iterator<llvm::InlineAsm::SubConstraintInfo*, std::vector<llvm::InlineAsm::SubConstraintInfo, std::allocator<llvm::InlineAsm::SubConstraintInfo> > >)( см. $ nm -C -D /usr/lib64/mesa/r600g_dri.so )
и понадобилось всё это из-за вот этого:
http://www.opennet.me/opennews/art.shtml?num=17139
>Компания AMD открыла исходные тексты новой версии парсера AtomBIOS, библиотеки для эффективного взаимодействия с BIOS видеокарт (вместо низкоуровневого программирования регистров предлагается использовать уровень абстракции видеоBIOS).вот так-то.
зыж
ну и что ты хочешь? интерфейс к современным видиокартам не фунт изюма.
Лол, это значит парсер к AtomBIOS занимает ~4МБ, и для интеловских карточек, и для swrast?!Самому не смешно? :D>да хоть ду-ду-ду, а содержит в основном тэмплэйты к С++ и llvm
Узелковое мышление в действии, пробуем исправить через readelf -a r600_dri.so:
>Dynamic section at offset 0x43da80 contains 31 entries:
> Tag Type Name/Value
> 0x00000001 (NEEDED) Shared library: [libdrm.so.2]
> ...
>Symbol table '.dynsym' contains 186 entries:
> 5: 00000000 0 FUNC GLOBAL DEFAULT UND drmIoctl
> 50: 00000000 0 FUNC GLOBAL DEFAULT UND drmFreeVersion
>109: 00000000 0 FUNC GLOBAL DEFAULT UND drmCommandWriteRead
>144: 00000000 0 FUNC GLOBAL DEFAULT UND drmGetVersion+ весь набор трансцендентных функций из libm - это НЕСОМНЕННО нужно для LLVM, которого у меня в системе нет, ага :D
>> http://habrahabr.ru/post/148954/
> По ссылке:
>> К чему всё это? К тому, что, например, когда вы запускаете утилиту типа glxgears, она загружает mesa. Mesa загружает libdrm. Libdrm общается с драйвером ядра, используя GEM/TTMЕсть драйвера ядра, а есть юзерлэнд драйвера, которые тоже железоспецифичны. Последние сейчас входят в состав Mesa.
ЗЫ популярная статья, перевод которой на хабре, ИМХО шлак. Хаброперевод думаю тоже шлак(хотя не читал), получается шлак в квадрате.
>>Меса — это вообще не драйвера ни разу.
>>Меса — это реализация opengl.
>Ну уж если к концу 2012 года в головах нет ясности что да как, прочтите
>http://habrahabr.ru/post/148954/
>А то пишешь всякую чушьт.е. даже после прочтения этого ты утверждаешь, что меса — это драйвер?!!!!
вау!
реализации opengl как правило ПОСТАВЛЯЮТСЯ с драйвером, но это ни разу не драйвер.это ж какой бред у вас в голове должен быть, когда на неправильно сформированные понятия ещё и вылить такой суп сверху.
Для него и DirectX наверно драйвер мультимедийных устройств)
> т.е. даже после прочтения этого ты утверждаешь, что меса — это драйвер?!!!!
> вау!
> реализации opengl как правило ПОСТАВЛЯЮТСЯ с драйвером, но это ни разу не
> драйвер.
> это ж какой бред у вас в голове должен быть, когда на
> неправильно сформированные понятия ещё и вылить такой суп сверху.Я утверждал, что меса это и реализация огл и открытые драйверы для конкретных карт. А то, что после тобой написанного, получалось, что проект меса чуть ли нештатная разделяемая библиотека уровня libjpeg.
>нештатнаячуть ли незаштатная
>Я утверждал, что меса это и реализация огл и открытые драйверы для конкретных карт.я правильно понимаю, что если расставить знаки препинания, то ты имел в виду:
>Я утверждал, что меса это и реализация огл, и открытые драйверы для конкретных карт.Так вот, это чушь.
В составе меса НЕ идут драйвера.
более того, меса полностью в user space.>А то, что после тобой написанного, получалось, что проект меса чуть ли нештатная разделяемая библиотека уровня libjpeg.
так и есть. :D
при чём согласно как стандарту на opengl, так и самому названию (GL).
это уже даже несмешно. Успокойся.
И да, выхлоп emerge ни разу не доказательство
разумеется не смешно — твоей дубоголовости поражаешься.
>И да, выхлоп emerge ни разу не доказательствозато вот это доказательство.
http://dri.freedesktop.org/wiki/
>Mesa is an open-source OpenGL implementation, continually updated to support the latest OpenGL specification.
>The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa.но ты видимо совершенно туп.
зыж
для тупых ещё раз повторю:
>The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa.
>The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager).
>is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager).
>is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner.under the X Window System in a safe and efficient manner.
Это поднимет производительность отрисовки динамически сменяющих друг друга 3D-сцен примерно в три раза на современных 4-8 ядерных CPU (приходится учитывать потребности в вячислительных ресурсах других приложений/нитей).
> в три раза на современных 4-8 ядерных CPUМечтать не вредно - одна только асинхронная перекачка буферов все в целом в 3 раза врядли разгонит. Но часть кадра посчитать пока буфер заливается - очень даже можно. Распараллеливание операций налицо.
Только вот ядерный тред делающий heavy lifting и провоцирующий коллбэк должен быть в ядреном драйвере GPU, если что. Я думаю ты понимаешь, что это означает...
> Это поднимет производительность отрисовки динамически сменяющих друг друга 3D-сцен примерно в...Не факт.
Если приложение само утилизирует имеющиеся ресурсы (возможно ограниченные например сигропс), то сабж може и помешать планировщику за счет лишнего переключения контекстов выполнения.Для опенарена — да.