LINUX.ORG.RU

Ответ на: комментарий от CYB3R

Коснётся, но позже. Часть из этих патчей затрагивает все драйверы. Интелоспецифичные части должны допилить работники интела. Кстати Марек использовал некоторые из их патчей.

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

А полный выхлоп glxinfo | grep OpenGL?

У меня

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.7.0-devel (git-4d35eef pontostroy:X11)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.7.0-devel (git-4d35eef pontostroy:X11)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.7.0-devel (git-4d35eef pontostroy:X11)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
Самое главное это «OpenGL core profile version string».

Rakot ★★ ()

OpenGL version string: 2.1 Mesa 10.5.2

Мне ничего не грозит.

SystemD-hater ()
Ответ на: комментарий от Rakot
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.7.0-devel (git-f7aad9d 2015-06-09 utopic-oibaf-ppa)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.7.0-devel (git-f7aad9d 2015-06-09 utopic-oibaf-ppa)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.7.0-devel (git-f7aad9d 2015-06-09 utopic-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

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

Современные приложения считают, что 3.3. Некоторые устаревшие могут думать, что 3.0.

Rakot ★★ ()

с поддержкой OpenGL 4.0~4.2

на бумаге может быть.

x0r ★★★★★ ()

<вброс>Спасибо nvidia и блобу за мое счастливое детство!</вброс>

В nouveau тоже будет? Если да, то годно.

leg0las ★★★★★ ()
Ответ на: комментарий от ranka-lee

Вулкан скоро будет. Развития OpenGL больше не будет.

Ну да конечно. При появлении OpenGL 3.0 старый OpenGL отправился в compatibility extensions, но никуда не исчез. И большинство программ создают себе контекст OpenGL именно с compatibility extensions. OpenGL — тот редкий случай, когда даже в линуксе API работает больше 20 лет без нарушений обратной совместимости и при этом не устаревает.

Переписать старый код на Vulkan — нереальная задача, я уж и не говорю о необходимости выполнять старые скомпилированные бинарники, с которой чаще или реже сталкиваются все. Тем более что даже в OpenGL 3.0 и GLES 2.0 порог вхождения очень высокий и Hello World пишется далеко непросто; в Vulkan простые вещи делаются ещё более сложно и поэтому в большинстве задач вменяемый программист предпочтёт OpenGL, GLES и библиотеки на их основе, а не Vulkan.

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

По идее вулкан и компания (D3D12, Metal) проще чем OpenGL, Меньше сущностей и делает ровно то что ты сказал.

Тем более что даже в OpenGL 3.0 и GLES 2.0 порог вхождения очень высокий

Никаких трудностей не встречал, всё тривиально.

ranka-lee ()
Последнее исправление: ranka-lee (всего исправлений: 1)
Ответ на: комментарий от ranka-lee

На OpenGL 2.x нарисовать кубик, сетку по точкам - совсем просто.

На OpenGL 3.x и 4.x чуть посложнее - нужно явно иметь дело с vertex buffer'ами и шейдерами, но в принципе, то же самое.

Что с вулканом?

Не идет ли все к тому, что «а программируй ка ты всё сам»?

UPD: У них там написано

Direct control over GPU operation, with minimized driver overhead for maximum performance

похоже, так и есть

может тогда вообще выкинуть все это OpenGL, directx, vulcan, оставить один только OpenCL, и пускай те, кому нужна графика, сами все с нуля делают? Никакого оверхеда, максимальный контроль над GPU.

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 4)
Ответ на: комментарий от Stil

Патчи в мае в списке рассылки были. Один товарищ с фороникса даже метро запускал с этими патчами (игра как раз требует GL_ARB_shader_subroutine). Он же уже протестировал тесселяцию, в Unigene Heaven 4.0 работает. Можно видео на ютюбе посмотреть.

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

может тогда вообще выкинуть все это OpenGL, directx, vulcan, оставить один только OpenCL, и пускай те, кому нужна графика, сами все с нуля делают?

Скоро. Сейчас там ещё есть специальные транзисторы которые растеризируют треугольники.

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

http://kunaifusu.livejournal.com/

