Комментарии 25
Можно вопрос оффтопом:
А какие бы посоветовали туториалы по последнему OpenGL?
А то немного писал на старых версиях, и мне кажется, что во многом я использую очень старый функционал.
А какие бы посоветовали туториалы по последнему OpenGL?
А то немного писал на старых версиях, и мне кажется, что во многом я использую очень старый функционал.
ogldev.atspace.co.uk
learnopengl.com
Вот эти ресурсы дают неплохую базу, так же на habr есть перевод части уроков learnopengl
А касательно современных штук: документация от NVidia и англоязычные статьи.
Я постараюсь выпустить ряд статей по новым фичам и техникам (в меру своих знаний и найденного материала)
learnopengl.com
Вот эти ресурсы дают неплохую базу, так же на habr есть перевод части уроков learnopengl
А касательно современных штук: документация от NVidia и англоязычные статьи.
Я постараюсь выпустить ряд статей по новым фичам и техникам (в меру своих знаний и найденного материала)
Уточню, по поводу переводов learnopengl.com. Переведены все же все уроки из основной, технической секции. Секция, посвященная сборке своего арканоида не переведена, это да.
Спрошу здесь, т.к. этот ресурс указали.
Ни у кого нет проблем с доступом к learnopengl.com? У меня без дополнительных движений данный сайт не открывается (Firefox, Ubuntu, Ростелеком). Приходится или в кеш гугла заглядывать или еще чего. У кого-нибудь открывается этот туториал нормально?
Ни у кого нет проблем с доступом к learnopengl.com? У меня без дополнительных движений данный сайт не открывается (Firefox, Ubuntu, Ростелеком). Приходится или в кеш гугла заглядывать или еще чего. У кого-нибудь открывается этот туториал нормально?
Аналогично, ростелеком, открывается только через proxy или vpn.
Похоже, это опять их DPI-решение чудит и рубит не понравившийся https
P.S.: Создал обращение, посмотрим, что ответят.
Похоже, это опять их DPI-решение чудит и рубит не понравившийся https
P.S.: Создал обращение, посмотрим, что ответят.
Заголовок спойлера
Так он просто забанен РКН по IP.
[10:47:44]$ ping learnopengl.com
PING learnopengl.com (128.199.49.46) 56(84) bytes of data.
64 bytes from 128.199.49.46 (128.199.49.46): icmp_seq=1 ttl=59 time=80.1 ms
64 bytes from 128.199.49.46 (128.199.49.46): icmp_seq=2 ttl=59 time=78.8 ms
^C
— learnopengl.com ping statistics — 2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 78.873/79.513/80.154/0.699 ms
Не открывается.
НЛО прилетело и опубликовало эту надпись здесь
Ребят, если у кого-то есть желание помочь с форматированием и правками в следующих статьях, очень прошу — напишите :)
Больной вопрос (надеюсь, не сильно оффтоп) — есть ли хорошие туториалы по Vulkan, где не требуется предварительное знание OpenGL, чтобы не учить первый полностью в придачу? В идеале, с Vulkan-hpp (даже для него доков мало несколько).
А то что не открою — "возьмите программиста с опытом работы с OpenGL".
vulkan-tutorial.com но они на англ, я могу написать авторам и если людям будет интересно — перевести.
Касательно OpenGL — он дает базу, понимание как происходит создание камеры, что такое матрицы Model/View/Projection, но это все можно выучить и на DirectX, и на Vulkan. Материала касательно OpenGL намного больше из-за чего и понять/вычить будет быстрее. По вулкану материалов очень мало, нужно сидеть и смотреть какие проекты есть в открытом доступе, изучать код движка и тд.
Надеюсь понятно обьяснил :)
Касательно OpenGL — он дает базу, понимание как происходит создание камеры, что такое матрицы Model/View/Projection, но это все можно выучить и на DirectX, и на Vulkan. Материала касательно OpenGL намного больше из-за чего и понять/вычить будет быстрее. По вулкану материалов очень мало, нужно сидеть и смотреть какие проекты есть в открытом доступе, изучать код движка и тд.
Надеюсь понятно обьяснил :)
Перевод был, но сайт закрылся внезапно. Кстати, довольно хороший: web.archive.org/web/20180103131302/http://vulkanapi.ru/
Скажем так — Vulkan сам по себе не требует предварительных знаний OpenGL или DirectX, но с практикой в одном из них, можно серьезно улучшить воспринимаемость изучаемых по этой тематике материалов. Как по мне, идеальным подходом к изучению Vulkan без большого опыта с OpenGL и DirectX будет пробег по знаменитому в кругах туториалу vulkan-tutorial.com с написанием кодовой базы вручную(крайне желательно). Кода для вывода примитива с текстурированием получится много, усидчивость приветствуется. После этого скачать/купить книгу Vulkan Programming Guide: The Official Guide to Learning Vulkan. В ней детально описывается сам API, но нет никакой практики, её как раз можно будет взять из кода туториала выше. И вот так, глава за главой, поглядывая в исходный код будет проходить изучение. Vulkan — очень сложный, но он логичный. Поэтому хорошо бы было вести mind-map изученного материала, иначе быстро будете терять ощущение прогресса и могут вовсе руки опуститься. В обилии структур и привязок вулкан превзойдет возможно всё, что вы могли до этого видеть, в этом будет сложно разобраться. Пожелаю удачи!
В своё время пытался его освоить по https://vulkan-tutorial.com, но загнулся из-за попыток одновременно понять vulkan-hpp.
Благодарю за совет сначала пробовать писать код, а лишь потом смотреть примеры.
Автор, нормально пишешь. Про оптимизацию тоже смело пиши.
НЛО прилетело и опубликовало эту надпись здесь
Как теперь более правильно стримить текстуры, например для показа видео? Проверки, это хорошо, но иногда нужна и скорость… Кстати, заметил такую разницу между NV и AMD — у AMD крайне медленно работает glTexImage2D в цикле, даже если надо просто обновить уже имеющиеся данные текстуры без изменения размера и типа пикселей, там как будто текстура полностью и честно пересоздается каждый раз с очисткой и перевыделением памяти и решается это только через glTexSubImage2D, но есть моменты когда нужен именно glTexImage2D (вдруг прилетит кадр не такой как предыдущий). На карточках NV видимо имеется некий спидхак и наличие glTexImage2D с теми же самыми параметрами с которыми была вызвана в первый раз для этой же текстуры вообще никак не влияет на производительность.
Это логично, так как при вызове glTexImage2D мы пересоздаем текстуру, у NVidia скорее всего стоит оптимизация какая-то (он возможно не подчищает и не перевыделяет память, так как создаете с теме же параметрами). В данном случае, вы создаете так называемые mutable texture.
Я немного не понял, про «не такой как предидущий» кадр…
А для ускорения используется PBO он убирает одно копирование данных. И запись из PBO идет через DMA.
www.songho.ca/opengl/gl_pbo.html#unpack — тут хороший пример
Я немного не понял, про «не такой как предидущий» кадр…
А для ускорения используется PBO он убирает одно копирование данных. И запись из PBO идет через DMA.
www.songho.ca/opengl/gl_pbo.html#unpack — тут хороший пример
По поводу «не такой как предыдущий» — имелось ввиду, что когда прилетают кадры видео ролика/карты захвата/веб-камеры и пр. их обрабатывает единственная функция у меня, которая и использует glTexImage2D, которая в свою очередь снимает кучу проблем с выяснением «а какой по размеру был предыдущий кадр (смена видеоролика например), какой формат пикселей был у предыдущего кадра, надо ли пересоздать формат/размер текстуры через glTexImage2D с нулевым пойнтером. К тому же у меня абсолютно всеядный плеер по yuv форматам, коих просто куча, опять же благодаря простоте использования glTexImage2D. Использую ffmpeg разумеется и получаю непосредственно распакованный кадр в yuv формате любом (конвертирование шейдером). Пробовал использовать glTexSubImage2D, но это надо сохранять данные каждого полученного кадра и каждый последующий сравнивать с предыдущим по формату/размеру и т.д., чтобы в случае чего пересоздать текстуру через glTexImage2D с нулевым пойнтером.
По поводу PBO — видел, пробовал. В моем случае ускоряет ровно в 2 раза при загрузке кадра 8k (7680x4320), но все упирается в софтовое копирование данных в маппированную память GPU.
По ссылке — это void updatePixels(GLubyte* dst, int size), т.е. мне все равно надо вручную копировать полученный из ffmpeg кадр куда-то, а в моем случае еще и до 3х раз при наличии 3х битовых полей у yuv кадра. В итоге разница с простецким glTexImage2D даже хоть и 2 раза, но 8k 60fps не тянет ни то ни это… максимум 30.
зы тестировалось на gtx1080 и Vega64
По поводу PBO — видел, пробовал. В моем случае ускоряет ровно в 2 раза при загрузке кадра 8k (7680x4320), но все упирается в софтовое копирование данных в маппированную память GPU.
По ссылке — это void updatePixels(GLubyte* dst, int size), т.е. мне все равно надо вручную копировать полученный из ffmpeg кадр куда-то, а в моем случае еще и до 3х раз при наличии 3х битовых полей у yuv кадра. В итоге разница с простецким glTexImage2D даже хоть и 2 раза, но 8k 60fps не тянет ни то ни это… максимум 30.
зы тестировалось на gtx1080 и Vega64
Я постараюсь поискать ответ, но не обещаю, что смогу помочь
Вообще сейчас вот немного побаловался с PBO и таки удалось догнать сэмулированный через bmp по объему данных кадр якобы 8k yuv420p (7680х1620х32bit) до 110 к/c стиминг+отрисовка… Немного помогло кастомное SSE копирование ещё. Это 9мс уже с отрисовкой, ну 1-2 еще на преобразования, вроде как укладываемся в 16мс. Надо будет покопать в эту сторону…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Суперсовременный OpenGL. Часть 1