San Jose | September 30, 2009 | Mark J. Kilgard, NVIDIA Corporation OpenGL 3.2 and More

OpenGL 3.2 and More

Mark J. Kilgard Principal System Software Engineer OpenGL driver Cg shading language OpenGL Utility Toolkit (GLUT) implementer co-author of Cg Tutorial

Principal System Software Engineer

OpenGL driver

Cg shading language

OpenGL Utility Toolkit (GLUT) implementer

co-author of Cg Tutorial

Overview OpenGL 3.2 Available today What’s in it? NVIDIA’s additional functionality Above & beyond OpenGL 3.2

OpenGL 3.2

Available today

What’s in it?

NVIDIA’s additional functionality

Above & beyond OpenGL 3.2

A brief 2-slide review of OpenGL 3.0 & 3.1 Before we get really started… You are already familiar and using OpenGL 3.1 aren’t you??

For review, OpenGL 3.0 Texturing Integer & floating-point texture formats Compact floating-point formats sRGB color space texture formats 1- and 2-component compressed texture formats 1D and 2D texture array targets Miscellaneous Vertex array objects Conditional rendering Multisample-aware stretch blits Fine control over mapping & flushing buffer sub-ranges Framebuffer functionality Render-to-texture with framebuffer objects sRGB blending Packed depth/stencil formats for render-buffers (and texturing) Per-color-attachment blend enables and color write masks Shader improvements OpenGL Shading Language 1.30

Texturing

Integer & floating-point texture formats

Compact floating-point formats

sRGB color space texture formats

1- and 2-component compressed texture formats

1D and 2D texture array targets

Miscellaneous

Vertex array objects

Conditional rendering

Multisample-aware stretch blits

Fine control over mapping & flushing buffer sub-ranges

Framebuffer functionality

Render-to-texture with framebuffer objects

sRGB blending

Packed depth/stencil formats for render-buffers (and texturing)

Per-color-attachment blend enables and color write masks

Shader improvements

OpenGL Shading Language 1.30

For review, OpenGL 3.1 Texturing Guarantees 16 texture units Texture buffer objects Texture rectangle target: 2D image with [0..width, 0..height] coordinate space Signed normalized texture formats Miscellaneous Fast data copying between buffer objects Primitive restart index for vertex arrays Shader improvements OpenGL Shading Language 1.40 Shader can access uniform values from buffer objects Instanced rendering provides instance counter to vertex shader

Texturing

Guarantees 16 texture units

Texture buffer objects

Texture rectangle target: 2D image with [0..width, 0..height] coordinate space

Signed normalized texture formats

Miscellaneous

Fast data copying between buffer objects

Primitive restart index for vertex arrays

Shader improvements

OpenGL Shading Language 1.40

Shader can access uniform values from buffer objects

Instanced rendering provides instance counter to vertex shader

OpenGL 3.2 modern GPU functionality, platform portability, API maturity & completeness

From the 1994 OpenGL 1.1 Data Flow… vertex processing rasterization & fragment coloring texture raster operations framebuffer pixel unpack pixel pack vertex puller client memory pixel transfer glReadPixels / glCopyPixels / glCopyTex{Sub}Image glDrawPixels glBitmap glCopyPixels glTex{Sub}Image glCopyTex{Sub}Image glDrawElements glDrawArrays selection / feedback / transform feedback glVertex* glColor* glTexCoord* etc. blending depth testing stencil testing accumulation storage access operations

… OpenGL 1.0 in detail Vertex processing Pixel processing Texture mapping Image primitive processing Pixel unpacking Pixel packing Vertex assembly texture image specification image rectangles, bitmaps primitive topology, transformed vertex data stenciling, depth testing, blending, accumulation pixel image primitive batch type, vertex attributes primitive batch type, vertex data fragment texture fetches pixel image or texture image specification image and bitmap fragments point, line, and polygon fragments pixels to pack unpacked pixels pixels fragments filtered texels buffer data vertices Legend programmable operations fixed-function operations copy pixels, copy texture image Fragment processing Geometric primitive assembly & processing Raster operations Framebuffer Command parser

… to the 2009 OpenGL 3.2 Data Flow Vertex processing Pixel processing Texture mapping Geometric primitive assembly & processing Image primitive processing Transform feedback Pixel unpacking Pixel packing Vertex assembly pixels in framebuffer object textures texture buffer objects texture image specification image rectangles, bitmaps primitive topology, transformed vertex data vertex texture fetches pixel pack buffer objects pixel unpack buffer objects vertex buffer objects transform feedback buffer objects buffer data, unmap buffer geometry texture fetches primitive batch type, vertex indices, vertex attributes primitive batch type, vertex data fragment texture fetches pixel image or texture image specification map buffer, get buffer data transformed vertex attributes image and bitmap fragments point, line, and polygon fragments pixels to pack unpacked pixels pixels fragments filtered texels buffer data vertices Legend programmable operations fixed-function operations copy pixels, copy texture image Buffer store uniform/ parameters buffer objects Fragment processing stenciling, depth testing, blending, accumulation Raster operations Framebuffer Command parser

Buffer Centric View of OpenGL Vertex Array Buffer Object (VaBO) Transform Feedback Buffer (XBO) Parameter Buffer (PaBO) Pixel Unpack Buffer (PuBO) Pixel Pack Buffer (PpBO) Bindable Uniform Buffer (BUB) Texture Buffer Object (TexBO) Vertex Puller Vertex Shading Geometry Shading Fragment Shading Texturing Array Element Buffer Object (VeBO) Pixel Pipeline vertex data texel data pixel data parameter data ( not ARB functionality yet ) glBegin, glDrawElements, etc. glDrawPixels, glTexImage2D, etc. glReadPixels, etc. Framebuffer

OpenGL 3.2 Functional Overview Direct3D-isms BGRA vertex component ordering Provoking vertex convention Drawing commands allowing modification of the base vertex index Upper-left and lower-left fragment coordinate conventions Geometry shaders Per-primitive programmability Shader improvements OpenGL Shading Language 1.50 Miscellaneous Depth clamping, synchronization, seamless cube map filtering, multisample improvements

Direct3D-isms

BGRA vertex component ordering

Provoking vertex convention

Drawing commands allowing modification of the base vertex index

Upper-left and lower-left fragment coordinate conventions

Geometry shaders

Per-primitive programmability

Shader improvements

OpenGL Shading Language 1.50

Miscellaneous

Depth clamping, synchronization, seamless cube map filtering, multisample improvements

Direct3Disms better OpenGL & Direct3D content portability

Direct3Dism Motivation A posteriori “3D content tied to API” scheme Without intending it, 3D application content gets tied to API’s conventions Your OpenGL application OpenGL driver same GPU Direct3D driver Your OpenGL application content Your Direct3D application Your Direct3D application content OpenGL conventions Direct3D conventions content authored to OpenGL conventions content authored to Direct3D conventions OpenGL API Direct3D API hardware interface 3D API interface

A posteriori “3D content tied to API” scheme

Without intending it, 3D application content gets tied to API’s conventions