Скоро кончится второй год 8го поколения а никто не понимает вообще как устроен современный ГПУ. Ну понятно дети в интернете не знают, но программисты, которые пишут игры - тоже в основном ни ухом, ни рылом. Вот я и решил провести разъяснительную работу, в надежде, что хоть кто-то перестанет топтаться на граблях.

Как учит нас марксизм-ленинизм, все развитие происходит по спирали. Первые ГПУ были простыми как валенок - трансформировали вершины и рисовали треугольнички с текстуркой через z-буффер. Все эффекты и фотореализм - запечены в текстуре. Так работали графические «карты» 80х («карты» потому что там было 3-5 плат, размером с материнку, на одной - коммандный процессор, на одной z-буффер, текстурная память, фрейм буффер и т.д.). Так работал GS в PS2 и прочия Voodoo Graphics.

Чисто теоретически, на таком ГПУ можно сделать все что угодно - только успевай текстурки обновлять. Но практически это очень гемморно и дорого, потому как текстурки занимают много памяти и, соответсвенно, обновлять их заколеблешься. Однако, графические программисты давно вкурили, что некоторые эффекты можно делать не обновляя текстуры, а комбинируя их прямо в фреймбуфере, то есть делая несколько проходов с одной и той же геометрией и пересчитывая только текстурные координаты в вершинах для каждого прохода (вершины занимают мало памяти и пересчитывать их можно прямо налету). К примеру, спекулярное освещение можно сделать добавив текстуру с хайлайтом, замапленную на (x,y) трансформированных нормалей в вершинах. Конечно это не точный спекуляр, но неспециалист не заметит разницы. Подобными трюками можно было сделать весьма достоверные модели освещения а ля Фонг-Блинн и кучу эффектов а ля cell shading.

Производители ГПУ, увидев такой криатив со стороны программистов, решили им помочь и впендюрили комбинирование проходов в новые ГПУ. Сначала осторожно, с парочкой состояний, парочкой текстур и несколькими стадиями комбинирования как в Xbox, а потом и с большой стейт-машиной, десятками текстур и хоть тысячами стадий. От таких манипуляций ГПУ проще не стал, а стал походить на швейцарский нож со стопицот лезвий, которые торчали во все стороны и норовили воткнуться куда не надо. Подобные монстроузные ГПУ стоят на PS3 и 360. Проблема с этим подходом была в том, что было очень тяжело ускорять подобную архитектуру. На старых ГПУ с ускорением не было проблем - рисование пикселей это чисто параллельная задача, поэтому добавляя больше юнитов для рисования можно было получить линейный рост производительности. А тут каждый юнит для рисования содержал в себе всю многопроходную тряхомудию и новые просто не помещались на чип, поэтому нужно было исхитриться и как-то поделить всю систему между более простыми юнитами, от чего все становилось еще сложнее и тормознее.

Тут производители ГПУ вспомнили, что они всеж таки инженеры, а не программисты, и использовать программисткие подходы им, вообще-то, западло. И сразу же послали весь геморрой с проходами в другой проход, хехе. Так и появились современные ГПУ, вскоре после выхода PS3.

В современной архитектуре ГПУ вернулся к своим истокам и больше не занимается ничем, кроме рисования треугольников. Причем даже текстуры на них не кладет и вершины даже не трансформирует. Чисто рисует в z-буффер и все. Все вершины, все эффекты, весь фотореализм считает отдельный процессор. Вполне себе обычный процессор с регистрами, инструкциями и памятью. Конечно, поскольку на этом процессоре не нужно запускать 1C, он по-мощнее Пентиума будет, на пару-тройку порядков мощнее может даже. Но это не главное. Главное что теперь путь развития прямой и чистый - хочешь добавляй рисовалок к ГПУ, хочешь - добавляй ядер к процессору, все линейно ускоряется и никаких проблем.

Хотя процессор при ГПУ есть теперь и на консолях и на песи, использовать его на песи для чего-то помимо рисования на ГПУ не особо получится. Мудрые парни из Кронос и МСФТ заложили его таким слоем API, что лучше и не пытаться. А на консолях, во всяком случае на PS4 - без проблем. Хоть всю игру можно на него переписать. Но практически никто не пишет. Почему - загадка природы. Вот буквально сидит народ и неделями пытается срезать полмиллисекунды с ЦПУ, когда переписав на ГПУ можно было бы ускориться в 10 раз. То есть либо не знают, либо просто любят страдать хуйней, либо и то и другое вместе.

