1 Questions about GPUs AS-Temps réel – Bordeaux Philippe Decaudin Fabrice Neyret Stéphane Guy Sylvain Lefebvre

2 Overview 1.Suspicious behaviors of GPUs. 2.What could be improved quickly. 3.Our wishes.

3 1. Suspicious behaviors 3D Textures, MIP-mapping and anisotropy Clamp to border and MIP-mapping Deferred shading for conditions

4 3D textures and MIP-mapping Filtering of 3D textures is isotropic (same MIP-map level for u, v and w)  When texturing a slice of volume with a 3D texture, the slope of the slice controls the blur sloppy => blurry  With 2D textures, this problem is solved by anisotropic filtering, but: - it is not available for 3D textures… - no dsdw

5 Clamp_to_border and MIP-mapping Using non-square textures (2 a  2 b, a  b) CLAMP_TO_BORDER_ARB enabled MIP-map enabled  at MIP-map levels > log 2 (a) (with a < b), the texture becomes 1D: clamp doesn’t seem to work correctly…

6 Clamp_to_border and MIP-mapping a quad mapped with a white texture 256  64 (u,v) = (0,0) to (6,6) mapping clamped to [0,1]  [0,1] border color is black MIP-map level forced with GL_TECTURE_MIN_LOD Square texture (64  64)  correct (0,0) (6,6) Clamp problem  bug? Texture 256  64 MIP-map level = 1 (256  64) MIP-map level = 8 (1  1)

7 Clamp_to_border and MIP-mapping  all MIP-map levels 128x32 64x16 32x8 16x4 8x2 4x1 2x1 1x1

8 Deferred shading for conditions fast, but a few pixels are wrong 1 Theory: Custom shader: costly particular case for some pixels general case fast.

9 fast, but a few pixels are wrong flag wrong pixels in stencil 12 Deferred shading for conditions Theory:

10 fast, but a few pixels are wrong use slow correction shader only where needed 12 3 flag wrong pixels in stencil Deferred shading for conditions Theory:

11 fast, but a few pixels are wrong use slow correction shader only where needed 12 3 Practice: Does not work !? cost the same as full rendering stencil after fragment program ? flag wrong pixels in stencil Deferred shading for conditions

12 2. What could be improved quickly Front to back rendering with alpha Fog and pre-multiplied alpha Scale / Bias not limited to [0,1] Tiled textures storage

13 Front to back rendering with alpha Theory: front to back (to benefit Z-test culling) Practice with alpha: must disable depth_test !  landscapes, billboards, volumes… even more costly Suggested solution: glEnable(ALPHA_DEPTH_TEST) doing regular blending, then if (Ascreen>Athreshold) Zscreen:=Zfrag

14 Fog and pre-multiplied alpha Premultiplied alpha textures (aR,aG,aB,a) to avoid interpolation artefacts. Blend mode is then set to glBlendFunc(GL_ONE,GL_ONE_MINUS_SRC_ALPHA)

15 Fog and pre-multiplied alpha Problem: not compatible with standard Fog equation ( glEnable(GL_FOG) ) Fog equation: C frag ’= (1-f) C frag + f C fog In our case, C frag = aC (premultiplied alpha) Blend equation: C dest ’=C frag ’+ (1-a)C dest  C dest ’= (1-f) aC + f C fog + (1-a)C dest missing ‘a’ Suggestion: if SRC_ALPHA == GL_ONE then fog equation: (1-f) C + f a C fog

16 Scale / Bias not limited to [0,1] Theory: scale, bias to tune transparency, light, color… Practice: coef must lies in [0,1] !  applications which need coef > 1 must multipass (volume rendering, light maps…) Suggested Solution: Float operation in texture units for scaling.

17 Tiled textures storage Principle: –Use a set of tiles to create a larger texture fragment program

18 Tiled textures storage Numerous new advanced usage of tiles –Antialiased Parameterized Solid Texturing [Hart et al] ACM Transactions on Graphics 2002 –Adaptive Texture Maps [Kraus and Ertl] Graphics Hardware 2002 –Pattern Based Procedural Textures [Lefebvre and Neyret] I3D 2003 –… and more !

19 Tiled textures storage Storage requirements –Efficient selection from FP –No waste of memory –Ease filtering / interpolation of tiles per-tile border color per-tile MIP-mapping

20 Tiled textures storage Current solutions –Store as separate textures limited bindings no real selection in FP –Store in an atlas false neighborhood and no border color waste space if filtering on tiles limited to 4096x4096 –Store as a stack in a 3D Texture waste a lot of space (2 n ) ill-defined filtering

21 Tiled textures storage Our proposal: Texture stack 3D Texture with no filtering on R per-tile border colors per-tile filtering easy selection from fragment program s t r level x32x4 level x16x4 level x4x4

22 3. Our wishes Having features more coherent –programable blending –feedback buffer –read access to all state variables (ex: MIP-mapping) –r/w stencil from FP Native support of tiled textures Fragment culling order (stencil, A, depth) Tools for procedural textures

23 Having features more coherent Programable blending: –multi-pass algorithms with intermediate results –needs complex blending –current blending very limited compared to programable pipeline

24 Having features more coherent Feedback buffer: –lot of vertex attributes –few can be read back

25 Perspective correction rasterization in object space not always desired  need control on variables interpolated by rasterizer glEnable/Disable(param,GL_PERSPECTIVE_CORRECTION) Having features more coherent

26 Native support of tiled textures Difficulties –Storage (borders, repeat, …) –MIP-mapping –Linear interpolation

27 Fragment culling order Early culling essential for performance Would let the user specify test order between –alpha test –stencil –depth –discard (from FP)

28 Tools for procedural textures New texture types (envmap, indir., N, shaders, …)  custom filtering MIP-mapping levels –have to be infered from ddx ddy –while computed for standard textures  needs to be accessible (read) resolution specifiable by user

29 Questions about GPUs AS-Temps réel – Bordeaux Philippe Decaudin Fabrice Neyret Stéphane Guy Sylvain Lefebvre