NVIDIA Recognizes 3D API Reality You decide the 3D API best for your application Lots of reasons to pick your API choice Target systems, intended market, cross-platform requirements, software legacy, content creation vs. deployment, etc. Fundamentally, NVIDIA believes in Visual Computing (not APIs) So is essentially agnostic about your 3D API choice OpenGL, Direct3D 9/10/11, or OpenGL ES NVIDIA provides best implementations of all options; you pick NVIDIA’s belief in Visual Computing means Your 3D API choice shouldn’t tie down your 3D application or 3D content

You decide the 3D API best for your application

Lots of reasons to pick your API choice

Target systems, intended market, cross-platform requirements, software legacy, content creation vs. deployment, etc.

Fundamentally, NVIDIA believes in Visual Computing (not APIs)

So is essentially agnostic about your 3D API choice

OpenGL, Direct3D 9/10/11, or OpenGL ES

NVIDIA provides best implementations of all options; you pick

NVIDIA’s belief in Visual Computing means

Your 3D API choice shouldn’t tie down your 3D application or 3D content

Direct3Dism Concept Allows your 3D content to be API agnostic OpenGL supports both OpenGL & Direct3D conventions, so support either style Your OpenGL application OpenGL driver GPU Direct3D driver Your OpenGL application content Your Direct3D application Your Direct3D application content OpenGL API Direct3D API content authored to OpenGL conventions content authored to Direct3D conventions OpenGL + Direct3D conventions Direct3D conventions hardware interface 3D API interface Direct3D conventions supported by OpenGL too

Allows your 3D content to be API agnostic

OpenGL supports both OpenGL & Direct3D conventions, so support either style

OpenGL & Direct3D Conventions OpenGL 3.2 First vertex of primitive Last vertex of primitive (mostly) Provoking vertex for flat-shading OpenGL 3.2 Upper-left Lower-left Fragment coordinate origin Cg HLSL 9, 10, and 11 GLSL Shading Language syntax Convention OpenGL Direct3D Addressed by Window origin Lower-left, pixels at half-integers Upper-left, pixels on integers (DX9) pixels on half-integers (DX 10) projection matrix & front-facing re-configuration Clip space [-1…+1] 3 [-1…+1] 2 [0…1] projection matrix re-configuration 4-byte vertex color RGBA BGRA OpenGL 3.2 Shader bind granularity Linked (for GLSL) Per-domain (for Cg & assembly) Per-domain EXT_separate shader_objects Object manipulation Bind-to-edit, Bind-to-query Edit-by-name, Query-by-name EXT_direct_ state_access

Dealing with API Convention Differences Innocuous differences API granularity OpenGL fine-grain state vs. Direct3D 10 state blocks OpenGL selectors versus Direct3D direct state access Easily dealt with by reconfiguring existing state Examples: window origin & clip space conventions Formidable differences Format differences Unsupported formats such as 4-byte BGRA vertex colors Inconsistent state management Per-domain shaders vs. monolithic GLSL shaders Shaders coded to a particular shading language syntax GLSL vs. HLSL, achieve commonality via Cg Conventions baked into shaders Fragment coordinate origin as visible from a fragment shader fairly easy to address in your application difficult to address without 3D API help

Innocuous differences

API granularity

OpenGL fine-grain state vs. Direct3D 10 state blocks

OpenGL selectors versus Direct3D direct state access

Easily dealt with by reconfiguring existing state

Examples: window origin & clip space conventions

Formidable differences

Format differences

Unsupported formats such as 4-byte BGRA vertex colors

Inconsistent state management

Per-domain shaders vs. monolithic GLSL shaders

Shaders coded to a particular shading language syntax

GLSL vs. HLSL, achieve commonality via Cg

Conventions baked into shaders

Fragment coordinate origin as visible from a fragment shader

Impetus for Direct3Dism Effort Many software companies motivated this effort TransGaming Blizzard Destineer Aspyr CodeWeavers Direct result of feedback from 3D software engineers Yes, you can influence OpenGL’s direction & course

Many software companies motivated this effort

TransGaming

Blizzard

Destineer

Aspyr

CodeWeavers

Direct result of feedback from 3D software engineers

Yes, you can influence OpenGL’s direction & course

Supporting Direct3Disms Not New to OpenGL OpenGL has always supported multiple formats well OpenGL’s plethora of pixel and vertex formats Very first OpenGL extension: EXT_bgra Provides a pixel component ordering to match the color component ordering of Windows for 2D GDI rendering Made core functionality by OpenGL 1.3 Many OpenGL extensions have embraced Direct3Disms Secondary color Fog coordinate Point sprites OpenGL 3.0’s fine-grain buffer mapping

OpenGL has always supported multiple formats well

OpenGL’s plethora of pixel and vertex formats

Very first OpenGL extension: EXT_bgra

Provides a pixel component ordering to match the color component ordering of Windows for 2D GDI rendering

Made core functionality by OpenGL 1.3

Many OpenGL extensions have embraced Direct3Disms

Secondary color

Fog coordinate

Point sprites

OpenGL 3.0’s fine-grain buffer mapping

BGRA Vertex Array Order Direct3D 9’s most common usage for per-vertex colors is 32-bit D3DCOLOR data type: Red in bits 16:23 Green in bits 8:15 Blue in bits 0:7 Alpha in bits 24:31 Laid in memory, looks like BGRA order OpenGL assumes RGBA order for all vertex arrays However Direct3D colors not stored in packed unsigned bytes have RGBA order Direct3Dism EXT_vertex_array_bgra extension allows: glColorPointer( GL_BGRA , GL_UNSIGNED_BYTE, stride, pointer); glSecondaryColorPointer( GL_BGRA , GL_UNSIGNED_BYTE, stride, pointer); glVertexAttribPointer( GL_BGRA , GL_UNSIGNED_BYTE, stride, pointer); 8-bit red 8-bit alpha 8-bit green 8-bit blue bit 31 bit 0

Direct3D 9’s most common usage for per-vertex colors is 32-bit D3DCOLOR data type:

Red in bits 16:23

Green in bits 8:15

Blue in bits 0:7

Alpha in bits 24:31

Laid in memory, looks like BGRA order

OpenGL assumes RGBA order for all vertex arrays

However Direct3D colors not stored in packed unsigned bytes have RGBA order

Direct3Dism EXT_vertex_array_bgra extension allows: glColorPointer( GL_BGRA , GL_UNSIGNED_BYTE, stride, pointer); glSecondaryColorPointer( GL_BGRA , GL_UNSIGNED_BYTE, stride, pointer); glVertexAttribPointer( GL_BGRA , GL_UNSIGNED_BYTE, stride, pointer);

Provoking Vertex Order Conventions Direct3D uses “first” vertex of a triangle or line to determine which color is used for flat shading OpenGL uses “last” vertex for lines, triangles, and quads Except for polygons ( GL_POLYGON ) mode that use the first vertex Direct3D 9 pDev->SetRenderState( D3DRS_SHADEMODE, D3DSHADE_FLAT); OpenGL glShadeModel(GL_FLAT); Input triangle strip with per-vertex colors

Direct3D uses “first” vertex of a triangle or line to determine which color is used for flat shading

OpenGL uses “last” vertex for lines, triangles, and quads

Except for polygons ( GL_POLYGON ) mode that use the first vertex