ranka-lee ()
Ответ на: комментарий от ranka-lee

Как-то он все больше в сторону консолей пишет. А на PC-шном железе то что?

И да, на PC ускорение графики не только в AAA-YOBA-играх используется и затачивать под конкретный GPU мало кто желает (за пределами игр).

А потому нужно api, независящий от gpu. Как в этом плане у вулкана?

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 2)
Ответ на: комментарий от cvs-255

Новые GAPI как раз не зависимы от конкретного железа. Они просто соответствуют тому что под капотом у всех и уже не первый год. А слово «ускорение» для графики следует кстати забыть уже лет 10 как. Нет ускорения, есть специальный полноценный графический процессор.

ranka-lee ()
Ответ на: комментарий от ranka-lee

Я почему-то прямо чувствую, как все сложнее и сложнее становится использовать графическое api для визуализации, а не для aaa-yoba-игр.

А заодно чувствую, как меня возвращают в школу, где мы на программировании сами «с нуля» рисовали картинку, без использовании opengl/d3d. Теперь похоже будет тоже самое, но только расчеты на gpu.

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Тут фича в том что на GPU 100500 злых ядер, вместо 4-8. Вместо цикла пускаем всё параллельно и всё. Но это надо ещё суметь.

ranka-lee ()
Ответ на: комментарий от ranka-lee

Я в играх ни бум-бум, но считаю, что этим не дураки занимаются. Всегда есть задачи, для которых синхронизация параллельных вычислений съедает больше, чем тупо один поток на CPU. Дело уже не в «суметь», а в «найти».

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

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

ranka-lee ()
Ответ на: комментарий от ranka-lee

Мне интересно, у автора заметки всё ограничивается теорией, или он на практике успешно ускоряет в 10 раз те места, в которых другие миллисекунды вытягивают? А то ведь я тоже могу нахватавшись поверхностных знаний в пляс пойти.

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

У меня даже интереснее пример есть — преобразование YV12 в RGB. Шейдером это очень быстро делается, код идеально параллельный. Но если картинка нужна на CPU, её надо из GPU скачивать, что всю скорость убивает. Быстрее всё полностью на CPU преобразовывать.

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

Это не противопоставление, а использование правильных методов в правильных местах. Типичный пример - сценграф из учебника. Красиво, по всем правилам, но не работает в реальности и не распараллеливается. По тестам получается что часто проще и быстрей использовать тупой массив и тупой брутфорс вместо умной структуры.

ranka-lee ()
Ответ на: комментарий от ranka-lee

Что ж он тогда эту свою идею не развивает? Или этим кто-то другой должен заниматься, а он будет пророком?

i-rinat ★★★★★ ()
Ответ на: комментарий от ranka-lee

использовать тупой массив и тупой брутфорс вместо умной структуры.

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

i-rinat ★★★★★ ()
Ответ на: комментарий от ranka-lee

Какую идею?

Идею использовать юниты на GPU как группу процессоров общего назначения с целью выполнять на них ту работу, для которой обычно используется CPU.

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

Этим знающие люди и занимаются. Но кроме них - никто, продолжают пытать бедный несчастный CPU и делают вид что так надо.

ranka-lee ()
Ответ на: комментарий от ranka-lee

Этим знающие люди и занимаются. Но кроме них - никто, продолжают пытать бедный несчастный CPU и делают вид что так надо.

Ощущение, будто получил пощёчину, но не понимаешь за что. Некоторый чел высказывает идею о том, что он знающий как всё разрулить Д'Артаньян, а все остальные дураки. Но его идея настолько абстрактна, что только абстрактные знающие люди ею могут заниматься и, вероятно, занимаются. Зачем это нам? Что мы можем сделать?

Разговор ни о чём; какое-то перекидывание понтами.

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

Некоторый чел высказывает идею о том, что он знающий как всё разрулить Д'Артаньян, а все остальные дураки.

Это вы что то нафантазировали.

Но его идея настолько абстрактна

Более чем конкретна. И если вы играете в видеоигры на PS3/PS4 - то вы уже видели это всё в действии.

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