Войти
ПрограммированиеФорумГрафика

OpenGL 4.x (3 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 583 Следующая »
#30
(Правка: 19:31) 19:30, 11 мар. 2010

Я примерно понял что за семплеры.
Короче, делаешь один семплер с нужной фильтрацией и подставляешь его везде.
Сначала думал что сделают в GLSL, но тогда пришлось бы к каждому семплеру писать все параметры.
Всё-таки один раз это делать удобнее.
По сути удобная вещь, но не необходимая, можно обойтись без неё.
В остальном вообще ничего интерсного... как-то странно... это случай из серии "смотришь в книгу - видишь фигу" :)))


В GLSL 330 вообще ни одного изменения.


#31
(Правка: 19:57) 19:52, 11 мар. 2010

//всё нижесказанное относится к 2.0
Если это играет какую-то роль, то вот моё мнение по поводу текущей огл орхетектуры:

Эти ребята ещё давно решили идти по трудному пути - объектный подход через plain C. Если мы хотим, например, создать текстуру, нам выдают её айдишник(аналог указателя на класс) и далее мы многочисленными методами glSetBlhaBlhaBlha изменяем её свойства - что-то в духе вызова мемберов-сеттеров. Я уж точно не первый фанат такого подхода, на мой взгляд, на C++ это смотрелось бы лучше. С++ горе-ооп хотя бы не позволить скомпилировать перл вроде

glBindTexture(texid, target); //аргументы оба инты, но перепутаны местами
потому что в С++ коде будет что-то в духе
tex->Bind();
Вроде как принято, что в нормальной архитектуре расово неверный код попросту нельзя составить, чего не скажешь, когда у нас вся информация хранится в void* а указатели на всё типа int.

Но если предыдущий пункт я ещё могу понять, это связано с тем, что под какие-то там ущербные платформы когда-то не существовало С++ компиляторов, поэтому всё ваяли на девственно чистом, добром и светлом plain C, то следующий пункт я считаю откровенной ошибкой проектирования.

В GAPI полностью смешались FFP и шейдеры. Вовсе не очевидно, что происходит, когда я, например, говорю, glDisable(GL_TEXTURE_2D) и что-то там делаю с текстурами в шейдере. Не понятно, на что вообще влияют glMaterialfv, если всё равно у меня свой фрагментный шейдер. Как выполняется фрагментный шейдер для полигона со сглаженными мультисемплингом рёбрами?

Разумеется, ответы на эти вопросы где-то документированы, тот, кто занимается этим профессионально, должен знать на них ответы, просто меня, как человека, кому ОГЛ нужен просто в прикладных целях, напрягает то, что из-за обратной совместимости у них уже такой ком конфликтов старых и новых технологий намотался, что, блин, мама не горюй.

#32
19:56, 11 мар. 2010

Suslik,
FFP уже давно нет в гл

#33
19:57, 11 мар. 2010

я не в курсе, извините. всё растекание мыслью по древу относилось исключительно к 2.0.

#34
(Правка: 20:22) 20:20, 11 мар. 2010

Suslik
С первым согласен тоже, по идее это ожидалось от OpenGL 4.0.
А второе уже не актуально.

З.Ы. Почитал спек GLSL 400. Это действительно интересно.
По сути в OpenGL 4 это самое главное - новый спек языка шейдеров.
Добавили всё что ожидалось:
- два шейдера для тесселляции
- чудесные функции EmitStreamVertex (int stream) и EndStreamPrimitive (int stream)
- установка семплов
- новые математические функции (FMA и прочее) и функции для целых чисел
- гейзер и текстурный лод
- даблы
- функции интерполяции

Не хватает задания стенсила и OIT-буфера.

#35
(Правка: 20:58) 20:49, 11 мар. 2010

SNVampyre
> Почему не сделать класс?
Не нужны нам никакие классы. Классами делайте обертки и называйте их как хотите. Тысячи их.

#36
21:16, 11 мар. 2010