Configurable Provoking Vertex Easy-to-use API New command glProvokingVertex // “native” OpenGL convention glProvokingVertex(GL_LAST_VERTEX_CONVENTION); // Direct3D convention glProvokingVertex(GL_FIRST_VERTEX_CONVENTION); OpenGL 3.2 promotion of EXT_provoking_vertex extension Affects fixed-function glShadeModel flat shaded attributes for fragment shaders geometry shaders that emit flat shaded attributes

Easy-to-use API

New command glProvokingVertex // “native” OpenGL convention glProvokingVertex(GL_LAST_VERTEX_CONVENTION); // Direct3D convention glProvokingVertex(GL_FIRST_VERTEX_CONVENTION);

OpenGL 3.2 promotion of EXT_provoking_vertex extension

Affects

fixed-function glShadeModel

flat shaded attributes for fragment shaders

geometry shaders that emit flat shaded attributes

Provoking Vertex Details Provoking vertex sounds really obscure Technically shade model is part of “deprecated” feature set of OpenGL However very common mode for real-time strategy games Many, many objects drawn this way Very difficult for application to “juggle” vertex data to match API’s native provoking vertex convention Particularly when using vertex buffer objects Quad behavior may vary Direct3D doesn’t support quadrilateral primitives So “first vertex” provoking vertex convention may or may not apply to quadrilateral primitives GeForce 8 say true for “quads follow the convention” GeForce 7 and earlier say false for “quads follow the convention” Check GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION boolean if you care

Provoking vertex sounds really obscure

Technically shade model is part of “deprecated” feature set of OpenGL

However very common mode for real-time strategy games

Many, many objects drawn this way

Very difficult for application to “juggle” vertex data to match API’s native provoking vertex convention

Particularly when using vertex buffer objects

Quad behavior may vary

Direct3D doesn’t support quadrilateral primitives

So “first vertex” provoking vertex convention may or may not apply to quadrilateral primitives

GeForce 8 say true for “quads follow the convention”

GeForce 7 and earlier say false for “quads follow the convention”

Check GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION boolean if you care

Provoking Vertex Behavior geometry shader primitives Last vertex convention First vertex convention Primitive type of polygon i 2i+3 2i-1 GL_TRIANGLE_STRIP_ADJACENCY 6i-1 6i-5 GL_TRIANGLE_ADJACENCY i+2 i+1 GL_LINE_STRIP_ADJACENCY 4i-1 4i-2 GL_LINES_ADJACENCY i i GL_POLYGON 2i+2 , if quads follow provoking vertex 2i+2 , if not 2i-1 2i+2 GL_QUAD_STRIP 4i , if quads follow provoking vertex 4i , if not 4i-3 4i GL_QUADS i+2 i+1 GL_TRIANGLE_FAN i+2 i GL_TRIANGLE_STRIP 3i 3i-2 GL_TRIANGLES i+1 i GL_LINE_STRIP i+1 , if i<n 1, if i=n i GL_LINE_LOOP 2i 2i-1 GL_LINES i i GL_POINT same same same same

Direct3D vs. OpenGL Coordinate System Conventions Window origin conventions Direct3D = upper-left origin OpenGL = lower-left origin Pixel center conventions Direct3D9 = pixel centers at integer locations OpenGL and Direct3D 10 = pixel centers at half-pixel locations Makes pixel centers for rasterization “match” texel centers for texturing Clip space conventions Direct3D = [-1,+1] for XY, [0,1] for Z OpenGL = [-1,+1] range for XYZ Affects How projection matrix is loaded Fragment shaders that access the window position Point sprites have upper-left texture coordinate origin OpenGL already lets application choose lower-left or upper-left

Window origin conventions

Direct3D = upper-left origin

OpenGL = lower-left origin

Pixel center conventions

Direct3D9 = pixel centers at integer locations

OpenGL and Direct3D 10 = pixel centers at half-pixel locations

Makes pixel centers for rasterization “match” texel centers for texturing

Clip space conventions

Direct3D = [-1,+1] for XY, [0,1] for Z

OpenGL = [-1,+1] range for XYZ

Affects

How projection matrix is loaded

Fragment shaders that access the window position

Point sprites have upper-left texture coordinate origin

OpenGL already lets application choose lower-left or upper-left

3 APIs, 3 Different Window Space Conventions Pixel center grids coordinate systems OpenGL Direct3D 9 Direct3D 10 Upper-left origin Lower-left origin = pixel sample center

Pixel center grids coordinate systems

Direct3D 9 to OpenGL How to go from Direct3D ’s [-1,+1]x[-1,+1]x[0,1] clip space to OpenGL’s [-1,+1] 3 integer-centered pixel centers to OpenGL’s half-pixel centers Simple state adjustment Projection matrix fudge glMatrixLoadIdentityEXT(GL_PROJECTION); glMatrixScalefEXT(GL_PROJECTION, 1, -1, 2); glMatrixTranslatefEXT(GL_PROJECTION, 0.5/windowWidth, 0.5/windowHeight, -0.5); Reverse convention for what is front-facing glFrontFace(GL_CW); // OpenGL default is GL_CCW Compensates for y-flip that reverses coordinate system’s handedness No need for API additions to support Direct3D 9’s system

How to go from Direct3D ’s

[-1,+1]x[-1,+1]x[0,1] clip space to OpenGL’s [-1,+1] 3

integer-centered pixel centers to OpenGL’s half-pixel centers

Simple state adjustment

Projection matrix fudge glMatrixLoadIdentityEXT(GL_PROJECTION); glMatrixScalefEXT(GL_PROJECTION, 1, -1, 2); glMatrixTranslatefEXT(GL_PROJECTION, 0.5/windowWidth, 0.5/windowHeight, -0.5);

Reverse convention for what is front-facing glFrontFace(GL_CW); // OpenGL default is GL_CCW

Compensates for y-flip that reverses coordinate system’s handedness

No need for API additions to support Direct3D 9’s system

