В девайсах, где в качестве операционной системы установлен Android, есть мало возможностей для обновления софта графической подсистемы – единственным официальным методом можно назвать только установку свежей версии прошивки.
Также в интернете можно наткнуться на инструкции по обновлению драйверов видеоускорителя на смартфоне или планшете. Назвать этот метод откровенным обманом нельзя – действительно, некоторые устройства (чаще всего с чипсетами Qualcomm) и правда поддерживают такую возможность, но при условии наличия root-доступа и стороннего рекавери. Однако в большинстве случаев под видом драйверов распространяется вредоносное ПО, особенно если предлагается загрузить APK-файл, поэтому будьте бдительны и при малейших сомнениях откажитесь от использования этого метода.
Вариант 2: Эмуляторы Android
Для программ-эмуляторов «зелёного робота» ситуация выглядит иначе. Дело в том, что в приложениях вроде Bluestacks и подобных ему в качестве графического ускорителя виртуального устройства задействуется видеокарта компьютера, где ПО и установлено. Следовательно, уровень используемого эмулятором OpenGL зависит от поддерживаемого GPU. Просмотреть текущий можно посредством специальной утилиты, например, GPU Caps Viewer.
Рассматриваемый софт поставляется в двух вариантах – полный установщик и портативная версия. Для нашей цели достаточно второго, он обозначен ссылкой с «(zip)» в имени.
Воспользуйтесь вкладкой «GPU» – внизу должна находится строка с именем «OpenGL». Указанная в ней версия и будет поддерживаемой данным устройством.
Если этот уровень ниже 4.0, поднять его можно с помощью установки свежей версии драйверов – подробности процедуры для разных типов видеокарт есть в инструкции по ссылке далее.
Помимо этой статьи, на сайте еще 12473 инструкций. Добавьте сайт Lumpics.ru в закладки (CTRL+D) и мы точно еще пригодимся вам.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Источник
Установить opengl для андроида
Для чего эта тема? У многих создалась иллюзия сложности изучения «OpenGL», и не понимания простоты работы этой библиотеки для программиста. И даже используя «движок» нужно понимать как это взаимодействует с ОС, что может/не может конкретные устройства.
В данной статье постараюсь выйти за рамки стандартных примеров — а именно постараюсь рассказать почему и за чем. ( тем более я давно это пообещал ) От читателей требуется хотя бы поверхностное знание любого ЯП.
Все дальнейшее посвящено библиотеке OpenGL ES 2.0 под Android, и последующим версиям.
Что такое библиотека OpenGL ES 2.0? На базовом уровне, OpenGL ES 2.0 — это просто спецификация, то есть документ, описывающий набор функций и их точное поведение. Производители оборудования на основе этой спецификации создают реализации — библиотеки функций, соответствующих набору функций спецификации ( W: ).
OpenGL ориентируется на следующие две задачи: Скрыть сложности адаптации различных 3D-ускорителей, и предоставить разработчику единый API.
Для программиста OpenGL представляет низкоуровневую библиотеку для доступа к GPU ( графическому процессору ).
Схема вариантов реализации библиотеки ( с точки зрения программиста + для сравнения DirectX ):
В Android на 99.99% используется вариант В. То есть реализация OpenGL ES входит в состав драйвера, в отличие от DirectX, которая скорее является прослойкой между приложением и драйвером. Есть еще отдельные реализации OpenGL, например Mesa3D, но они в основном достаточно медленно развиваются и часто отстают на несколько поколений от решений производителей чипов.
Что лучше, DirectX или OpenGL? Вопрос не корректный. Например если нужна мультиплатформенность — про DirectX можно забыть. И на взгляд автора DirectX слишком «оброс» хвостами. ( но это очень субъективно ) + Сравнивать не совсем корректно, так как DirectX кроме графики реализует много интерфейсов ( и вполне кошерных — включая звук, ввод, сеть и т. д. ) Что быстрее, DirectX или OpenGL? Тоже не корректный вопрос, все зависит от опытности программиста. Но опять на взгляд автора ( меня =) ) нестандартные возможности проще реализовывать на современных версиях OpenGL и тем более для этого не требуются переходы на новые операционные системы ( в отличие от DirectX 10 ). Времени на изучение тоже требуется на порядок меньше. + переносимость.
Теперь чуть-чуть про GPU: В данный момент ( декабрь 2012г. ) в Android устройствах присутствуют два поколения GPU, Поддерживающие OpenGL ES 2.0 ( почти 95% ) и поддерживающие только версии 1.0 и 1.1. Аппаратной обратной совместимости НЕТ. Поэтому рассматривать версию стандарта меньше 2.0 на взгляд автора кроме как археологам не имеет смысла. ( стандарт версии 3.0 обратно совместим с 2.0 )
Структура конвейера OpenGL 1.x:
Структура конвейера OpenGL 2.x+:
То есть часть блоков с «железной логикой» заменили на программируемые процессоры. Вопрос: а для чего? А все дело в том что аппаратно было реализовано достаточно мало функций, из-за этого создавались существенные ограничения в дальнейшем развитии и гибкость была равна нулю. История ( немного ): Первые попытки перенести расчеты с Cpu ( центрального процессора ) были реализованы в первом Geforce ( а не в Voodoo, как думают многие ), называлать технология T&L. Она позволяла аппаратно просчитывать на GPU освещение и выполнять уже простейшие шейдеры. Получилось «быстро», но не осталось даже минимальной гибкости. Есть аппаратно-реализованный метод освещения например,используем. Нет — и не будет. Следующая веха — GeForce 3, который обладал уже вполне программируемой логикой, но процессорные блоки еще небыли универсальными. То есть блоки делились на обрабатывающие вершины и фрагментные ( обрабатывающие пиксели ). Одни могли быть перегружены, другие простаивали. В чем смысл наращивания процессоров ( вычислительных блоков ) у GPU? Все дело в том что графические просчеты почти линейно маштабируется, то есть увеличение процессоров например со 100 до 200 дает почти 100% прирост производительности, так как в компьютерной графике текущий расчет обычно не зависит от предыдущего — то есть легко запаралелить. Но и существуют некоторые ограничения, о которых будет написано ниже. Теперь про сам OpenGL ES:
Что может OpenGL ES? Основным принципом работы OpenGL является получение наборов векторных графических примитивов в виде точек, линий и многоугольников с последующей математической обработкой полученных данных и построением растровой картинки на экране и/или в памяти. Векторные трансформации и растеризация выполняются графическим конвейером (graphics pipeline), который по сути представляет собой дискретный автомат. Абсолютное большинство команд OpenGL попадают в одну из двух групп: либо они добавляют графические примитивы на вход в конвейер, либо конфигурируют конвейер на различное исполнение трансформаций. Ключевая особенность — CPU и GPU работают не синхронно, то есть CPU не дожидается окончания исполнения команд от GPU, а продолжает работать ( если не было дополнительных указаний ). Есть стек команд ( инструкций ) OpenGL. ( стек бывает двух типов, fifo и lifo. FIFO — акроним «First In, First Out» (англ. ). Принцип «первым пришёл — первым ушёл», LIFO — акроним «Last In, First Out» (англ.), обозначающий принцип «последним пришёл — первым ушёл». В OpenGL используется fifo ( очередь )).
Урок первый END.
Представьте себе конвейер производства дед.мороза =)
С одной стороны вы забрасываете заготовки, с другой стороны выходит готовая продукция. Но вы стоите за пультом, у которого есть несколько рычагов — и в зависимости от переключения Вами этих рычагов выходят танки, куклы, хлопушки. Но никогда не может появиться на свет куклахлопушка, то есть в данный момент времени возможен только один вид продукции. Линия находится всегда только в одном состоянии, и может в данный момент времени выпускать только определенную продукцию.
Это и есть машина конечных состояний. Проще объяснить не могу. Кто не понял — тут
Продолжение как чуть высплюсь. ( следующая тема — что скрывается за GLSurfaceView, чем это плохо и что такое EGL. ) OpenGL 2.0+ под Android (Пост Leopotam #18544726)
Все статьи в PDF, благодаря who-e, oges2.zip ( 2.76 МБ ) . Надеюсь будет полезно. Спасибо who-e.
В теме нет куратора. Если в теме есть пользователь, желающий стать Куратором и соответствующий Требованиям для кандидатов, он может подать заявку в теме Хочу стать куратором (предварительно изучив шапку темы и все материалы для кураторов). До назначения куратора, по вопросам наполнения шапки, обращайтесь к модераторам раздела через кнопку под сообщениями, на которые необходимо добавить ссылки.
Сообщение отредактировал vaalf — 23.11.17, 12:12
Неплохо было бы еще на пальцах объяснить, что такое конечный автомат (более правильное название, а не дискретный) и что нужно сохранять / восстанавливать изменения состояния автомата, т.к. он един для всего приложения и смена флагов в одном месте может повлечь забавные глюки в другом.
Сообщение отредактировал Leopotam — 10.01.13, 22:58
Теперь пример простейшей инициализации OpenGL ES 2.0 под Android ( из премеров Google, абсолютно корявый и не применимый в реальной жизни =) ):
В приложении, методе OnCreate:
requestWindowFeature(Window.FEATURE_NO_TITLE); // Убираем заголовок getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); // Устанавливаем полноэкранный режим
// Далее устанавливаем версию OpenGL ES, равную 2 glSurfaceView.setEGLContextClientVersion(2);
renderer = new nRender();
glSurfaceView.setRenderer(renderer); // устанавливаем нашу реализацию GLSurfaceView.Renderer для обработки событий
glSurfaceView.setRenderMode(GLSurfaceView.RENDERMODE_CONTINUOUSLY); // режим смены кадров // RENDERMODE_CONTINUOUSLY — автоматическая смена кадров, // RENDERMODE_WHEN_DIRTY — по требованию ( glSurfaceView.requestRender(); )
>catch(RuntimeException e)<> // выводим окошко «увы, выше устройство слишком. «
public class nRender implements GLSurfaceView.Renderer < public nRender() < >
public void onDrawFrame(GL10 glUnused) < // Отрисовка кадра
Random rnd = new Random();
// Задаем случайный цвет и сводим с ума эпилептиков =) // Цвет задается в формате RGBA, от 0.0f до 1.0f. GLES20.glClearColor(((float)rnd.nextInt(2)/2.0f), ((float)rnd.nextInt(2)/2.0f), ((float)rnd.nextInt(2)/2.0f), 1.0f);
GLES20.glClear( GLES20.GL_COLOR_BUFFER_BIT ); // Очищаем буффер цвета >
public void onSurfaceChanged(GL10 glUnused, int width, int height) < // изменение поверхности, например изменение размера
GLES20.glViewport(0, 0, width, height); // Устанавливаем положение и размер вьюпорта // вьюпорт устанавливаеться относительно поверхности ( OpenGLSurface ), в данном случае на весь экран. // замечу, что GLES20.glClear очищает всю поверхность, все зависимости от установки Viewport. >
public void onSurfaceCreated(GL10 glUnused, EGLConfig config) < // вызываеться при создании поверхности
Далее пробуем запустить, и получаем мечту эпилептика.
Данный пример каноничен ( по документации ), но убог и уродлив по всем проявлениям.
Сообщение отредактировал usnavii — 17.01.13, 11:55
OpenGL по своему принципу является конечным автоматом.
Представьте себе конвейер производства дед.мороза =)
С одной стороны вы забрасываете заготовки, с другой стороны выходит готовая продукция. Но вы стоите за пультом, у которого есть несколько рычагов — и в зависимости от переключения Вами этих рычагов выходят танки, куклы, хлопушки. Но никогда не может появиться на свет куклахлопушка, то есть в данный момент времени возможен только один вид продукции. Линия находится всегда только в одном состоянии, и может в данный момент времени выпускать только определенную продукцию.
Это и есть машина конечных состояний. Проще объяснить не могу. Кто не понял — тут
Продолжение как чуть высплюсь. ( следующая тема — что скрывается за GLSurfaceView, чем это плохо и что такое EGL. )
Сообщение отредактировал usnavii — 10.01.13, 23:26
Конечный автомат — это система, содержащая в себе несколько состояний, причем можно четко определить, в каком из них она находится. Это если по-умному и непонятному. Если ближе к отображению графики, например, выводу модели Деда Мороза на экран: *) существует единая лента-конвейер по выводу изображения на экран, на вход которого подаются модели Деда Мороза, а на выходе получаем 2d картинку, готовую для отображения на мониторе. Конвейер выполняет обработку данных последовательно, без пропусков. Модели представляют собой набор вершин и треугольные грани (см. P.S.1), связывающие 3 соседние вершины. *) У главного пульта конвейера есть всего, допустим, 5 тумблеров-переключателей (P.S.2), каждый из которых может находиться в состоянии вкл / выкл (см P.S.3): -) тумблер «отрисовывать сглаженно или с острыми кромками». -) тумблер «отрисовывать с текстурой или просто сплошным цветом». Под этим тумблером есть фото-рамка для вставки желаемой текстуры. -) тумблер «отрисовывать все грани или только лицевые» (например, для прозрачных объектов). -) тумблер «очищать только буфер глубины или буфер глубины и буфер цвета (изображения)». -) еще какой-то, с красной кнопкой. *) Стартовые значения переключателей на пульте устанавливаются в момент инициализации OpenGL и сохраняются в специальной области, называемой контекстом. Да, OpenGL может в одном приложении выводить изображение в 2 окна, каждый из которых будет иметь свой независимый контекст и свой независимый конвейер. *) Конвейер работает все время существования окна приложения, используя для отрисовки Дедов Морозов текущие настройки на пульте. Нет необходимости перед каждой отрисовкой повторно устанавливать выключатели в старое положение. *) Эльфы, сидящие внутри блока обработки входящей информации через конвейер, не сразу выдают результат на экран, а только после выполнения нужных операций по растеризации-отрисовке внутри себя, распараллеливая между собой. Чем совершеннее графический процессор, тем больше эльфов, способных работать параллельно для отрисовки точек, сидит внутри. При этом конвейер приостанавливается до обработки всей модели. Если данных будет очень много, то эльфы, сидящие внутри, не будут успевать перерабатывать такой объем и блокировка конвейера вызовет простой уже центрального процессора, ожидающего, когда конвейер освободится — отсюда мы видим падение fps-ов при большом потоке информации (перекрывающем филлрейт конвейера) и слабом графическом процессоре.
Пример. Конвейер запущен, Деды Морозы поехали по ленте. И через 5 штук мы вспоминаем, что нам не нужны гламурно-сглаженные, но только рубленные топором, только хардкорные модели на выходе. Подходим к пульту и перещелкиваем первый тумблер (см. выше). Все, все последующие модели будут отрисовываться, словно резчик по дереву был пьян и забыл про шлифовку и прочие доработки. Нам ничего не нужно перещелкивать на пульте перед каждой последующей моделью. Прибежала Снегурочка, наблюдающая все это непотребство на экране и сказала, что неплохо бы раскрасить Деда Мороза, потому что гламурное розовое нечто с неаккуратными краями смотрится на экране неканонично, хотя ей нравится. Берем у нее фотографию-картинку настоящего Деда Мороза, подсовываем в рамку под тумблером текстурирования и перещелкиваем его. Все, все последующие Деды Морозы будут выглядеть с наложенной картинкой-текстурой и с несглаженными гранями. Нам ничего не нужно перещелкивать на пульте перед каждой последующей моделью. Снегурочка пришла еще через 10 моделей, уже немного нетрезвая, и заявила, что пусть лучше Дед Мороз будет гламурно ровненьким, но должен иметь сходство с фотографией. ок, перещелкиваем тумблер сглаживания и идем дальше праздновать НГ. На выходе получим текстурированного и сглаженного Деда Мороза для всех последующих моделей. Нам ничего не нужно перещелкивать на пульте перед каждой последующей моделью.
P.S.1. На самом деле OpenGL поддерживает не только треугольные грани, но для унификации всего процесса лучше использовать именно их. P.S.2. Их не 5, а гораздо больше — в этом смысл конечного автомата OpenGL — много настроек, каждая из которых отвечает за что-то свое и за изменением которых нужно внимательно следить, чтобы не получить Злого Санту, например. P.S.3. Состояний может быть больше двух, если настройка подразумевает несколько вариантов значений.
Сообщение отредактировал Leopotam — 11.01.13, 10:36