OpenGL EXT: shader_buffer_load

http://www.opengl.org/registry/specs/NV/shader_buffer_load.txt

Overview

    At a very coarse level, GL has evolved in a way that allows
    applications to replace many of the original state machine variables
    with blocks of user-defined data. For example, the current vertex
    state has been augmented by vertex buffer objects, fixed-function
    shading state and parameters have been replaced by shaders/programs
    and constant buffers, etc.. Applications switch between coarse sets
    of state by binding objects to the context or to other container
    objects (e.g. vertex array objects) instead of manipulating state
    variables of the context. In terms of the number of GL commands
    required to draw an object, modern applications are orders of
    magnitude more efficient than legacy applications, but this explosion
    of objects bound to other objects has led to a new bottleneck -
    pointer chasing and CPU L2 cache misses in the driver, and general
    L2 cache pollution.

    This extension provides a mechanism to read from a flat, 64-bit GPU
    address space from programs/shaders, to query GPU addresses of buffer
    objects at the API level, and to bind buffer objects to the context in
    such a way that they can be accessed via their GPU addresses in any
    shader stage. 

    The intent is that applications can avoid re-binding buffer objects
    or updating constants between each Draw call and instead simply use
    a VertexAttrib (or TexCoord, or InstanceID, or...) to "point" to the
    new object‘s state. In this way, one of the cheapest "state" updates
    (from the CPU‘s point of view) can be used to effect a significant
    state change in the shader similarly to how a pointer change may on
    the CPU. At the same time, this relieves the limits on how many
    buffer objects can be accessed at once by shaders, and allows these
    buffer object accesses to be exposed as C-style pointer dereferences
    in the shading language.

    As a very simple example, imagine packing a group of similar objects‘
    constants into a single buffer object and pointing your program
    at object <i> by setting "glVertexAttribI1iEXT(attrLoc, i);"
    and using a shader as such:

        struct MyObjectType {
            mat4x4 modelView;
            vec4 materialPropertyX;
            // etc.
        };
        uniform MyObjectType *allObjects;
        in int objectID; // bound to attrLoc

        ...

        mat4x4 thisObjectsMatrix = allObjects[objectID].modelView;
        // do transform, shading, etc.

    This is beneficial in much the same way that texture arrays allow
    choosing between similar, but independent, texture maps with a single
    coordinate identifying which slice of the texture to use. It also
    resembles instancing, where a lightweight change (incrementing the
    instance ID) can be used to generate a different and interesting
    result, but with additional flexibility over instancing because the
    values are app-controlled and not a single incrementing counter.

    Dependent pointer fetches are allowed, so more complex scene graph
    structures can be built into buffer objects providing significant new
    flexibility in the use of shaders. Another simple example, showing
    something you can‘t do with existing functionality, is to do dependent
    fetches into many buffer objects:

        GenBuffers(N, dataBuffers);
        GenBuffers(1, &pointerBuffer);

        GLuint64EXT gpuAddrs[N];
        for (i = 0; i < N; ++i) {
            BindBuffer(target, dataBuffers[i]);
            BufferData(target, size[i], myData[i], STATIC_DRAW);

            // get the address of this buffer and make it resident.
            GetBufferParameterui64vNV(target, BUFFER_GPU_ADDRESS,
                                      gpuaddrs[i]);
            MakeBufferResidentNV(target, READ_ONLY);
        }

        GLuint64EXT pointerBufferAddr;
        BindBuffer(target, pointerBuffer);
        BufferData(target, sizeof(GLuint64EXT)*N, gpuAddrs, STATIC_DRAW);
        GetBufferParameterui64vNV(target, BUFFER_GPU_ADDRESS,
                                  &pointerBufferAddr);
        MakeBufferResidentNV(target, READ_ONLY);

        // now in the shader, we can use a double indirection
        vec4 **ptrToBuffers = pointerBufferAddr;
        vec4 *ptrToBufferI = ptrToBuffers[i];

    This allows simultaneous access to more buffers than
    EXT_bindable_uniform (MAX_VERTEX_BINDABLE_UNIFORMS, etc.) and each
    can be larger than MAX_BINDABLE_UNIFORM_SIZE.

OpenGL EXT: shader_buffer_load

时间: 2024-12-04 10:28:29

OpenGL EXT: shader_buffer_load的相关文章

three.js 相关概念

1.什么是three.js? Three.js 是一个 3D JavaScript 库.Three.js 封装了底层的图形接口,使得程序员能够在无需掌握繁冗的图形学知识的情况下,也能用简单的代码实现三维场景的渲染. 2.渲染器(renderer) 渲染器(Renderer):渲染器是3D引擎的核心部分,它完成将3D物体绘制到屏幕上的任务.渲染器分为硬件渲染器和软件渲染器组成. a).软件渲染器通常基于底层图形API(应用程序接口)构建,采用适合硬件架构的光栅化方法进行渲染.图形API负责与硬件的