Direct3D 10 to OpenGL How to go from Direct3D 10’s [-1,+1]x[-1,+1]x[0,1] clip space to OpenGL’s [-1,+1] 3 where both APIs have half-pixel centers Simple state adjustment Projection matrix fudge glMatrixLoadIdentityEXT(GL_PROJECTION); glMatrixScalefEXT(GL_PROJECTION, 1, -1, 2); glMatrixTranslatefEXT(GL_PROJECTION, 0, 0, // no half-pixel shift for Direct3 10 -0.5); Reverse convention for what is front-facing glFrontFace(GL_CW); // OpenGL default is GL_CCW Compensates for y-flip that reverses coordinate system’s handedness Again, no need for API additions to support Direct3D 10’s system

How to go from Direct3D 10’s

[-1,+1]x[-1,+1]x[0,1] clip space to OpenGL’s [-1,+1] 3

where both APIs have half-pixel centers

Simple state adjustment

Projection matrix fudge glMatrixLoadIdentityEXT(GL_PROJECTION); glMatrixScalefEXT(GL_PROJECTION, 1, -1, 2); glMatrixTranslatefEXT(GL_PROJECTION, 0, 0, // no half-pixel shift for Direct3 10 -0.5);

Reverse convention for what is front-facing glFrontFace(GL_CW); // OpenGL default is GL_CCW

Compensates for y-flip that reverses coordinate system’s handedness

Again, no need for API additions to support Direct3D 10’s system

Fragment Coordinate Convention Usage Typically used in post-processing shaders Examples: Motion blur Depth-of-field Shader assumes a particular convention for the fragment coordinate origin Attempting to “re-write” Direct3D shader tends to Compromise shader performance Introduces new “window height” uniform that must be always set correctly Hard to do automatically and robustly Robust approach: Allow shader author (or automatic translator) to specify convention explicitly

Typically used in post-processing shaders Examples:

Motion blur

Depth-of-field

Shader assumes a particular convention for the fragment coordinate origin

Attempting to “re-write” Direct3D shader tends to

Compromise shader performance

Introduces new “window height” uniform that must be always set correctly

Hard to do automatically and robustly

Robust approach: Allow shader author (or automatic translator) to specify convention explicitly

Fragment Shader Coordinate Conventions Required GLSL introduction #extension GL_ARB_fragment_coord_conventions : require Pick one of the following GLSL declarations: // “native” OpenGL convention in vec4 gl_FragCoord; // DirectX 9 convention layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord; // DirectX 10 convention layout(origin_upper_left) in vec4 gl_FragCoord; Also supported by NVIDIA assembly extensions OPTION ARB_fragment_coord_origin_upper_left; OPTION ARB_fragment_coord_pixel_center_integer;

Required GLSL introduction #extension GL_ARB_fragment_coord_conventions : require

Pick one of the following GLSL declarations: // “native” OpenGL convention in vec4 gl_FragCoord; // DirectX 9 convention layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord; // DirectX 10 convention layout(origin_upper_left) in vec4 gl_FragCoord;

Also supported by NVIDIA assembly extensions OPTION ARB_fragment_coord_origin_upper_left; OPTION ARB_fragment_coord_pixel_center_integer;

Deprecation there’s “old” & there’s “still supported”

Deprecation – OpenGL ARB view OpenGL has never removed features. However, After 15+ years, defining new features to work with old features becomes increasingly difficult OpenGL 3.0 marks features as deprecated OpenGL 3.0 does not remove any features Redundant, legacy and obsolete features Parts of OpenGL unlikely to be accelerated Guidance to developers to prepare for future revisions

OpenGL has never removed features. However,

After 15+ years, defining new features to work with old features becomes increasingly difficult

OpenGL 3.0 marks features as deprecated

OpenGL 3.0 does not remove any features

Redundant, legacy and obsolete features

Parts of OpenGL unlikely to be accelerated

Guidance to developers to prepare for future revisions

Deprecation – OpenGL ARB view OpenGL 3.1 removed these deprecated features Added support back with ARB_compatibility extension OpenGL 3.2 formalized this in two profiles “ Core” profile with features removes “ Compatibility” profile with all features present Implementation of “Core” mandatory “ Compatibility” optional

OpenGL 3.1 removed these deprecated features

Added support back with ARB_compatibility extension

OpenGL 3.2 formalized this in two profiles

“ Core” profile with features removes

“ Compatibility” profile with all features present

Implementation of “Core” mandatory

“ Compatibility” optional

Deprecation – NVIDIA view Set of removed functionality is in use by applications today, helping our customer’s business Using just “Core” OpenGL 3.2 is a huge effort in rewriting existing code OpenGL 3.2 “Core” not offering enough incentive to re-write existing code Deprecation is NOT in the best interest of ISVs and therefore not in NVIDIA’s business interest

Set of removed functionality is in use by applications today, helping our customer’s business

Using just “Core” OpenGL 3.2 is a huge effort in rewriting existing code

OpenGL 3.2 “Core” not offering enough incentive to re-write existing code

Deprecation is NOT in the best interest of ISVs and therefore not in NVIDIA’s business interest

Deprecation – NVIDIA view We will not remove ANY feature from our drivers OpenGL on NVIDIA will be fully backwards compatible NVIDIA has and will ship the Compatibility profile NVIDIA will fully support, tune and bug fix all features See our public statement: http://developer.nvidia.com/object/opengl_3_driver.html

We will not remove ANY feature from our drivers

OpenGL on NVIDIA will be fully backwards compatible

NVIDIA has and will ship the Compatibility profile

NVIDIA will fully support, tune and bug fix all features

See our public statement:

http://developer.nvidia.com/object/opengl_3_driver.html

Deprecation – Myths Feature removal will result in a faster driver Feature removal will result in a higher quality driver Feature removal will result in a cleaner API Not removing features means OpenGL will die Only useless features were deprecated Far from true

Feature removal will result in a faster driver

Feature removal will result in a higher quality driver

Feature removal will result in a cleaner API

Not removing features means OpenGL will die

Only useless features were deprecated

Far from true

So You can just ignore Deprecation NVIDIA values OpenGL API backward compatibility We don’t take API functionality away from you We aren’t going to force you to re-write apps Does deprecated functionality “stay fast”? Yes, of course—and stays fully tested Bottom-line: Old & new features run fast

NVIDIA values OpenGL API backward compatibility

We don’t take API functionality away from you

We aren’t going to force you to re-write apps

Does deprecated functionality “stay fast”?

Yes, of course—and stays fully tested

Bottom-line: Old & new features run fast

Geometry Shaders per-primitive programmability

Geometry Shaders via OpenGL Programmability for geometric primitives one geometric primitive in, zero or more primitives out Supported by NVIDIA’s OpenGL driver since GeForce 8 launch NV_gpu_program4 for assembly Cg 2.x’s gp4gp “geometry” profile NV_geometry_shader4 / EXT_geometry_shader4 for (GLSL) Standardized as an ARB extension in OpenGL 3.1 timeframe ARB_geometry_shader4 Now finally core functionality in OpenGL 3.2 Essentially unchanged from EXT and ARB versions

Programmability for geometric primitives

one geometric primitive in, zero or more primitives out

Supported by NVIDIA’s OpenGL driver since GeForce 8 launch

NV_gpu_program4 for assembly

Cg 2.x’s gp4gp “geometry” profile

NV_geometry_shader4 / EXT_geometry_shader4 for (GLSL)

Standardized as an ARB extension in OpenGL 3.1 timeframe

ARB_geometry_shader4

Now finally core functionality in OpenGL 3.2

Essentially unchanged from EXT and ARB versions

Geometry Shaders New programmable shader domain Operates on assembled primitives Triangles, lines, points, and new adjacency primitives Outputs zero or more primitives Must be point, line stripes, or triangle strips Primitive restarts allowed Warning: Not well suited for unbounded tessellation application Vertex shader Primitive assembly Geometry shader Rasterizer Fragment shader Raster operations framebuffer application programmable

New programmable shader domain

Operates on assembled primitives

Triangles, lines, points, and new adjacency primitives

Outputs zero or more primitives

Must be point, line stripes, or triangle strips

Primitive restarts allowed

Warning: Not well suited for unbounded tessellation

Geometry Shader Silhouette Edge Rendering silhouette edge detection geometry program Complete mesh Silhouette edges Useful for non-photorealistic rendering Looks like human sketching

More Geometry Shader Examples Shimmering point sprites Generate fins for lines Generate shells for fur rendering

Improved Interpolation Using geometry shader functionality Quadratic normal interpolation True quadrilateral rendering with mean value coordinate interpolation

Using geometry shader functionality

“Fair” Quadrilateral Interpolation glBegin(GL_QUADS); glColor3fv(red); glVertex3fv(lowerLeft); glColor3fv(green); glVertex3fv(lowerRight); glColor3fv(red); glVertex3fv(upperRight); glColor3fv(blue); glVertex3fv(upperLeft); glEnd(); Geometry shader actually operates on 4-vertex GL_LINE_ADJACENCY primitives instead of quads Wrong , slash triangle split Wrong , backslash triangle split Better : Mean value coordinates

glBegin(GL_QUADS);

glColor3fv(red); glVertex3fv(lowerLeft);

glColor3fv(green); glVertex3fv(lowerRight);

glColor3fv(red); glVertex3fv(upperRight);

glColor3fv(blue); glVertex3fv(upperLeft);

glEnd();

Geometry shader actually operates on 4-vertex GL_LINE_ADJACENCY primitives instead of quads

Geometry Shader-based Bump Map Setup Vertex shader does skinning Problem: how does texture-space basis for bump mapping respond to arbitrary skinning? Solution: geometry shader constructs per-triangle texture-basis using post-skinning vertex positions and normals So geometry shader: Computes object-to-texture space basis for triangle Can account of texture mirroring in normal map Transforms object-space vectors to texture space Outputs triangle Fragment shader uses texture-space normals for bump map shading

Vertex shader does skinning

Problem: how does texture-space basis for bump mapping respond to arbitrary skinning?

Solution: geometry shader constructs per-triangle texture-basis using post-skinning vertex positions and normals

So geometry shader:

Computes object-to-texture space basis for triangle

Can account of texture mirroring in normal map

Transforms object-space vectors to texture space

Outputs triangle

Fragment shader uses texture-space normals for bump map shading

Cg Code Shader performs texture-basis setup Can compile to GLSL or HLSL 10 code Cg 2.2 feature See working example code in Cg 2.2 TRIANGLE void md2bump_geometry( AttribArray < float4 > position : POSITION , AttribArray < float2 > texCoord : TEXCOORD0 , AttribArray < float3 > objPosition : TEXCOORD1 , AttribArray < float3 > objNormal : TEXCOORD2 , AttribArray < float3 > objView : TEXCOORD3 , AttribArray < float3 > objLight : TEXCOORD4 ) { float3 dXYZdU = objPosition[1] - objPosition[0]; float dSdU = texCoord[1].s - texCoord[0].s; float3 dXYZdV = objPosition[2] - objPosition[0]; float dSdV = texCoord[2].s - texCoord[0].s; float3 tangent = normalize (dSdV * dXYZdU - dSdU * dXYZdV); float area = determinant ( float2x2 (dSTdV, dSTdU)); float3 orientedTangent = area >= 0 ? tangent : -tangent; for ( int i=0; i<3; i++) { float3 normal = objNormal[i], binormal = cross (tangent,normal); float3x3 basis = float3x3 (orientedTangent, binormal, normal); float3 surfaceLightVector : TEXCOORD1 = mul (basis, objLight[i]); float3 surfaceViewVector : TEXCOORD2 = mul (basis, objView[i]); emitVertex (position[i], texCoord[i], surfaceLightVector, surfaceViewVector); } }

Shader performs texture-basis setup

Can compile to GLSL or HLSL 10 code

Cg 2.2 feature

See working example code in Cg 2.2

Geometry Shader-based Shadow Volume Generation un-shadowed bump-mapped shading via geometry shader texture-space basis setup shadow volume extrusion by geometry shader shadow region stencil multi-pass combination of shadowed and un-shadowed shading

Miscellaneous some other 3.2 goodness

Tripped Up By Near/Far Clipping Conventionally 3D APIs “clip” to near & far view frustum planes Results in classic artifacts Geometry is “cut open” by near clip plane Naïvely moving near plane closer poorly distributes depth buffer precision Alternatively, geometry is “lost” beyond the far clip plane no clipping problem closer to alien near clip plane cuts open alien head

Conventionally 3D APIs “clip” to near & far view frustum planes

Results in classic artifacts

Geometry is “cut open” by near clip plane

Naïvely moving near plane closer poorly distributes depth buffer precision

Alternatively, geometry is “lost” beyond the far clip plane

Depth Clamping to the Rescue Depth clamping API Easy to enable/disable glEnable(GL_DEPTH_CLAMP); glDisable(GL_DEPTH_CLAMP); What it does Disables near & far clip planes But this allows depth values to interpolate beyond [0,1] representable range of the depth buffer So additionally clamps interpolated values to [0,1] range

Depth clamping API

Easy to enable/disable glEnable(GL_DEPTH_CLAMP); glDisable(GL_DEPTH_CLAMP);

What it does

Disables near & far clip planes

But this allows depth values to interpolate beyond [0,1] representable range of the depth buffer

So additionally clamps interpolated values to [0,1] range

Depth Clamping Applications Avoid near plane “cut opens” via depth clamping Fragment shader replaces color of z=0 fragments with black In GLSL: if (gl_FragCoord.z == 0) gl_FragColor = vec4(0,0,0,1); Alternatively, use Painter’s algorithm for objects at the near plane Last (or first) fragment at z=0 “wins” Infinite Z-fail Shadow volumes See [Everett & Kilgard 2002] Conserves depth buffer precision when eye-space infinity must be within depth range

Avoid near plane “cut opens” via depth clamping

Fragment shader replaces color of z=0 fragments with black

In GLSL: if (gl_FragCoord.z == 0) gl_FragColor = vec4(0,0,0,1);

Alternatively, use Painter’s algorithm for objects at the near plane

Last (or first) fragment at z=0 “wins”

Infinite Z-fail Shadow volumes

See [Everett & Kilgard 2002]

Conserves depth buffer precision when eye-space infinity must be within depth range

Near Plane Depth Clamping Example without depth clamping depth clamping enabled * * simple situation because depth complexity at z=0 is a single layer

Seam-free Cube Map Edges Cube maps have edges along each face Traditionally texture mapping hardware simply clamps to these seam edges Results in “seam” artifacts Particularly when level-of-detail bias is large Meaning very blurry levels But seams appear sharply Use glEnable( GL_TEXTURE_CUBE_MAP_SEAMLESS) to mitigate these artifacts seam

Cube maps have edges along each face

Traditionally texture mapping hardware simply clamps to these seam edges

Results in “seam” artifacts

Particularly when level-of-detail bias is large

Meaning very blurry levels

But seams appear sharply

Use glEnable( GL_TEXTURE_CUBE_MAP_SEAMLESS) to mitigate these artifacts

Seamless Cube Maps: Before and After Before: with edge seams After: without seams

Before: with edge seams

After: without

Remaining OpenGL 3.2 Features Async objects Synchronization of GPU completion Supports synchronization between multiple contexts Draw elements base index Provides a base added to all vertex indices Multisampled renderbuffers Also can query framebuffer’s sample locations

Async objects

Synchronization of GPU completion

Supports synchronization between multiple contexts

Draw elements base index

Provides a base added to all vertex indices

Multisampled renderbuffers

Also can query framebuffer’s sample locations

Beyond OpenGL 3.2 NVIDIA’s further contributions

Texture arrays 1D texture array 2D texture array Cube map texture array Multisample 2D texture multisample 2D texture array multisample All of OpenGL’s Texture Targets Conventional targets 1D texture 2D texture 3D texture Special addressing Cube map texture cube face selection Rectangle texture [0..w]x[0..h] range Texture buffer 1D unfiltered buffer objects

Texture arrays

1D texture array

2D texture array

Cube map texture array

Multisample

2D texture multisample

2D texture array multisample

Conventional targets

1D texture

2D texture

3D texture

Special addressing

Cube map texture

cube face selection

Rectangle texture

[0..w]x[0..h] range

Texture buffer

1D unfiltered buffer objects

Bindless Graphics NVIDIA keeps building faster and faster GPUs But that x86 core feeding the GPU isn’t getting faster at anything near the same rate! Makes your application more & more likely to be CPU limited, instead of GPU limited Bundling OpenGL state in objects helps But time goes on… GPUs keep getting faster… Eventually even binding to objects becomes a bottleneck Hence the desire for “bindless” graphics Extensions: NV_vertex_buffer_unified_memory (VBUM) for bindless vertex pulling NV_shader_buffer_load (SBL) for bindless buffer loads from shaders

NVIDIA keeps building faster and faster GPUs

But that x86 core feeding the GPU isn’t getting faster at anything near the same rate!

Makes your application more & more likely to be CPU limited, instead of GPU limited

Bundling OpenGL state in objects helps

But time goes on… GPUs keep getting faster…

Eventually even binding to objects becomes a bottleneck

Hence the desire for “bindless” graphics

Extensions:

NV_vertex_buffer_unified_memory (VBUM) for bindless vertex pulling

NV_shader_buffer_load (SBL) for bindless buffer loads from shaders

“Classic” OpenGL 1.0 Model Application Driver GPU command buffer GPU Video memory wide stream of commands wide interconnect OpenGL commands contains data directly Examples: immediate mode vertices, pixels to draw, downloaded texels Inefficient All data flows through the CPU GPU can’t access the data directly from video memory

OpenGL commands contains data directly

Examples: immediate mode vertices, pixels to draw, downloaded texels

Inefficient

All data flows through the CPU

GPU can’t access the data directly from video memory

Object Bind Model of OpenGL 2.x/3.x OpenGL commands “name” objects to use Objects allow GPU to access object data (texels, vertices, pixels, constants, etc.) via fast video memory directly Driver must lookup and access object’s vital information Tends to generate lots of cache misses Cache misses are the bane of modern, fast CPUs Application Driver GPU command buffer GPU Video memory narrow stream of commands wide interconnect System memory expensive stream of cache misses

OpenGL commands “name” objects to use

Objects allow GPU to access object data (texels, vertices, pixels, constants, etc.) via fast video memory directly

Driver must lookup and access object’s vital information

Tends to generate lots of cache misses

Cache misses are the bane of modern, fast CPUs

Bindless Graphics Model of OpenGL OpenGL commands and shaders can use GPU addresses of buffers So driver doesn’t have to translate to addresses & doesn’t take cache misses GPU addresses for Vertex buffer offsets Constant loads from buffers within shaders Application Driver GPU command buffer GPU Video memory narrow stream of commands wide interconnect feedback GPU address at creation time

OpenGL commands and shaders can use GPU addresses of buffers

So driver doesn’t have to translate to addresses

& doesn’t take cache misses

GPU addresses for

Vertex buffer offsets

Constant loads from buffers within shaders

Direct State Access Existing OpenGL model Bind-to-edit , bind-to-query , bind-to-use One bind operation for all three purposes To change a GL object, you must first “bind” to it Example glBindTexture(GL_TEXTURE_2D, obj); gl Tex Parameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); Bind-to-edit leads to unnecessary re-validations NEW additional Direct State Access (DSA) approach Edit-by-name To change a GL object, name the object to change Example gl Texture ParameteriEXT(obj, GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); Extension: EXT_direct_state_access

Existing OpenGL model

Bind-to-edit , bind-to-query , bind-to-use

One bind operation for all three purposes

To change a GL object, you must first “bind” to it

Example glBindTexture(GL_TEXTURE_2D, obj); gl Tex Parameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

Bind-to-edit leads to unnecessary re-validations

NEW additional Direct State Access (DSA) approach

Edit-by-name

To change a GL object, name the object to change

Example gl Texture ParameteriEXT(obj, GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

Extension: EXT_direct_state_access

What is the root of the problem? “ Selectors” OpenGL state that tells which state other OpenGL commands should update Think of selectors as “sticky” phantom parameters to all your matrix, texture, program, buffers, etc. commands and queries Examples of selectors glMatrixMode glActiveTexture glBindTexture glBindProgramARB glUseProgram two distinct selectors for texture commands, extra confusing

“ Selectors”

OpenGL state that tells which state other OpenGL commands should update

Think of selectors as “sticky” phantom parameters to all your matrix, texture, program, buffers, etc. commands and queries

Examples of selectors

glMatrixMode

glActiveTexture

glBindTexture

glBindProgramARB

glUseProgram

Reasons to Avoid Selectors Direct3D has an “edit-by-name” model of operation Means Direct3D has no selectors Having to manage selectors when porting Direct3D or console code to OpenGL is awkward Requires deferring updates to minimize selector and object bind changes Layered libraries can’t count of selector state To be safe when updating sate controlled by selectors, such libraries must use idiom Save selector, Set selector, Update state, Restore selector Bad for performance, particularly bad for dual-core drivers since queries are expensive Cg 2.2 October 2009 makes use of DSA automatically when available

Direct3D has an “edit-by-name” model of operation

Means Direct3D has no selectors

Having to manage selectors when porting Direct3D or console code to OpenGL is awkward

Requires deferring updates to minimize selector and object bind changes

Layered libraries can’t count of selector state

To be safe when updating sate controlled by selectors, such libraries must use idiom

Save selector, Set selector, Update state, Restore selector

Bad for performance, particularly bad for dual-core drivers since queries are expensive

Cg 2.2 October 2009 makes use of DSA automatically when available

Direct State Access Advantages Less error-prone Consider this code glRotatef(phi, x,y,z); Which matrix did you change? Depends on how the matrix mode selector was last left! Instead consider the DSA version gl Matrix RotatefEXT( GL_MODELVIEW , phi, x,y,z); Another example Consider this code glActiveTexture(GL_TEXTURE3); some_function(); glBindTexture(GL_TEXTURE2D, 89); But what if some_function calls glActiveTexture ? It might not now, but could in the future! Instead use glBind Multi TextureEXT( GL_TEXTURE3 , GL_TEXTURE_2D, 89); Problem solved!

Less error-prone

Consider this code glRotatef(phi, x,y,z);

Which matrix did you change?

Depends on how the matrix mode selector was last left!

Instead consider the DSA version gl Matrix RotatefEXT( GL_MODELVIEW , phi, x,y,z);

Another example

Consider this code glActiveTexture(GL_TEXTURE3); some_function(); glBindTexture(GL_TEXTURE2D, 89);

But what if some_function calls glActiveTexture ?

It might not now, but could in the future!

Instead use glBind Multi TextureEXT( GL_TEXTURE3 , GL_TEXTURE_2D, 89);

Problem solved!

Direct State Access Advantages More efficient layered libraries Consider a library that uses OpenGL commands to create a texture object from an image file Example: loadPNGtoGLtexture(GLuint texobj, …); Ideally, calling loadPNGtoGLtexture shouldn’t disturb the current bound texture Preserving the current bound texture requires a save-selector/change-state/restore-selector idiom GLint saved_current_binding; glGetIntegerv(GL_TEXTURE_BINDING_2D, &saved_current_binding); glBindTexture(GL_TEXTURE_2D, texobj); // now you can change texobj with bind-to-edit commands glBindTexture(GL_TEXTURE_2D, saved_current_binding); But save/change/restore undermines dual-core OpenGL operation Because GL queries of the selector sync the app and driver threads DSA routines avoid disturbing selectors Cg 2.2 October 2009 is an example of such a library

More efficient layered libraries

Consider a library that uses OpenGL commands to create a texture object from an image file

Example: loadPNGtoGLtexture(GLuint texobj, …);

Ideally, calling loadPNGtoGLtexture shouldn’t disturb the current bound texture

Preserving the current bound texture requires a save-selector/change-state/restore-selector idiom GLint saved_current_binding; glGetIntegerv(GL_TEXTURE_BINDING_2D, &saved_current_binding); glBindTexture(GL_TEXTURE_2D, texobj); // now you can change texobj with bind-to-edit commands glBindTexture(GL_TEXTURE_2D, saved_current_binding);

But save/change/restore undermines dual-core OpenGL operation

Because GL queries of the selector sync the app and driver threads

DSA routines avoid disturbing selectors

Cg 2.2 October 2009 is an example of such a library

Latched State Direct State Access solves another problem Some OpenGL state is “latched” by subsequent commands Think of latched state as phantom parameters to commands that come from the OpenGL state Examples: pixel store (pack/unpack) state, vertex array state Provides new commands glPushClientAttribDefaultEXT command Like glPushClientAttrib but also resets affected state to default Fast and efficient

Direct State Access solves another problem

Some OpenGL state is “latched” by subsequent commands

Think of latched state as phantom parameters to commands that come from the OpenGL state

Examples: pixel store (pack/unpack) state, vertex array state

Provides new commands

glPushClientAttribDefaultEXT command

Like glPushClientAttrib but also resets affected state to default

Fast and efficient

Copy Image Fast copies of pixels between image objects 1D textures, 2D textures, 3D textures, cube maps, texture rectangles, 1D texture arrays, 2D texture arrays, cube map texture arrays, & render-buffers all work Pixel data can be 1D, 2D, or 3D Best part Image objects can belong to distinct OpenGL rendering contexts Even when contexts do not share objects! Even when contexts on system’s different physical GPUs Extension: NV_copy_image

Fast copies of pixels between image objects

1D textures, 2D textures, 3D textures, cube maps, texture rectangles, 1D texture arrays, 2D texture arrays, cube map texture arrays, & render-buffers all work

Pixel data can be 1D, 2D, or 3D

Best part

Image objects can belong to distinct OpenGL rendering contexts

Even when contexts do not share objects!

Even when contexts on system’s different physical GPUs

Extension: NV_copy_image

Basic Copy Image Command Basic prototype, for within a context void glCopyImageSubDataNV( GLuint srcName, GLenum srcTarget, GLint srcLevel, GLint srcX, GLint srcY, GLint srcZ, GLuint dstName, GLenum dstTarget, GLint dstLevel, GLint dstX, GLint dstY, GLint dstZ, GLsizei width, GLsizei height, GLsizei depth ); Color key: source arguments destination arguments sub-image dimensions

Basic prototype, for within a context void glCopyImageSubDataNV( GLuint srcName, GLenum srcTarget, GLint srcLevel, GLint srcX, GLint srcY, GLint srcZ, GLuint dstName, GLenum dstTarget, GLint dstLevel, GLint dstX, GLint dstY, GLint dstZ, GLsizei width, GLsizei height, GLsizei depth );

Color key:

source arguments

destination arguments

sub-image dimensions

Texture Barrier Background Framebuffer objects allow rendering into textures Nothing keeps you from sampling a texture you are also bound to, though the behavior is specified to be undefined Provides a mechanism to avoid read-after-write hazards when rendering into a bound texture In limited circumstances Reads (including all filtered samples) and writes are to/from disjoint pixels There is only a single read and write of a pixel by a fragment shader “over” that pixel without an intervening glTextureBarrierNV() command Extension: NV_texture_barrier

Background

Framebuffer objects allow rendering into textures

Nothing keeps you from sampling a texture you are also bound to, though the behavior is specified to be undefined

Provides a mechanism to avoid read-after-write hazards when rendering into a bound texture

In limited circumstances

Reads (including all filtered samples) and writes are to/from disjoint pixels

There is only a single read and write of a pixel by a fragment shader “over” that pixel without an intervening glTextureBarrierNV() command

Extension: NV_texture_barrier

Improved: Parameter Buffer Object Parameter buffer objects give shaders access to values stored in buffers Also called constant or uniform buffers Supported by Cg 2.2’s BUFFER semantics Originally just 32-bit scalars or 32-bit 4-component vectors Now 1, 2, 4, 8, or 16 byte accesses allowed Extension: NV_parameter_buffer_object2

Parameter buffer objects give shaders access to values stored in buffers

Also called constant or uniform buffers

Supported by Cg 2.2’s BUFFER semantics

Originally just 32-bit scalars or 32-bit 4-component vectors

Now 1, 2, 4, 8, or 16 byte accesses allowed

Extension: NV_parameter_buffer_object2

Separate Shader Objects Combining different GLSL shaders at once Needed linking Better to allow mixing and matching of shader objects Like Direct3D Like OpenGL assembly extensions Extension: EXT_separate_shader_objects (SSO) Specular brick bump mapping Red diffuse Wobbly torus Smooth torus Different GLSL vertex shaders Different GLSL fragment shaders

Combining different GLSL shaders at once

Needed linking

Better to allow mixing and matching of shader objects

Like Direct3D

Like OpenGL assembly extensions

Extension: EXT_separate_shader_objects (SSO)

Separate Shader Object Binding Per-domain binding glUseShaderProgramEXT(GL_VERTEX_SHADER, vprog); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, gprog); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, fprog); Uses a linked program object, but only the portion of that linked program for the specified domain Introduces selector for glUniform calls glActiveProgramEXT(program_updated_by_glUniform); Better to use DSA’s selector-free glProgramUniform*EXT commands