entryway
> Не нужны нам никакие классы. Классами делайте обертки и называйте их как
> хотите. Тысячи их.
нам нужны шаблоны?)

    template<GLenum TARGET> struct tvbo
    {
      typedef tvbo<TARGET> TYPE;
      static const GLenum Target = TARGET;
      inline static void bind ( SBuffer &buffer );
      inline static void unbind ( );
      inline static void data ( GLsizeiptrARB size, const void * data, GLenum usage );
      inline static void clear ( );
      inline static void setSubData ( GLintptrARB offs, GLsizeiptrARB size, const void * data );
      inline static void getSubData ( GLintptrARB offs, GLsizeiptrARB size, void * data );
      inline static void * map ( GLenum access );
      inline static GLboolean unmap ( );
    };

    typedef tvbo<GL_ARRAY_BUFFER_ARB> ArrayBuffer;
    typedef tvbo<GL_ELEMENT_ARRAY_BUFFER_ARB> ElementsArrayBuffer;
    typedef tvbo<GL_PIXEL_PACK_BUFFER_EXT> PixelPackBuffer;
    typedef tvbo<GL_PIXEL_UNPACK_BUFFER_EXT> PixelUnPackBuffer;
    typedef tvbo<GL_TEXTURE_BUFFER_EXT> TextureBuffer;
    typedef tvbo<GL_UNIFORM_BUFFER_EXT> UniformBuffer;

нужны проверки на момент компилирования типов и констант.

#37
21:26, 11 мар. 2010

GL 4.0 подкрался незаметно....
Неожиданно то как.

жалко что на OpenGL я забил еще со второй версии...

#38
21:26, 11 мар. 2010
Not Found

The requested URL /documentation/specs/doc/glspec40.core.20100311.pdf was not found on this server.

что за на....

#39
21:27, 11 мар. 2010

И ещё. Я сейчас, наверно, сморожу глупость, но всё-таки. Давно интересует этот вопрос:

Вот раньше видеокарта умела только растеризовать треугольники по одному заложенному в неё алгоритму. Потом она стала уметь их не просто растеризовать, а с выкрутасами, добавили вершинный и фрагментный шейдеры. Потом поняли, что это не всё, что умеют видеокарты и добавили геометрические шейдеры. Тесселяционные вот теперь ещё. Внимание, вопрос:
Что мешает просто предоставить API для работы с видеокартой напрямую (а-ля GPGPU) и уже используя этот апи реализовать все стандартные алгоритмы вроде растризации треугольников и парсинг шейдеров? Тогда вместо новых спецификаций OGL можно будет просто обновлять этот самый пакет. Преимущества налицо: если программист считает, что он хочет, чтобы видеокарта что-то делала по-другому, он берёт и переписывает этот момент в пайплайне. Если он считает, что он вообще умнее всех, он не использует пайплайн вовсе и просто загружает видеокарту так, как считает нужным. В чём проблемы подхода? Оверхед? Слишком жирно?

#40
21:27, 11 мар. 2010
[шутка]Бросайте ОГЛ, переходите на ДХ[/шутка]
В который раз сожалею, что выбрал ДХ, а не ОГЛ :(
#41
21:44, 11 мар. 2010

Suslik
То что ты хочешь называется CPU.

#42
21:46, 11 мар. 2010

Suslik
> Что мешает просто предоставить API для работы с видеокартой напрямую (а-ля GPGPU)
Предполагаю, что GPU еще не совсем GP

#43
21:53, 11 мар. 2010

eagle
> То что ты хочешь называется CPU.
то, что я хочу называется GPGPU. никто не говорит, что видеокарта должна уметь эффективно поддерживать весь набор инструкций, подобных IA32. достаточно предоставить её нативную функциональность, уверен, желающие реализовать существующие функции видеокарты программно найдутся.

*vmr
> Предполагаю, что GPU еще не совсем GP
Более конкретные предположения? Насколько я знаю CUDA, ничто принципиально не мешает на ней достаточно эффективно реализовать аналог FFP. Вопрос в том, какой это может дать оверхед? Теоретически, конечно, нулевой, но это в идеале.

#44
22:05, 11 мар. 2010

SNVampyre
> Почему не сделать класс?

Какой ещё класс? О_О

Страницы: 1 2 3 4 583 Следующая »
ПрограммированиеФорумГрафика