和馅饼一起学opengl 第一篇——总概

写在前面 这个系列是关于OpenGL(以下称OGL)的一些入门学习,虽然旨在入门,但是我却不想把它写得过于简单(当然是相对的,会者不难),首先这系列要肯定的一点是一定会有编码,有实例来帮助大家一起学习,但是套用一句侯捷先生说过的话,勿在浮沙筑高台,所以我会说一些晦涩的关于OGL的理论知识,如其RC的概念,状态机等等,旨在深入浅出OGL,同时,我也在学习中,所以错误在所难免,请大家不要给我面子一定要狠狠的指出来,那么有疑问的地方我一定会寻找更多的证据来解释,所以,本系列希望达到的是一个双赢的效果,

OpenGL入门学习

说起编程作图,大概还有很多人想起TC的#include <graphics.h>吧? 但是各位是否想过,那些画面绚丽的PC游戏是如何编写出来的?就靠TC那可怜的640*480分辨率.16色来做吗?显然是不行的. 本帖的目的是让大家放弃TC的老旧图形接口,让大家接触一些新事物. OpenGL作为当前主流的图形API之一,它在一些场合具有比DirectX更优越的特性. 1.与C语言紧密结合. OpenGL命令最初就是用C语言函数来进行描述的,对于学习过C语言的人来讲,OpenGL是容易理解和学习的

android graphic(14)—EGL和OpenGL ES之间的关系

OpenGL ES EGL 例子 EGL加载OpenGL ES库 涉及的库 库的加载 小结 OpenGL ES 什么是OpenGL? Open Graphics Library (OpenGL) is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. The API is typically used to intera

OpenGL开发环境配置-Windows/MinGW/Clion/CMake

因为某些原因,不想用过于臃肿的VS了,转而使用常用的jetbrains的CLion,Clion沿袭了jetbrans的优良传统,基本代码提示功能还是比较好的,不过就是对于windows不熟悉cmake(像我这样)的朋友可能不是太友好,经过了2个小时的查资料,终于正常运行了一个简单示例. 下面谈谈如何在Windows下配置这个开发环境. 起始,我是参考了我的前一篇OpenGL+VS开发环境的搭建,实际上除了freeglut重新下载的是MinGW版本之外,其他的文件并无区别,当然为了方便引用,我把所

OpenGL版本与OpenGL扩展机制

OpenGL版本与OpenGL扩展机制 1 opengl的版本区别(在opengl官方文档中有详细说明)    针对Opengl不同版本的升级是主要是扩展指令集.    现在版本是4.0啦1.1 opengl1.11995年,SGI推出了更为完善的OpenGL 1.1版本.OpenGL 1.1的性能比1.0版提高甚多.其中包括改进打印机支持,在增强元文件中包含OpenGL的调用,顶点数组的新特性,提高顶点位置.法线.颜色.色彩指数.纹理坐标.多边形边缘标识的传输速度,引入了新的纹理特性等等.1.

OpenGL 加载DDS文件(压缩纹理)

想必很多人都见过DDS这种文件,它是一个"图片文件",如果你安装了某些看图软件,你可以直接双击打开它来进行预览. 那么,这种DDS文件和我们常见的TGA/PNG之类的文件有何不同呢? DDS和TGA/PNG/JPG之类的"图片文件" 一样,支持"压缩",减少磁盘空间占用(把文件变小). 通常我们要加载一个TGA或者PNG文件到OpenGL的时候,都要先把文件数据还原成RGB格式的像素数据,然后用glTexImage2D把像素数据传到显存.这个过程

[翻译]opengl扩展教程1

[翻译]opengl扩展教程1 原文地址https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/extensions.php [翻译]opengl扩展教程1 简介 检测扩展 使用扩展 GLEW入门 入门简介 初始化GLEW 检测OpenGL版本 检测扩展 平台特定扩展 练习 简介 OpenGL扩展是为了使用3D图形硬件的新功能.硬件厂商定义新的函数到OpenGL来支持新的或增强已有的特性. 由单个厂商创建的扩展是"vendor-spec

opengl基本库介绍

开发基于OpenGL的应用程序,必须先了解OpenGL的库函数.它采用C语言风格,提供大量的函数来进行图形的处理和显示.OpenGL库函数的命名方式非常有规律.所有OpenGL函数采用了以下格式: <库前缀><根命令><可选的参数个数><可选的参数类型> 库前缀,有gl.glu.aux.glut.wgl.glx.agl等等,分别表示该函数属于OpenGL那个开发库.    从函数名后面中还可以看出需要多少个参数以及参数的类型.I代表int型,f代表float