Per-domain binding glUseShaderProgramEXT(GL_VERTEX_SHADER, vprog); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, gprog); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, fprog);

Uses a linked program object, but only the portion of that linked program for the specified domain

Introduces selector for glUniform calls glActiveProgramEXT(program_updated_by_glUniform);

Better to use DSA’s selector-free glProgramUniform*EXT commands

glUseProgram Equivalence Question: What does the existing glUseProgram call “mean” in the context of SSO? glUseProgram(glsl_prog); Answer : It is exactly equivalent to these calls: glUseShaderProgramEXT(GL_VERTEX_SHADER, glsl_prog); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, glsl_prog); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, glsl_prog); glActiveProgramEXT(glsl_prog);

Question: What does the existing glUseProgram call “mean” in the context of SSO? glUseProgram(glsl_prog);

Answer : It is exactly equivalent to these calls: glUseShaderProgramEXT(GL_VERTEX_SHADER, glsl_prog); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, glsl_prog); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, glsl_prog); glActiveProgramEXT(glsl_prog);

Convenient 1-Step Single-domain Shader Loading GLSL requires elaborate multi-step API for compiling/linking a shader Over-kill for separate shader objects Desirable to have an API more like glProgramStringARB 1-Step command glCreateShaderProgramEXT( GLenum domain, const char *shader_string); Just a convenience function You don’t have to use it for SSO You can still create separate shaders with multi-step API Sometimes necessary for binding attributes and fragment out locations

