Geometry-Aware Framebuffer Level of Detail

Total Page:16

File Type:pdf, Size:1020Kb

Geometry-Aware Framebuffer Level of Detail Eurographics Symposium on Rendering 2008 Volume 27 (2008), Number 4 Steve Marschner and Michael Wimmer (Guest Editors) Geometry-Aware Framebuffer Level of Detail Lei Yang1 Pedro V. Sander1 Jason Lawrence2 1Hong Kong University of Science and Technology 2University of Virginia Abstract This paper introduces a framebuffer level of detail algorithm for controlling the pixel workload in an interactive rendering application. Our basic strategy is to evaluate the shading in a low resolution buffer and, in a second ren- dering pass, resample this buffer at the desired screen resolution. The size of the lower resolution buffer provides a trade-off between rendering time and the level of detail in the final shading. In order to reduce approximation er- ror we use a feature-preserving reconstruction technique that more faithfully approximates the shading near depth and normal discontinuities. We also demonstrate how intermediate components of the shading can be selectively resized to provide finer-grained control over resource allocation. Finally, we introduce a simple control mecha- nism that continuously adjusts the amount of resizing necessary to maintain a target framerate. These techniques do not require any preprocessing, are straightforward to implement on modern GPUs, and are shown to provide significant performance gains for several pixel-bound scenes. Categories and Subject Descriptors (according to ACM CCS): I.3.3 [Computer Graphics]: Picture/Image Generation 1. Introduction and Related Work al. [SGNS07], we apply the joint bilateral filter [TM98, Programmable graphics hardware has brought with it a KCLU07] to consider differences in scene depth and sur- steady increase in the complexity of real-time rendering ap- face orientation during framebuffer upsampling. Second, we plications, often expressed as a greater number of arithmetic extend traditional resizing to allow computing partial com- operations and texture accesses required to shade each pixel. ponents of the shading at different resolutions. This allows, In response, researchers have begun investigating fully gen- for example, evaluating a detailed texture map at the full eral and automatic methods for reducing the pixel process- framebuffer resolution while still reaping the performance ing workload at an acceptable amount of approximation er- benefits of resizing a more computationally intensive inter- ror. These include techniques for automatically simplifying mediate calculation. Third, we present a feedback control shader programs [OKS03, Pel05] and data reuse [ZWL05, mechanism that automatically determines the degree of re- ∗ sizing necessary to achieve a target framerate. This approach DWWL05, NSL 07] which exploit the spatio-temporal co- ∗ herence in animated image sequences by reusing data gener- is analogous to geometry LOD methods [LWC 02] in that it ated in previously rendered frames to accelerate the calcula- controls one aspect of the rendering workload by reducing tion of the shading in the current frame. A related approach the number of pixels that are processed. We evaluate these is to exploit the spatial coherence within just a single frame techniques using several pixel-bound test scenes to demon- by simply rendering the scene to a lower resolution buffer strate their benefits over conventional resizing. that is then upsampled to the desired screen resolution in a Our approach bears a number of similarities to interleaved second rendering pass. Introduced as dynamic video resizing sampling techniques [SIMP06, LSK∗07] which reconstruct in the InfiniteReality rendering system [MBDM97], this sim- a smooth approximation of some component of the shading ple technique is effective for controlling the pixel workload, (e.g., indirect illumination) from a noisy estimate. As this but suffers from noticeable sampling artifacts near silhou- noisy approximation is smoothed to produce the final frame, ettes and other discontinuities in the shading (Figure 2). care must be taken to avoid integrating across discontinu- This paper extends conventional dynamic resizing in three ities in scene geometry. The method proposed by Laine et key ways to provide a framebuffer level of detail (LOD) al. [LSK∗07] uses a bilateral filter similar to the one we ap- system. Following Laine et al. [LSK∗07] and Sloan et ply here. However, interleaved sampling reduces the average c 2008 The Author(s) Journal compilation c 2008 The Eurographics Association and Blackwell Publishing Ltd. Published by Blackwell Publishing, 9600 Garsington Road, Oxford OX4 2DQ, UK and 350 Main Street, Malden, MA 02148, USA. Yang et al. / Geometry-Aware Framebuffer Level of Detail number of samples processed in the shader at every pixel features of the shading. We use a geometry-aware recon- (e.g., virtual point light sources accumulated [LSK∗07]) struction filter inspired by the bilateral filter [TM98] to re- whereas dynamic resizing reduces the number of expensive duce these artifacts. The basic idea is to modify the re- shader invocations within a single frame. In this respect, they construction kernel at each pixel to avoid integrating across are complimentary approaches for addressing the same prob- shading data associated with different regions in the scene. lem of reducing shading costs. Specifically, we weight the contribution of each pixel in L to- ward the reconstruction of each pixel in H based not only on The benefit of selectively resizing an expensive compo- their distance in the image plane, but also on the difference nent of the shading has been demonstrated in interactive between their respective scene depths and surface normals. systems that simulate certain aspects of global illumina- At each rendered pixel x in H, a pixel shader first computes tion [SGNS07, HPB06]. In fact, Sloan et al. [SGNS07] also i the surface normal nH and scene depth zH and reconstructs apply a reconstruction filter similar to ours. However, these i i the surface color cH according to systems have all focused on optimizing a specific render- i ing task in which resizing some partial value brings a prof- L H L H L H ∑c j f (xˆi,x j) g(|ni − n j |,σn) g(|zi − z j |,σz) itable speed/error trade-off. This paper focuses on the role ci = H L H L , (1) ∑ f (xˆi,x j) g(|n − n |,σn) g(|z − z |,σz) geometry-aware resizing plays within a general strategy for i j i j regulating shading costs and we present a number of differ- L L L where c j , n j , and z j are the respective counterparts in L ent effects for which resizing has clear benefits. Finally, a andx ˆi is the position of xi after having been downsampled number of hybrid CPU/GPU cache-based interactive render- in each dimension by r. Note that the normals are defined ing systems have also explored edge-aware framebuffer re- in screen-space so the vector n = (0,0,1) points toward the construction [BWG03,VALBW06]. Although these methods viewer. This sum is carried out over all the pixels in L. The may apply in this context as well, our emphasis is on provid- domain filter f weights the contribution of each pixel in L ing a lightweight method that runs entirely on the GPU and according to its distance in the image plane. Instead of mod- can be easily incorporated into existing real-time systems. eling this as a Gaussian, as is commonly done with the bi- lateral filter, we instead use a simple tent function which 2. Geometry-Aware Framebuffer Resizing restricts this sum to only the 2 × 2 grid of nearest pixels. In our approach each frame is rendered in two passes. In the We found this gave acceptable results at a fraction of the first pass, the scene geometry is rendered to a low resolution compute overhead. The range filters g(·,σn) and g(·,σz) are buffer L which stores the color, depth, and surface normal modeled as Gaussians and weight each pixel based on dif- at each pixel. In the second pass, the scene geometry is ren- ferences in surface normals and scene depths, respectively. dered to the framebuffer H at the desired screen resolution A similar generalization of the bilateral filter was pro- using a pixel shader that reconstructs the shading from L. posed by Toler-Franklin et al. [TFFR07] for manipulating The resizing factor r is equal to the ratio of the width of H natural images augmented with per-pixel surface normals. relative to that of L; resizing the framebuffer by a factor of They note the importance of accounting for foreshorten- r = 2 will thus reduce the pixel load by roughly a factor of ing when computing the distance between screen-space nor- 4. We next describe each of these passes in detail. mals. Following that work, we transform each normal vector (nx,ny,nz) by its z-component (nx/nz,ny/nz,1) before com- 2.1. Rendering L puting the Euclidean distance. The original pixel shader is used to render the scene to the The standard deviations σn and σz are important parame- low resolution buffer L. In addition to surface color, we also ters that determine the extent to which shading information store the depth and surface normal at each pixel (this is is shared between surface regions with different depths and similar to the G-buffer used in deferred shading [DWS∗88, orientations. Figure 1 illustrates the effect of these parame- ST90]). This information allows the second pass to consider ters at different resizing factors. Smaller values of σz limit discontinuities in the scene geometry when reconstructing the amount of blending across depth boundaries as can be the shading. Our current implementation packs this data into seen along the silhouette edges of the car. Smaller values of a single 16-bit RGBA render target (8-bit RGBA packed on σn limit the amount of blending across orientation bound- RG, 16-bit depth on B, and 8 bits for each of the normal’s x- aries like where the rear-view mirror meets the car’s body.
Recommended publications
  • Opengl Distilled / Paul Martz
    Page left blank intently OpenGL® Distilled By Paul Martz ............................................... Publisher: Addison Wesley Professional Pub Date: February 27, 2006 Print ISBN-10: 0-321-33679-8 Print ISBN-13: 978-0-321-33679-8 Pages: 304 Table of Contents | Inde OpenGL opens the door to the world of high-quality, high-performance 3D computer graphics. The preferred application programming interface for developing 3D applications, OpenGL is widely used in video game development, visuali,ation and simulation, CAD, virtual reality, modeling, and computer-generated animation. OpenGL® Distilled provides the fundamental information you need to start programming 3D graphics, from setting up an OpenGL development environment to creating realistic te tures and shadows. .ritten in an engaging, easy-to-follow style, this boo/ ma/es it easy to find the information you0re loo/ing for. 1ou0ll quic/ly learn the essential and most-often-used features of OpenGL 2.0, along with the best coding practices and troubleshooting tips. Topics include Drawing and rendering geometric data such as points, lines, and polygons Controlling color and lighting to create elegant graphics Creating and orienting views Increasing image realism with te ture mapping and shadows Improving rendering performance Preserving graphics integrity across platforms A companion .eb site includes complete source code e amples, color versions of special effects described in the boo/, and additional resources. Page left blank intently Table of contents: Chapter 6. Texture Mapping Copyright ............................................................... 4 Section 6.1. Using Texture Maps ........................... 138 Foreword ............................................................... 6 Section 6.2. Lighting and Shadows with Texture .. 155 Preface ................................................................... 7 Section 6.3. Debugging .......................................... 169 About the Book ....................................................
    [Show full text]
  • Real-Time Graphics Architecture P
    4/18/2007 Real-Time Graphics Architecture Lecture 4: Parallelism and Communication Kurt Akeley Pat Hanrahan http://graphics.stanford.edu/cs448-07-spring/ CS448 Lecture 4 Kurt Akeley, Pat Hanrahan, Spring 2007 Topics 1. Frame buffers 2. Types of parallelism 3. Communication patterns and requirements 4. Sorting classification for parallel rendering (with examples) CS448 Lecture 4 Kurt Akeley, Pat Hanrahan, Spring 2007 1 4/18/2007 Frame Buffers Raster vs. calligraphic Raster (image order) dominant choice Calligraphic (object order) Earliest choice (Sketchpad) E&S terminals in the 70s and 80s Works with light pens Scene complexity affects frame rate Monitors are expensive Still required for FAA simulation Increases absolute brightness of light points CS448 Lecture 4 Kurt Akeley, Pat Hanrahan, Spring 2007 2 4/18/2007 Frame buffer definitions What is a frame buffer? What can we learn by considering different definitions? CS448 Lecture 4 Kurt Akeley, Pat Hanrahan, Spring 2007 Frame buffer definition #1 Storage for commands that are executed to refresh the display Allows for raster or calligraphiccalligraphic display (e. g. Megatech) “Frame buffer” for calligraphic display is a “display list” OpenGL “render list”? Key point: frame buffer contents are interpreted Color mapping Image scaling, warping Window system (overlay, separate windows, …) Address Recalculation Pipeline CS448 Lecture 4 Kurt Akeley, Pat Hanrahan, Spring 2007 3 4/18/2007 Frame buffer definition #2 Image memory used to decouple the render frame rate from the display
    [Show full text]
  • Deconstructing Hardware Usage for General Purpose Computation on Gpus
    Deconstructing Hardware Usage for General Purpose Computation on GPUs Budyanto Himawan Manish Vachharajani Dept. of Computer Science Dept. of Electrical and Computer Engineering University of Colorado University of Colorado Boulder, CO 80309 Boulder, CO 80309 E-mail: {Budyanto.Himawan,manishv}@colorado.edu Abstract performance, in 2001, NVidia revolutionized the GPU by making it highly programmable [3]. Since then, the programmability of The high-programmability and numerous compute resources GPUs has steadily increased, although they are still not fully gen- on Graphics Processing Units (GPUs) have allowed researchers eral purpose. Since this time, there has been much research and ef- to dramatically accelerate many non-graphics applications. This fort in porting both graphics and non-graphics applications to use initial success has generated great interest in mapping applica- the parallelism inherent in GPUs. Much of this work has focused tions to GPUs. Accordingly, several works have focused on help- on presenting application developers with information on how to ing application developers rewrite their application kernels for the perform the non-trivial mapping of general purpose concepts to explicitly parallel but restricted GPU programming model. How- GPU hardware so that there is a good fit between the algorithm ever, there has been far less work that examines how these appli- and the GPU pipeline. cations actually utilize the underlying hardware. Less attention has been given to deconstructing how these gen- This paper focuses on deconstructing how General Purpose ap- eral purpose application use the graphics hardware itself. Nor has plications on GPUs (GPGPU applications) utilize the underlying much attention been given to examining how GPUs (or GPU-like GPU pipeline.
    [Show full text]
  • AMD Radeon E8860
    Components for AMD’s Embedded Radeon™ E8860 GPU INTRODUCTION The E8860 Embedded Radeon GPU available from CoreAVI is comprised of temperature screened GPUs, safety certi- fiable OpenGL®-based drivers, and safety certifiable GPU tools which have been pre-integrated and validated together to significantly de-risk the challenges typically faced when integrating hardware and software components. The plat- form is an off-the-shelf foundation upon which safety certifiable applications can be built with confidence. Figure 1: CoreAVI Support for E8860 GPU EXTENDED TEMPERATURE RANGE CoreAVI provides extended temperature versions of the E8860 GPU to facilitate its use in rugged embedded applications. CoreAVI functionally tests the E8860 over -40C Tj to +105 Tj, increasing the manufacturing yield for hardware suppliers while reducing supply delays to end customers. coreavi.com [email protected] Revision - 13Nov2020 1 E8860 GPU LONG TERM SUPPLY AND SUPPORT CoreAVI has provided consistent and dedicated support for the supply and use of the AMD embedded GPUs within the rugged Mil/Aero/Avionics market segment for over a decade. With the E8860, CoreAVI will continue that focused support to ensure that the software, hardware and long-life support are provided to meet the needs of customers’ system life cy- cles. CoreAVI has extensive environmentally controlled storage facilities which are used to store the GPUs supplied to the Mil/ Aero/Avionics marketplace, ensuring that a ready supply is available for the duration of any program. CoreAVI also provides the post Last Time Buy storage of GPUs and is often able to provide additional quantities of com- ponents when COTS hardware partners receive increased volume for existing products / systems requiring additional inventory.
    [Show full text]
  • The Opengl Framebuffer Object Extension
    TheThe OpenGLOpenGL FramebufferFramebuffer ObjectObject ExtensionExtension SimonSimon GreenGreen NVIDIANVIDIA CorporationCorporation OverviewOverview •• WhyWhy renderrender toto texture?texture? •• PP--bufferbuffer // ARBARB renderrender texturetexture reviewreview •• FramebufferFramebuffer objectobject extensionextension •• ExamplesExamples •• FutureFuture directionsdirections WhyWhy RenderRender ToTo Texture?Texture? • Allows results of rendering to framebuffer to be directly read as texture • Better performance – avoids copy from framebuffer to texture (glCopyTexSubImage2D) – uses less memory – only one copy of image – but driver may sometimes have to do copy internally • some hardware has separate texture and FB memory • different internal representations • Applications – dynamic textures – procedurals, reflections – multi-pass techniques – anti-aliasing, motion blur, depth of field – image processing effects (blurs etc.) – GPGPU – provides feedback loop WGL_ARB_pbufferWGL_ARB_pbuffer •• PixelPixel buffersbuffers •• DesignedDesigned forfor offoff--screenscreen renderingrendering – Similar to windows, but non-visible •• WindowWindow systemsystem specificspecific extensionextension •• SelectSelect fromfrom anan enumeratedenumerated listlist ofof availableavailable pixelpixel formatsformats usingusing – ChoosePixelFormat() – DescribePixelFormat() ProblemsProblems withwith PBuffersPBuffers • Each pbuffer usually has its own OpenGL context – (Assuming they have different pixel formats) – Can share texture objects, display lists between
    [Show full text]
  • Graphics Pipeline and Rasterization
    Graphics Pipeline & Rasterization Image removed due to copyright restrictions. MIT EECS 6.837 – Matusik 1 How Do We Render Interactively? • Use graphics hardware, via OpenGL or DirectX – OpenGL is multi-platform, DirectX is MS only OpenGL rendering Our ray tracer © Khronos Group. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/. 2 How Do We Render Interactively? • Use graphics hardware, via OpenGL or DirectX – OpenGL is multi-platform, DirectX is MS only OpenGL rendering Our ray tracer © Khronos Group. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/. • Most global effects available in ray tracing will be sacrificed for speed, but some can be approximated 3 Ray Casting vs. GPUs for Triangles Ray Casting For each pixel (ray) For each triangle Does ray hit triangle? Keep closest hit Scene primitives Pixel raster 4 Ray Casting vs. GPUs for Triangles Ray Casting GPU For each pixel (ray) For each triangle For each triangle For each pixel Does ray hit triangle? Does triangle cover pixel? Keep closest hit Keep closest hit Scene primitives Pixel raster Scene primitives Pixel raster 5 Ray Casting vs. GPUs for Triangles Ray Casting GPU For each pixel (ray) For each triangle For each triangle For each pixel Does ray hit triangle? Does triangle cover pixel? Keep closest hit Keep closest hit Scene primitives It’s just a different orderPixel raster of the loops!
    [Show full text]
  • Xengt: a Software Based Intel Graphics Virtualization Solution
    XenGT: a Software Based Intel Graphics Virtualization Solution Oct 22, 2013 Haitao Shan, [email protected] Kevin Tian, [email protected] Eddie Dong, [email protected] David Cowperthwaite, [email protected] Agenda • Background • Existing Arts • XenGT Architecture • Performance • Summary 2 Background Graphics Computing • Entertainment applications • Gaming, video playback, browser, etc. • General purpose windowing • Windows Aero, Compiz Fusion, etc • High performance computing • Computer aided designs, weather broadcast, etc. Same capability required, when above tasks are moved into VM 4 Graphics Virtualization • Performance vs. multiplexing • Consistent and rich user experience in all VMs • Share a single GPU among multiple VMs Client Rich Virtual Client Server VDI, transcoder, GPGPU Embedded Smartphone, tablet, IVI 5 Existing Arts Device Emulation • Only for legacy VGA cards • E.g. Cirrus logic VGA card • Limited graphics capability • 2D only • Optimizations on frame buffer operations • E.g. PV framebuffer • Impossible to emulate a modern GPU • Complexity • Poor performance 7 Split Driver Model • Frontend/Backend drivers • Forward OpenGL/DirectX API calls • Implementation specific for the level of forwarding • E.g. VMGL, VMware vGPU, Virgil • Hardware agnostic • Challenges on forwarding between host/guest graphics stacks • API compatibility • CPU overhead 8 Direct Pass-Through/SR-IOV • Best performance with direct pass-through • However no multiplexing 9 XenGT Architecture XenGT • A mediated pass-through solution
    [Show full text]
  • 20 Years of Opengl
    20 Years of OpenGL Kurt Akeley © Copyright Khronos Group, 2010 - Page 1 So many deprecations! • Application-generated object names • Depth texture mode • Color index mode • Texture wrap mode • SL versions 1.10 and 1.20 • Texture borders • Begin / End primitive specification • Automatic mipmap generation • Edge flags • Fixed-function fragment processing • Client vertex arrays • Alpha test • Rectangles • Accumulation buffers • Current raster position • Pixel copying • Two-sided color selection • Auxiliary color buffers • Non-sprite points • Context framebuffer size queries • Wide lines and line stipple • Evaluators • Quad and polygon primitives • Selection and feedback modes • Separate polygon draw mode • Display lists • Polygon stipple • Hints • Pixel transfer modes and operation • Attribute stacks • Pixel drawing • Unified text string • Bitmaps • Token names and queries • Legacy pixel formats © Copyright Khronos Group, 2010 - Page 2 Technology and culture © Copyright Khronos Group, 2010 - Page 3 Technology © Copyright Khronos Group, 2010 - Page 4 OpenGL is an architecture Blaauw/Brooks OpenGL SGI Indy/Indigo/InfiniteReality Different IBM 360 30/40/50/65/75 NVIDIA GeForce, ATI implementations Amdahl Radeon, … Code runs equivalently on Top-level goal Compatibility all implementations Conformance tests, … It’s an architecture, whether Carefully planned, though Intentional design it was planned or not . mistakes were made Can vary amount of No feature subsetting Configuration resource (e.g., memory) Config attributes (e.g., FB) Not a formal
    [Show full text]
  • PACKET 7 BOOKSTORE 433 Lecture 5 Dr W IBM OVERVIEW
    “PROCESSORS” and multi-processors Excerpt from Hennessey Computer Architecture book; edits by JT Wunderlich PhD Plus Dr W’s IBM Research & Development: JT Wunderlich PhD “PROCESSORS” Excerpt from Hennessey Computer Architecture book; edits by JT Wunderlich PhD Historical Perspective and Further 7.14 Reading There is a tremendous amount of history in multiprocessors; in this section we divide our discussion by both time period and architecture. We start with the SIMD SIMD=SinGle approach and the Illiac IV. We then turn to a short discussion of some other early experimental multiprocessors and progress to a discussion of some of the great Instruction, debates in parallel processing. Next we discuss the historical roots of the present multiprocessors and conclude by discussing recent advances. Multiple Data SIMD Computers: Attractive Idea, Many Attempts, No Lasting Successes The cost of a general multiprocessor is, however, very high and further design options were considered which would decrease the cost without seriously degrading the power or efficiency of the system. The options consist of recentralizing one of the three major components. Centralizing the [control unit] gives rise to the basic organization of [an] . array processor such as the Illiac IV. Bouknight, et al.[1972] The SIMD model was one of the earliest models of parallel computing, dating back to the first large-scale multiprocessor, the Illiac IV. The key idea in that multiprocessor, as in more recent SIMD multiprocessors, is to have a single instruc- tion that operates on many data items at once, using many functional units (see Figure 7.14.1). Although successful in pushing several technologies that proved useful in later projects, it failed as a computer.
    [Show full text]
  • PACKET 22 BOOKSTORE, TEXTBOOK CHAPTER Reading Graphics
    A.11 GRAPHICS CARDS, Historical Perspective (edited by J Wunderlich PhD in 2020) Graphics Pipeline Evolution 3D graphics pipeline hardware evolved from the large expensive systems of the early 1980s to small workstations and then to PC accelerators in the 1990s, to $X,000 graphics cards of the 2020’s During this period, three major transitions occurred: 1. Performance-leading graphics subsystems PRICE changed from $50,000 in 1980’s down to $200 in 1990’s, then up to $X,0000 in 2020’s. 2. PERFORMANCE increased from 50 million PIXELS PER SECOND in 1980’s to 1 billion pixels per second in 1990’’s and from 100,000 VERTICES PER SECOND to 10 million vertices per second in the 1990’s. In the 2020’s performance is measured more in FRAMES PER SECOND (FPS) 3. Hardware RENDERING evolved from WIREFRAME to FILLED POLYGONS, to FULL- SCENE TEXTURE MAPPING Fixed-Function Graphics Pipelines Throughout the early evolution, graphics hardware was configurable, but not programmable by the application developer. With each generation, incremental improvements were offered. But developers were growing more sophisticated and asking for more new features than could be reasonably offered as built-in fixed functions. The NVIDIA GeForce 3, described by Lindholm, et al. [2001], took the first step toward true general shader programmability. It exposed to the application developer what had been the private internal instruction set of the floating-point vertex engine. This coincided with the release of Microsoft’s DirectX 8 and OpenGL’s vertex shader extensions. Later GPUs, at the time of DirectX 9, extended general programmability and floating point capability to the pixel fragment stage, and made texture available at the vertex stage.
    [Show full text]
  • Intel Embedded Graphics Drivers, EFI Video Driver, and Video BIOS V10.4
    Intel® Embedded Graphics Drivers, EFI Video Driver, and Video BIOS v10.4 User’s Guide April 2011 Document Number: 274041-032US INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined.” Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
    [Show full text]
  • Interactive Visualization of Large-Scale Architectural Models Over the Grid Strolling in Tang Chang’An City
    Interactive Visualization of Large-Scale Architectural Models over the Grid Strolling in Tang Chang’an City XU Shuhong1, HENG Chye Kiang2, SUBRAMANIAM Ganesan1, HO Quoc Thuan1, KHOO Boon Tat1 and HUANG Yan2 1 Institute of High Performance Computing, Singapore 2 Department of Architecture, National University of Singapore Keywords: remote visualization, grid-enabled visualization, large-scale architectural models, virtual heritage Abstract: Virtual reconstruction of the ancient Chinese Chang’an city has been continued for ten years at the National University of Singapore. Motivated by sharing this grand city with people who are geographically distant and equipped with normal personal computers, this paper presents a practical Grid-enabled visualization infrastructure that is suitable for interactive visualization of large-scale architectural models. The underlying Grid services, such as information service, visualization planner and execution container etc, are developed according to the OGSA standard. To tackle the critical problem of Grid visualization, i.e. data size and network bandwidth, a multi-stage data compression approach is deployed and the corresponding data pre-processing, rendering and remote display issues are systematically addressed. 1 INTRODUCTION Chang’an, meaning long-lasting peace, was the capital of China’s Tang dynasty from 618 to 907 AD. At its peak, it had a population of about one million. Measuring 9.7 by 8.6 kilometres, the city’s architecture inspired the planning of many capital cities in East Asia such as Heijo-kyo and Heian-kyo in Japan in the 8th century, and imperial Chinese cities like Beijing of the Ming and Qing dynasties. To bring this architectural miracle back to life, a team led by Professor Heng Chye Kiang at the National University of Singapore (NUS) has conducted extensive research since the middle of 90s.
    [Show full text]