Войти
Мобильные платформыНовостиОбщееОбщее

OpenGL ES 3.0 официально представлен

Автор:

Khronos Group сегодня официально представила спецификацию OpenGL ES 3.0, которая базируется на OpenGL 3.3 и OpenGL 4.2. Краткий список нововведений:
- occlusion queries, transform feedback, instanced rendering и поддержка 4-х и более rendering targets;
- высококачественная ETC2 / EAC компрессия текстур, как стандартная фича;
- новая версия GLSL ES языка шейдеров с полной поддержкой операций над целыми числами и 32-битными числами с плавающей запятой;
- гарантированная поддержка floating point текстур, 3D текстур, текстур глубины, текстур вершин, NPOT текстур, R/RG текстур и других;
- обратная совместимость в OpenGL ES 2.0.

Более детальную информацию можно найти в официальном пресс-релизе:
http://www.khronos.org/news/press/khronos-releases-opengl-es-3.0-specification

#OpenGL, #OpenGL ES 3.0

7 августа 2012

Комментарии [46]

Страницы: 1 2 3 4 Следующая »
#1

>Besides having access to vertex attributes and uniform variables, vertex shaders can access the read-only built-in variables gl_VertexID and gl_InstanceID.
крутота, можно демосцены делать !

>SampleCoverage
у нас есть ретина, нафиг надо, да и привыкли без AA техник обходится, выезжают же визуальным стилем

>PBO
птчк ты прнс накнцт ?!!! если дрова не будут *бать мозги всякими копированиями (врам и рам всё равно на мобильниках в общем виртуальном пространстве, даже если на разных чипах), то будет збс

>Uniform Buffer Object
покажите мне человека у которого bottleneck в установке юниформов, но как замена говнокода драйвера своим - сойдет

>MapBufferRange
если разрабам драйверов хватит мозгов познать всю глубину флагов - будет аццкий отжиг !

>MRT
хым, DS обещает взлететь ? WELCOME TO BANDWIDTH, B*TCHES, на ипад3 гпу тупо упирается в пропускную способность памяти, хотя в даунскейл 1:4 вроде неплохо

>textureGrad
да вы что ?! Я СМОГУ СДЕЛАТЬ ТАЙЛИНГ СПРАЙТА В АТЛАСЕ В 2012 (2013) ГОДУ ?! ДА ЭТА БЛ*** ЗБС !

ps. в общем движемся в правильном направлении, но слишком уж медленно, sdk ps vita всё равно лучше :) дайте мне возможность генерить командный буфер руками - тогда и поговорим, эплы вот родили программируемый блендинг в ios 6, хотя он во всей линейке powervr был :) чего ждали то они 5 лет ?

7 авг. 2012

#2

OpenGL ES 3.0: приехали ... они уже догнали GL3.0 ?

> дайте мне возможность генерить командный буфер руками - тогда и поговорим

может лучше не руками, а типа DL ?

как ты себе представляешь генерить командный буфер руками для кучи разных железок ?

7 авг. 2012

#3

Интересно, в iOS 6 Beta 4 случаем его уже не встроили? Доберусь до работы - гляну.

7 авг. 2012

#4

Sergio
Ты что, спецификация же позавчерашняя.

7 авг. 2012

#5

Sergio
> Интересно, в iOS 6 Beta 4 случаем его уже не встроили?
Нет, конечно. Думаю, не раньше 7-й версии.

Кирюшык
> спецификация же позавчерашняя.
Это для широкой публики она появилась только вчера. А такие парни как Эпл как раз и пишут эту спеку ;)

7 авг. 2012

#6

innuendo
> может лучше не руками, а типа DL ?
где куча ? их всего три чипа для ios : SGX535, SGX543MP2, SGX543MP4, хотя для андроида надо какой нибудь low-level api, но я вообще не представляю как для андроида можно оптимизировать софт ?! разве что для nexus 7 с тегрой, остальные пускай идут по тормозному "default render path" на огле :) а то mali400, adreno, мне что прикидываться производителем телефонов чтобы получать low-level спеки эти ядра ?

7 авг. 2012

#7

.::jimon::.
> > может лучше не руками, а типа DL ?
> где куча ? их всего три чипа для ios

разве я написал только для iOS ? речь же идёт о GLES3.0 в целом

очень хочется услышать, как будет выглядеть работа с коммандным буфером на целой куче железок ?

> sdk ps vita всё равно лучше

замечательно, когда есть одна железка и под неё кодят, а как быть, когда не одна ?

7 авг. 2012

#8

innuendo
> разве я написал только для iOS ? речь же идёт о GLES3.0 в целом
> очень хочется услышать, как будет выглядеть работа с коммандным буфером на

тебе шашечки или ехать ? интересных для бизнеса применений OpenGL ES всего два : iOS и Android (остальные или не интересные в плане денег или слишком сырые), под iOS всего три чипа, два из которых очень похожи, вполне можно осилить, только вот непонятно как разрабатывать под андроид эффективно, если на пк рынке всего два (уже три) больших производителей видеокарт, то под андроид SoC'и лепят кто хочет, они все разные, совсем разные, и как тут получать максимальную производительность ? имхо ни один стандарт не может дать api дающий производительность без узких мест без зависимости от контекста и без зависимости от железа