GLSL requires elaborate multi-step API for compiling/linking a shader

Over-kill for separate shader objects

Desirable to have an API more like glProgramStringARB

1-Step command glCreateShaderProgramEXT( GLenum domain, const char *shader_string);

Just a convenience function

You don’t have to use it for SSO

You can still create separate shaders with multi-step API

Sometimes necessary for binding attributes and fragment out locations

glCreateShaderProgramEXT Equivalent to: const GLuint shader = glCreateShader (type); if (shader) { const GLint len = ( GLint ) strlen(string); glShaderSource (shader, 1, &string, &len); glCompileShader (shader); const GLuint program = glCreateProgram (); if (program) { GLint compiled = GL_FALSE ; glGetShaderiv (shader, GL_COMPILE_STATUS , &compiled); if (compiled) { glAttachShader( program, shader); glLinkProgram (program); glDetachShader (program, shader); } // Possibly... if ( active-user-defined-varyings-in-linked-program ) { append-error-to-info-log set-program-link-status-false } append-shader-info-log-to-program-info-log } glDeleteShader (shader); return program; } else { return 0; }

Equivalent to:

const GLuint shader = glCreateShader (type);

if (shader) {

const GLint len = ( GLint ) strlen(string);

glShaderSource (shader, 1, &string, &len);

glCompileShader (shader);

const GLuint program = glCreateProgram ();

if (program) {

GLint compiled = GL_FALSE ;

glGetShaderiv (shader, GL_COMPILE_STATUS , &compiled);

if (compiled) {

glAttachShader( program, shader);

glLinkProgram (program);

glDetachShader (program, shader);

}

// Possibly...

if ( active-user-defined-varyings-in-linked-program ) {

append-error-to-info-log

set-program-link-status-false

}

append-shader-info-log-to-program-info-log

}

glDeleteShader (shader);

return program;

} else {

return 0;

}

Passing Varyings Between Separate Shader Objects Programs in separate domains should pass varyings through builtin varyings (NOT user-specified varyings) So instead of varying float4 my_varying; Use a built-in such as gl_Texcoord[0] Guarantees up-stream and down-stream domains rendezvous with the same value Use of user-declared varyings are undefined Compiling Cg code to GLSL profiles guarantees this is the case Cg has semantics to indicate how varyings correspond to API resources Example Cg declaration: float4 my_varying : TEXCOORD0;

Programs in separate domains should pass varyings through builtin varyings (NOT user-specified varyings)

So instead of varying float4 my_varying;

Use a built-in such as gl_Texcoord[0]

Guarantees up-stream and down-stream domains rendezvous with the same value

Use of user-declared varyings are undefined

Compiling Cg code to GLSL profiles guarantees this is the case

Cg has semantics to indicate how varyings correspond to API resources

Example Cg declaration: float4 my_varying : TEXCOORD0;

Thoughts of OpenGL Future what direction now?

Where Do OpenGL Extensions Come From? 44% of extensions are “core” or multi-vendor Lots of vendors have initiated extensions Extending OpenGL is industry-wide collaboration EXT SGI SGIS SGIX ARB NV Others Others ATI APPLE MESA Source: http://www.opengl.org/registry (Dec 2008)

44% of extensions are “core” or multi-vendor

Lots of vendors have initiated extensions

Extending OpenGL is industry-wide collaboration

What’s Driving OpenGL Modernization? Human desire for Visual Intuition and Entertainment Embarrassing Parallelism of Graphics Increasing Semiconductor Density Particularly the hardware-amenable, latency tolerant nature of rasterization Particularly interactive video games

Conclusions NVIDIA’s OpenGL driver leads the industry Functional, performance, & semantic parity with Direct3D NVIDIA provides OpenGL 3.2 now If past is prologue…  NVIDIA OpenGL extensions: where to-be-core functionality shows up first Get a head-start by using the functionality now All new GPU functionality exposed for OpenGL in first shipping NVIDIA driver

NVIDIA’s OpenGL driver leads the industry

Functional, performance, & semantic parity with Direct3D

NVIDIA provides OpenGL 3.2 now

If past is prologue… 

NVIDIA OpenGL extensions: where to-be-core functionality shows up first

Get a head-start by using the functionality now

All new GPU functionality exposed for OpenGL in first shipping NVIDIA driver

More Information NVIDIA OpenGL 3.2 driver Available now! http://developer.nvidia.com/object/opengl_3_driver.html OpenGL 3.2 specification http://www.opengl.org/registry/doc/glspec32.compatibility.20090803.pdf NVIDIA’s OpenGL extension registry http://developer.nvidia.com/object/nvidia_opengl_specs.html Cg Toolkit 2.2 October 2009 Includes geometry shader examples shown here http://developer.nvidia.com/object/ cg_toolkit.html

NVIDIA OpenGL 3.2 driver

Available now!

http://developer.nvidia.com/object/opengl_3_driver.html

OpenGL 3.2 specification

http://www.opengl.org/registry/doc/glspec32.compatibility.20090803.pdf

NVIDIA’s OpenGL extension registry

http://developer.nvidia.com/object/nvidia_opengl_specs.html

Cg Toolkit 2.2 October 2009

Includes geometry shader examples shown here

http://developer.nvidia.com/object/ cg_toolkit.html

Links to Specific Extension Specifications Provoking Vertex Vertex Array BGRA Depth Clamp Texture Multisample Seamless Cube Map Fragment Coordinate Conventions Synchronization Objects Geometry Shaders Bindless graphics Shader Buffer Load Vertex Buffer Unified Memory Direct State Access Separate Shader Objects Copy Image Texture Barrier Draw Elements Base Vertex

Provoking Vertex

Vertex Array BGRA

Depth Clamp

Texture Multisample

Seamless Cube Map

Fragment Coordinate Conventions

Synchronization Objects

Geometry Shaders

Bindless graphics

Shader Buffer Load

Vertex Buffer Unified Memory

Direct State Access

Separate Shader Objects

Copy Image

Texture Barrier

Draw Elements Base Vertex