DOCSLIB.ORG

La Pile Graphique Linux

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

La pile graphique Linux Jérôme Pouiller <[email protected]> Programme Rappels sur les OS Historique du protocole X (la préhistoire) Accélération 2D Accélération des vidéos Accélération 3D des clients Drivers graphiques 3D Accélération du bureau toolkits graphiques Sysmic - J. Pouiller La pile graphique Linux 2 / 29 Rappel sur la mémoire Les CPU modernes intègrent un composant appelé MMU (Memory Management Unit): Unité de translation d’adresses mémoire On parle d’adresses physiques et virtuelles Lorsque le MMU est actif (cas nominal), toutes les adresses du code assembleur sont des adresses virtuelles Il est possible de configurer le MMU avec une instruction spéciale et en lui donnant un pointeur sur un tableau (dans la pratique, il s’agit plutôt d’un arbre) associant les adresses physiques et les adresses virtuelles Sysmic - J. Pouiller La pile graphique Linux 3 / 29 Drivers en espace utilisateur mmap permet d’allouer des plage d’adresses virtuelles Elles sont associées à : Mémoire anonyme (= allocation de mémoire) Fichiers (en intégralité ou en partie) /dev/mem représente la mémoire physique Utiliser mmap avec /dev/mem revient à accéder directement aux adresses physiques Avec iopl et ioperm, il est possible à un programme utilisateur d’accéder au ioport (inb, outb, ...) XFree86 est basé sur ce modèle Sysmic - J. Pouiller La pile graphique Linux 4 / 29 Fonctionnement de XFree86 Permet d’être portable entre les différents OS X gère aussi l’accès partagé aux périphériques d’entrées (souris, clavier, ’ecran tactile) C’est normalement le rôle de l’OS de gérer les accès aux périphériques Accéder directement aux périphériques peut rentrer en conflit avec la gestion de l’OS (plantage) Au fur et a mesure du temps, on a porté des morceaux des pilotes de X dans le noyau : Au lieu de travailler sur /dev/mem, on travaille sur /dev/nvidia. Sysmic - J. Pouiller La pile graphique Linux 5 / 29 Glossaire X11R6.X, X11R7.X : Xserver + Xlib + applications X + documentation Xserver : Le serveur en lui même. Il est divisé en deux parties : DDX : Device Dependent X : Xfree86/Xorg, Xnest, KDrive/TinyX, XWin, Darwin, xvfb, xgl, etc... un DDX peut avoir plusieurs drivers. chaque driver peut generer une binaire ou un module. Parfois, on nomme "Xserver" la partie DDX. DIX : Device Independent X : Le reste : gestion des protocoles clients, gestion des entrées, etc... Xorg : Fork de XFree86 pour des raison de licence (Xfree86 4.4, 2003) XAA : Différentes API interne à Xorg-Xserver pour travailler avec des drivers noyau et offrir un peu d’accélération (XFree86 3.3, 1997) Sysmic - J. Pouiller La pile graphique Linux 6 / 29 Coté utilisateur Sysmic - J. Pouiller La pile graphique Linux 7 / 29 Coté utilisateur Protocole X : Protocole de haut niveau Lent Sysmic - J. Pouiller La pile graphique Linux 8 / 29 Accélération 2D L’accélération 2D est toujours basé sur le même principe : Donner un buffer de mémoire au client sur lequel il peut écrire directement (un framebuffer). Le buffer est copié vers la carte graphique par DMA. Il est possible de demander à la carte graphique d’altérer différents buffers : positionnement sur l’écran, duplication, composition, etc... /dev/fb : Framebuffer fourni par le noyau. Peut-être implémenté par divers drivers Xrender : Extension du protocole X pour permettre l’accès direct a des framebuffer (Xfree86 4.0, 2000) EXA/UXA/SNA : Amélioration de XAA pour permettre une meilleure intégration de Xrender KAA : Idem EXA mais pour KDrive/tinyX Sysmic - J. Pouiller La pile graphique Linux 9 / 29 Le framebuffer noyau /dev/fb : L’interface framebuffer fournie par le noyau. Il existe un driver Xserver-XFree86 s’appuyant sur /dev/fb Directfb : Bibliothèque fournissant une abstraction entre /dev/fb et les différentes entrées. Le framebuffer ne peut être utilisé que par une appliction à la fois. Le patch noyau linux-fusion ajoute le support multi-application au framebuffer. Il faut utiliser DirectFB-fusion pour en profiter. Les toolkits courants ont un backend DirectFB ou /dev/fb. Certain driver peuvent ajouter des extensions plus ou moins documentées à /dev/fb Sysmic - J. Pouiller La pile graphique Linux 10 / 29 Accélération 2D/Video Les vidéos peuvent être optimisée d’une manière particulière. Il est possible de remplir une série de buffer et de demander à la carte graphique de passer automatiquement d’un buffer à l’autre. Xv : Extension permettant cette optimisation Aussi basé sur XAA/EXA Généralement, si Xrender est présent, Xv l’est aussi. Sysmic - J. Pouiller La pile graphique Linux 11 / 29 Accélération du décodage video XvMC/XvBA/VDPAU/VA-API : Extension permettant d’effectuer une partie du décodage de la vidéo sur la carte graphique. VA-API s’est imposé. Les bibliothèque de lecture courrant utilise normalement ces extensions : mplayer, gstreamer, etc... Dans l’embarqué, certains drivers ne respectent pas ces API. Les fournisseurs de chipsets proposent alors des versions patchées de mplayer/gstreamer (ou parfois des players maison). Se méfier. Sysmic - J. Pouiller La pile graphique Linux 12 / 29 Autres extensions X Gestion physique des écrans : xrandr Gestion du clavier : xkbd Gestion multi-écrans : xinerama Gestion multi-pointeurs : MPX Gestion de fenêtres non carrées : xshape Gestion du curseur : xcursor Gestion des périphériques d’entrée modernes : xi (Input eXtention) Accès exclusif à l’écran (pour les jeux) : DGA Et d’autres : xdmcp, xprint, xft (fonts), xaccess, etc... Sysmic - J. Pouiller La pile graphique Linux 13 / 29 Accélération 3D SGI/Khronos a spécifié plusieurs API pour communiquer avec les cartes graphiques : OpenGL (1 à 4), GLU, OpenGLESv1, OpenGLESv2, OpenCL, OpenVG, .... SGI/Khronos a interdit à la communauté de réutiliser le nom OpenGL dans l’implémentation. L’implémentation s’appelle donc Mesa3D (contient libGL, libEGL, libGLES) Afin d’ouvrir une fenêtre OpenGL, il est nécessaire de s’interfacer avec X : glx : extension de X wgl : API MS Windows équivalente à glx EGL : Api normalisée par SGI/Khronos (afin d’éviter de refaire l’erreur de glx/wgl). Portable : Xorg, Windows, /dev/fb, DirectFB... Fonctionne avec GLES, OpenVG Sysmic - J. Pouiller La pile graphique Linux 14 / 29 Accélération 3D Mesa3D a besoin de s’interfacer avec le hardware. Il doit partager des ressources avec le serveur X. Mesa s’intègre par l’intermédiaire d’une interface interne appelé DRI (Direct Rendering Infrastructure). Le DRI s’appuie ensuite généralement sur un driver se trouvant dans le noyau. Ces drivers implémentent l’interface DRM (Direct Rendering Manager) Mesa3D fourni un moteur software capable de fournir les fonctions OpenGL non implémentées par le Hardware. Sysmic - J. Pouiller La pile graphique Linux 15 / 29 Accélélration 3D Sysmic - J. Pouiller La pile graphique Linux 16 / 29 Accélération 3D Afin de gérer les différents drivers et les différentes API, Mesa3D se repose sur une architecture appelée Gallium3D : Sysmic - J. Pouiller La pile graphique Linux 17 / 29 Accélération 3D Sur framebuffer : Sur /dev/fb, l’API ne permet pas d’accéder à OpenGL (pas de GLX). Certains drivers propriétaires permettent d’avoir un accès à EGL en utilisant des extensions non standards DirectFB propose des API pour accéder à OpenGL/EGL ... fortement dépendentes du driver ... s’appuie sur les DRM (EGL uniquement) Travail récent Sysmic - J. Pouiller La pile graphique Linux 18 / 29 Drivers propriétaire Un driver propriétaire doit fournir : Une implémentation de libGL, libGLES, etc... Du coup, il remplace Mesa3D Un driver Xserver et en particulier pour Xrender Un driver pour la 2D (/dev/fb) Un DRI pour Xorg-Xserver. Toutefois, le driver peut ne pas garder la notion de DRI dans son architecture Un driver pour la 3D (DRM). Notons que l’interface DRM n’est utilisé que par le DRI. Du coup, les constructeurs se permettent de ne pas respecter les interfaces standards sur ces deux composants. Sysmic - J. Pouiller La pile graphique Linux 19 / 29 Dans l’embarqué Pas différent Choix large Dépendent de l’implémentation du driver par le fournisseur Attention au restriction sur l’usage et la publication Généralement, fournissent : un driver exposant un /dev/fb et une interface pour la 3D (équivalent DRM) un driver pour Xorg-Xserver implémentant Xrender, EGL et/ou GLX une implémentation de libEGL, libGLES, libOpenVG la Possibilité d’utiliser ces bibliothèques sur /dev/fb et/ou DirectFB Sysmic - J. Pouiller La pile graphique Linux 20 / 29 Dans l’embarqué Exemples : Chip Driver libre Exemples de chipsets Imagination Tech- Apple, Intel Atom (GMA 500/GMA nologies PowerVR 600), Texas Instrument OMAP (PandaBoard), ... ARM Mali Lima Allwinner Sunxi, Samsung Exynos Qualcomm Adreno Freedreno Freescale i.mx51/i.mx53 (AMD), Qualcomm Snapdragon Vivante Etnaviv Freescale imx6 Broadcom Video- Broadcom BCMx (Raspberry Pi) Core Nvidia Tegra Grate Nvidia Tegra Nvidia Nouveau Nvidia Geforce AMD Radeon Radeon AMD Radeon Sysmic - J. Pouiller La pile graphique Linux 21 / 29 L’accélération du bureau Possible d’accélérer les application, mais pas encore le bureau dans son ensemble Xgl : DDX s’appuyant sur une fenêtre OpenGL. Chaque fenêtre est rendue dans une texture. Il est alors possible d’appliquer des effets sur ces textures Aiglx : Remplace Xgl (Xgl était critiqué pour son organisation). Les fenêtres sont rendues sur des textures et les appels à GLX sont proxyfiés par AIGLX. Permet en outres aux application distante de faire du rendu OpenGL. Xcompose et Xdamage : extension du protocole X permettant à une application de contrôler l’affichage final des fenêtres (compiz, berryl, kwin, etc...). Sysmic - J. Pouiller La pile graphique Linux 22 / 29 Accélération 3D Sysmic - J. Pouiller La pile graphique Linux 23 / 29 Wayland L’architecture de Xserver date des années 80. L’informatique a beaucoup changé. Xserver est une succession d’extensions et de modifications Wayland est une nouvelle API faisant table rase du passé. Basée sur GLes, EGL, evdev. Wayland est basé sur des buffer dans lesquels les applications font des rendus 2D (comme Xrender) ou 3D (comme GLX).
Recommended publications
  • THINC: a Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices

    THINC: a Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices

    THINC: A Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices Ricardo A. Baratto Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2011 c 2011 Ricardo A. Baratto This work may be used in accordance with Creative Commons, Attribution-NonCommercial-NoDerivs License. For more information about that license, see http://creativecommons.org/licenses/by-nc-nd/3.0/. For other uses, please contact the author. ABSTRACT THINC: A Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices Ricardo A. Baratto THINC is a new virtual and remote display architecture for desktop computing. It has been designed to address the limitations and performance shortcomings of existing remote display technology, and to provide a building block around which novel desktop architectures can be built. THINC is architected around the notion of a virtual display device driver, a software-only component that behaves like a traditional device driver, but instead of managing specific hardware, enables desktop input and output to be intercepted, manipulated, and redirected at will. On top of this architecture, THINC introduces a simple, low-level, device-independent representation of display changes, and a number of novel optimizations and techniques to perform efficient interception and redirection of display output. This dissertation presents the design and implementation of THINC. It also intro- duces a number of novel systems which build upon THINC's architecture to provide new and improved desktop computing services. The contributions of this dissertation are as follows: • A high performance remote display system for LAN and WAN environments.
  • Ati Driver Freebsd

    Ati Driver Freebsd

    Ati driver freebsd Hey, I`m new to teh the bsd *BSD world and just installed Freebsd FreeBSD. Only thing missing is my video driver. ATI Radeon X How to Solved - Switch between ATI and VESA drivers? If you want to automatically load a video driver at boot time, we recommend to do it from /etc/:Radeon​: ​ It allows the use of newer xfvideo-ati drivers and AMD GPUs. This project started in January Initial radeon code comes from Linux. EndSection DESCRIPTION radeon is an Xorg driver for ATI/AMD RADEON-based video cards with the following features: o Full support for 8-, , and. This package contains the xfvideo-ati driver. xdrivers/drm-kmod: Port for the DRM kernel drivers for FreeBSD This port. If I boot X11 with no or with ati driver, the system stops responding, although cursor continues to follow mouse movements. (I suppose. To all those concerned, I have read that FreeBSD would be supported by the latest graphic card drivers, which was also confirmed by. I bought an expensive ATI card when they announced they'll go Note that AMD doesn't provide a driver for FreeBSD, so you'll be using the. We now know for sure that FreeBSD will ship with a kernel mode-setting driver for supporting open-source AMD Radeon graphics with its. AMD tech support has allegedly confirmed that Catalyst is being ported to FreeBSD. A Phoronix reader pointed out this thread. I am not sure that FreeBSD will fully support this card. The Xorg version for FreeBSD is and the ATI driver used is version The reason is, AMD/ATI doesn't support FreeBSD, and you have to resort to the sucky open source drivers.
  • OM-Cube Project

    OM-Cube Project

    OM-Cube project V. Hiribarren, N. Marchand, N. Talfer [email protected] - [email protected] - [email protected] Abstract. The OM-Cube project is composed of several components like a minimal operating system, a multi- media player, a LCD display and an infra-red controller. They should be chosen to fit the hardware of an em- bedded system. Several other similar projects can provide information on the software that can be chosen. This paper aims to examine the different available tools to build the OM-Multimedia machine. The main purpose is to explore different ways to build an embedded system that fits the hardware and fulfills the project. 1 A Minimal Operating System The operating system is the core of the embedded system, and therefore should be chosen with care. Because of its popu- larity, a Linux based system seems the best choice, but other open systems exist and should be considered. After having elected a system, all unnecessary components may be removed to get a minimal operating system. 1.1 A Linux Operating System Using a Linux kernel has several advantages. As it’s a popular kernel, many drivers and documentation are available. Linux is an open source kernel; therefore it enables anyone to modify its sources and to recompile it. Using Linux in an embedded system requires adapting the kernel to the hardware and to the system needs. A simple method for building a Linux embed- ded system is to create a partition on a development host and to mount it on a temporary mount point. This partition is filled as one goes along and then, the final distribution is put on the target host [Fich02] [LFS].
  • Institutionen För Datavetenskap Department of Computer and Information Science

    Institutionen För Datavetenskap Department of Computer and Information Science

    Institutionen för datavetenskap Department of Computer and Information Science Final thesis Simulation of Set-top box Components on an X86 Architecture by Implementing a Hardware Abstraction Layer by Faruk Emre Sahin Muhammad Salman Khan LITH-IDA-EX—10/050--SE 2010-12-25 Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping Linköping University Department of Computer and Information Science Final Thesis Simulation of Set-top box Components on an X86 Architecture by Implementing a Hardware Abstraction Layer by Faruk Emre Sahin Muhammad Salman Khan LITH-IDA-EX—10/050—SE 2010-12-25 Supervisors: Fredrik Hallenberg, Tomas Taleus R&D at Motorola (Linköping) Examiner: Prof. Dr. Christoph Kessler Dept. Of Computer and Information Science at Linköpings universitet Abstract The KreaTV Application Development Kit (ADK) product of Motorola en- ables application developers to create high level applications and browser plugins for the IPSTB system. As a result, customers will reduce develop- ment time, cost and supplier dependency. The main goal of this thesis was to port this platform to a standard Linux PC to make it easy to trace the bugs and debug the code. This work has been done by implementing a hardware abstraction layer(HAL)for Linux Operating System. HAL encapsulates the hardware dependent code and HAL APIs provide an abstraction of underlying architecture to the oper- ating system and to application software. So, the embedded platform can be emulated on a standard Linux PC by implementing a HAL for it. We have successfully built the basic building blocks of HAL with some performance degradation.
  • Openbricks Embedded Linux Framework - User Manual I

    Openbricks Embedded Linux Framework - User Manual I

    OpenBricks Embedded Linux Framework - User Manual i OpenBricks Embedded Linux Framework - User Manual OpenBricks Embedded Linux Framework - User Manual ii Contents 1 OpenBricks Introduction 1 1.1 What is it ?......................................................1 1.2 Who is it for ?.....................................................1 1.3 Which hardware is supported ?............................................1 1.4 What does the software offer ?............................................1 1.5 Who’s using it ?....................................................1 2 List of supported features 2 2.1 Key Features.....................................................2 2.2 Applicative Toolkits..................................................2 2.3 Graphic Extensions..................................................2 2.4 Video Extensions...................................................3 2.5 Audio Extensions...................................................3 2.6 Media Players.....................................................3 2.7 Key Audio/Video Profiles...............................................3 2.8 Networking Features.................................................3 2.9 Supported Filesystems................................................4 2.10 Toolchain Features..................................................4 3 OpenBricks Supported Platforms 5 3.1 Supported Hardware Architectures..........................................5 3.2 Available Platforms..................................................5 3.3 Certified Platforms..................................................7
  • The Linux Graphics Stack Attributions

    The Linux Graphics Stack Attributions

    I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions Introduction to GPUs and to the Linux Graphics Stack Martin Peres CC By-SA 3.0 Nouveau developer Ph.D. student at LaBRI November 26, 2012 1 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview Outline 1 I - Hardware : Anatomy of a GPU General overview Driving screens Host < − > GPU communication 2 II - Host : The Linux graphics stack General overview DRM and libdrm Mesa X11 Wayland X11 vs Wayland 3 Attributions Attributions 2 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview General overview of a modern GPU's functions Display content on a screen Accelerate 2D operations Accelerate 3D operations Decode videos Accelerate scientific calculations 3 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview CPU Clock Front-side Graphics Generator bus card slot Chipset Memory Slots High-speed graphics bus (AGP or PCI Northbridge Memory Express) bus (memory controller hub) Internal Bus PCI Bus Onboard Southbridge graphics PCI (I/O controller controller Bus hub) IDE SATA USB Cables and Ethernet ports leading Audio Codec CMOS Memory off-board PCI Slots LPC Bus Super I/O Serial Port Parallel Port Flash ROM Floppy Disk Keyboard (BIOS) Mouse 4 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview Hardware architecture GPU: Where all the calculations are made VRAM: Stores
  • Audio Video Graphics Working Group Session

    Audio Video Graphics Working Group Session

    Audio Video Graphics Working Group Session San Jose meeting Pieter van de Meulen WG chair 26 January, 2005 CE Linux Forum Technical Conference 1 AVG WG – todays objective: Audio Video 2D 3D Renesas, Mitsubishi, Conexant DirectFB Philips, Samsung UH API P hilips Multi-FB …. OpenGL …. …. …. 26 January, 2005 CE Linux Forum Technical Conference 2 Recall: 25th/26th Presentations • DirectFB - Dennis Oliver Kropp; Convergence ● http://www.directfb.org/ • OpenGL ES, OpenVG and OpenMAX - Ed Plowman; ARM ● http://www.khronos.org/ • Graphics APIS for Linux - Matsubara, Hagiwara, Hisao Munakata; Renesas • Creating GTK+ based UI's for embedded devices - Markku Ursin, Movial ● http://www.gtk.org/ • Linux DVB - Michael Hunold; Convergence ● http://www.linuxtv.org/ • UHAPI (AV streaming) tutorial - John Vugts; Philips/Samsung ● http://www.uhapi.org/ 26 January, 2005 CE Linux Forum Technical Conference 3 Recall: Jan. 25th Demos • FB (Multi-framebuffer) ● Philips: PNX8550 running Linux; dual framebuffer and AV accel. • DirectFB ● Conexant: DVD processor running CELF Linux with DirectFB. ● Mitsubishi: ARIB plane model emulated on DirectFB window system ● Mitsubishi: MPEG4 Player (via GTK+) running on Renesas SH-4 ● Renesas: GTK+ and GUI without X11 • UHAPI (AV streaming): ● Philips open source demo on PC • DTV ● Toshiba America/Europe: DTV reference solution and Home Gateway. • 3D graphics ●Renesas: demo by SI-Electronics on SH-4 and Power VR ●Pioneer: OpenGL 26 January, 2005 CE Linux Forum Technical Conference 4 Linux APIs (2004/6 status) & CCEELLFF VV11..00
  • Intel Embedded Graphics Drivers, EFI Video Driver, and Video BIOS V10.4

    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.
  • Programmable Image-Based Light Capture for Previsualization

    Programmable Image-Based Light Capture for Previsualization

    ii Abstract Previsualization is a class of techniques for creating approximate previews of a movie sequence in order to visualize a scene prior to shooting it on the set. Often these techniques are used to convey the artistic direction of the story in terms of cinematic elements, such as camera movement, angle, lighting, dialogue, and char- acter motion. Essentially, a movie director uses previsualization (previs) to convey movie visuals as he sees them in his ”minds-eye”. Traditional methods for previs include hand-drawn sketches, Storyboards, scaled models, and photographs, which are created by artists to convey how a scene or character might look or move. A recent trend has been to use 3D graphics applications such as video game engines to perform previs, which is called 3D previs. This type of previs is generally used prior to shooting a scene in order to choreograph camera or character movements. To visualize a scene while being recorded on-set, directors and cinematographers use a technique called On-set previs, which provides a real-time view with little to no processing. Other types of previs, such as Technical previs, emphasize accurately capturing scene properties but lack any interactive manipulation and are usually employed by visual effects crews and not for cinematographers or directors. This dissertation’s focus is on creating a new method for interactive visualization that will automatically capture the on-set lighting and provide interactive manipulation of cinematic elements to facilitate the movie maker’s artistic expression, validate cine- matic choices, and provide guidance to production crews. Our method will overcome the drawbacks of the all previous previs methods by combining photorealistic ren- dering with accurately captured scene details, which is interactively displayed on a mobile capture and rendering platform.
  • Opengl and the Linux Desktop LIFE in 3D New Technologies Will Change the Way You View the Objects on Your Linux Desktop

    Opengl and the Linux Desktop LIFE in 3D New Technologies Will Change the Way You View the Objects on Your Linux Desktop

    The Future of Linux Graphics COVER STORY OpenGL and the Linux desktop LIFE IN 3D New technologies will change the way you view the objects on your Linux desktop. BY JOE CASAD he X graphics system has been at antiquated design of the X system is not, specification originally created by Silicon the heart of the Unix GUI desktop on its own, flexible enough to support Graphics. The OpenGL specification pro- Tsince 1984. Of course, its hori- this kind of performance. vides a standard for vendors to create zons expanded slowly. In the early years, In the Linux world, wherever you find graphics programming interfaces. The no one knew they even needed a graph- a very big and intriguing question, you purpose of OpenGL is to provide a single ics subsystem, and if anyone did venture can bet that someone out there is work- interface that gives graphics programs a out to try X with one of the few applica- ing on the answer. A solution to the wor- standard way of talking to graphics hard- tions that supported it, they needed to ries of the restless graphics developers is ware. One of the reasons why OpenGL be ready for late nights of tinkering. converging now around the emergence is necessary is that graphics hardware But the X system kept getting better, of two very important developments: vendors are busy with their own experi- and the X protocol, with its surrounding • Extensions to X that offer increased ments to deliver richer graphics and bet- technologies, served a key role in the flexibility and shortcuts around some ter performance to their customers.
  • Directfb Internals Internals

    Directfb Internals Internals

    DirectFB Internals --ThinThings You Need to Know to Write Your DirectFBgfxdriver TakanariHayama, HisaoMunakata and Denis Oliver Kropp 1 What is DirectFB?DirectFB? Thin Graphics Library – Light weight and small footprint (< 700KB Library for SH4) – Not server/client model like X11 Hardware Abstraction Layer for Hardware Graphics Acceleration – Anyygthing not supp ppyorted by Hardware still su ppypported by software, i.e. utilize hardware where possible Multi-process support And others, e.g. build-in Window Manager etc. 15-17 April, 2008 ELC 2008 2 The First Embedded Chip Support by the Mainline DirectFB – Renesas SH7722 15-17 April, 2008 ELC 2008 3 df_andi and SawMan running on SH7722 15-17 April, 2008 ELC 2008 4 DirectFB Software Architecture for Renesas SH4 Platform Applications Direct FB gfxdriver for system module – Renesas’s Platform devmem Existing Code Linux Kernel Kernel Module Custom Code Video Memory and Hardware Accelerator Hardware Hardware 15-17 April, 2008 ELC 2008 5 Important Terms in DirectFB Layers – Represents independent graphics buffers. Most of embedded devices have more than one layer. They get layered with appropriate alpha blending by hardware, and displayed. Surface – Reserved memory region to hold pixel data. Drawing and blitting operation in DirectFB is performed from/to surfaces. Memory of surfaces could be allocated from video memory or system memory depending on the given constraints. Primary Surface – Special s urface that represents frame bu ffer of particu lar lay er. If the primary surface is single buffered, any operation to this primary surface is directly visible to the screen. 15-17 April, 2008 ELC 2008 6 Concept of Layers Each represents layer On the screen they are layered.
  • A Study on the Use of Opengl in Window Systems

    A Study on the Use of Opengl in Window Systems

    Master Thesis Computer Science Thesis no: MCS-2004:03 March 2004 A study on the use of OpenGL in window systems Johan Persson Department of Software Engineering and Computer Science Blekinge Institute of Technology Box 520 SE - 372 25 Ronneby Sweden This thesis is submitted to the Department of Software Engineering and Computer Science at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author: Johan Persson E-mail: [email protected] University advisor: Bj¨orn T¨ornqvist Department of Software Engineering and Computer Science Department of Software Engineering and Computer Science Internet : http://www.bth.se/ipd Blekinge Institute of Technology Phone : +46 457 38 50 00 Box 520 Fax : + 46 457 271 25 SE - 372 25 Ronneby Sweden Abstract OpenGL is getting used more in window system as a way of improving performance and enabling new functionality. Examples of two systems using different approaches of how OpenGL is being used are Quartz Extreme and Fresco. Quartz Extreme uses window composition which assures fast redisplay and Fresco on the other hand uses a structured graphics approach which utilises OpenGL on a much lower level compared to Quartz Extreme which operates at a window level. Fresco’s way brings great flexibility and an ability to mix 2D and 3D-objects on the desktop. But each of the approaches has its problems; Quartz extreme requires a large amount of memory for buffering of the window contents and Fresco has performance problems when redisplaying complex structures.