ps. в теории можно долго обсуждать что лучше, но в реальности же всё по другому :)

7 авг. 2012

#9

.::jimon::.
> тебе шашечки или ехать ?

какие претензии к GLES ? что не подстраивается под iOS и Android ? :) DX не стало попахивать ?

> имхо ни один стандарт не может дать api дающий производительность без узких
> мест без зависимости от контекста и без зависимости от железа

никто не спорит :)

ты опиши, конкретно, что и как хотел бы видеть ?

7 авг. 2012

#10

innuendo
я бы хотел видеть гарантии :) а то api дело такое, но производитель драйверов любит накосячить, а именно :

1) если я делаю мап то он обязан возвращать указатель на данные in-place, без копирований, без аллокаций, без ничего, указатель обязан быть валидным пока существует объект (это можно делать через механизм виртуальных страниц)

конечно нужны примитивы синхронизации чтобы понимать когда данные понадобятся gpu

2) формирование командного буфера, оно слишком неоднозначное, драйвер iOS делает кучу лишних аллокаций (все думаю видели тысячи вызовов malloc по 4-32 байта при вызове glDraw*), хотелось бы получить адекватный api для этого, ведь количество дипов меняется далеко не каждый кадр, вполне можно было бы зааллочить кусок памяти, и там уже просто включать-выключать команды и просто менять данные in-place

3) неоднозначность того что делает драйвер когда ему дают указатель, к примеру я сделал загрузку текстуры с помощью мапинга файла в память ( http://forum.boolean.name/showthread.php?t=16880 ), почему ЭТО не является решением по умолчанию ? почему народ до сих пор должен выделять временные буфера в оперативной памяти чтобы закинуть в драйвер данные с флешки ?! я уж молчу почему драйверу нельзя скормить указатель из рамы чтобы он по этому указателю данные и брал, всё равно свопа нет то (на iOS)

плюс где гарантии что драйвер не будет делать какую-то обработку данных ? я хочу чтобы он тупо их использовал, как бы O(1) получить хочу

плюс если ему всё же надо копировать что-то куда-то то хотелось бы задавать кешируемое или не кешируемое копирование использовать

4) шейдера, дорогие шейдера, драйвер говори с*ка что ты будешь делать ! вы знаете что на powervr нету конвеера выборки данных ? те если у вас атрибут вертекса имеет тип unsigned short, то код преобразования unsigned short в float добавляется драйвером в код вашего шейдера, а теперь представьте какая каша происходит если у вас много разных типов структур вертекса и много шейдеров ? начинается эпическая каша с неадекватными выделениями памяти и неадекватным временем работы (оно же только в момент glDraw* это может узнать, а там еще кеши какие-то надо делать), где контроль за этим ? можно и дальше притворятся сказочным эльфом, но когда драйвер делает такое под боком то уже страшновато

ну плюс слабая поддержка железа, это уже проблема расширений, я уже говорил что программируемый блендинг добавили только в iOS 6, хотя он еще был в sgx535, чего ждали то ? всё равно драйвер glBlend* делал через патчинг кода шейдера

ps. а больше всего я негодую тем что моя игра выделяет константное количество раз malloc за всё время работы (можно до 1 свести если приспичит), а всякие библиотеки (не только opengl) умудряются вызвать его 100 тыс, а то и больше раз, я просто мечтаю что на инженеров сойдет озарение и они будут поступать как все библиотеки и должны - просить рабочий пул извне, так например fmod делает

7 авг. 2012

#11

.::jimon::.
> без ничего, указатель обязан быть валидным пока существует объект (это можно
> делать через механизм виртуальных страниц)
> конечно нужны примитивы синхронизации чтобы понимать когда данные понадобятся
> gpu

в каких случаях у тебя он невалидный ? BufferSubData не помогает ?

> драйвер iOS делает кучу лишних аллокаций (все думаю видели тысячи вызовов
> malloc по 4-32 байта при вызове glDraw*),

жутко просто становится :)

> формирование командного буфера, оно слишком неоднозначное,

вот тут ,пожалуйста, точнее

7 авг. 2012

#12

innuendo
> BufferSubData не помогает ?
BufferSubData это уже синхронизация, которая флашит весь буфер комманд. Оно только жутко усугубляет ситуацию. Мэппинг является асинхронной операцией, вот потому и нужны примитивы синхронизации

7 авг. 2012

#13

StiX
> BufferSubData это уже синхронизация, которая флашит весь буфер комманд. Оно
> только жутко усугубляет ситуацию

в моём случае BufferSubData улучшил ситуацию , а glUnMap не делает синхронизации ? 

7 авг. 2012

#14

innuendo
> в каких случаях у тебя он невалидный ? BufferSubData не помогает ?
а в каких случаях он валидный по стандарту ? только между map-unmap ? почему стандарт не гарантирует что он будет валидный пока существует объект ? где объекты синхронизации чтобы узнавать когда gpu читает из него

>вот тут ,пожалуйста, точнее
я уже расписал в предыдущем посте, неоднозначно что делает драйвер когда ты делаешь glDraw*

7 авг. 2012

Страницы: 1 2 3 4 Следующая »
Мобильные платформыНовостиОбщееОбщее

Тема в архиве.

Смотрите modmcpe.net майнкрафт на андроид.