From: Sam Moore Date: Tue, 21 Oct 2014 08:11:15 +0000 (+0800) Subject: Commit things X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=ae8d5f837db032eb4d9e9666f5026fab7e3e8e4a;p=ipdf%2Fsam.git Commit things --- diff --git a/chapters/Background.tex b/chapters/Background.tex index 6a7b3a5..67d1cd3 100644 --- a/chapters/Background.tex +++ b/chapters/Background.tex @@ -9,7 +9,8 @@ \section{Coordinate Systems and Transformations} \input{chapters/Background/CoordinateSystems} \section{Precision Specified by Document Standards} -\input{chapters/Background/Standards} + +\input{chapters/Background/Standards/Precision} diff --git a/chapters/Background/CoordinateSystems.tex b/chapters/Background/CoordinateSystems.tex index 3a61cb3..ab3fbcd 100644 --- a/chapters/Background/CoordinateSystems.tex +++ b/chapters/Background/CoordinateSystems.tex @@ -1,53 +1,51 @@ Basic vector primitives composed of B{\'e}ziers may be rendered using only integer operations, once the starting and ending positions are rounded to the nearest pixel. -However, a complete document will contain many such primitives which in general cannot all be shown on a display at once. A ``View'' rectangle can be defined to represent the size of the display relative to the document. To interact with the document a user can change this view through scaling or translating with the mouse\cite{}. +However, a complete document will contain many such primitives which in general cannot all be shown on a display at once. A ``View'' rectangle can be defined to represent the size of the display relative to the document. To interact with the document a user can change this view through scaling or translating with the mouse. -Primitives which are contained within the view rectangle will be visible on the display. This involves the transformation from coordinates within the document to relative coordinates within the view rectangle as illustrated in Figure \ref{}. A point $(X,Y)$ in the document will transform to a point $(x,y)$ in the view by: +Primitives which are contained within the view rectangle will be visible on the display. This involves the transformation from coordinates within the document to relative coordinates within the view rectangle as illustrated in Figure \ref{view_transformation_minimal.pdf}. A point $(X,Y)$ in the document will transform to a point $(S_X,S_Y)$ in the display by: \begin{align} - X = \frac{x - v_x}{v_w} &\quad\quad Y = \frac{y - v_y}{v_h}\label{view-transformation} + S_X = \frac{X - V_x}{V_w} &\quad\quad S_Y = \frac{Y - V_y}{V_h}\label{view-transformation} \end{align} -Where $(v_x,v_y)$ are the coordinates of the top left corner and $(v_w,v_h)$ are the dimensions of the view rectangle. +Where $(V_x,V_y)$ are the coordinates of the top left corner and $(V_w,V_h)$ are the dimensions of the view rectangle. -The transformation may also be written as a 3x3 matrix $\matx{V}$ if we introduce a third coordinate $Z = 1$ +The transformation may also be written as a 3x3 matrix $\matx{V}$ if we introduce a third coordinate $z = 1$ \begin{align} - \matx{X} &= \matx{V} \matx{x} \\ - \left( \begin{array}{c} X \\ Y \\ 1 \end{array}\right) &= + \left( \begin{array}{c} S_X \\ S_Y \\ 1 \end{array}\right) &= \left( \begin{array}{ccc} - \frac{1}{v_w} & 0 & \frac{v_x}{v_w} \\ - 0 & \frac{1}{v_h} & \frac{v_y}{v_h} \\ + \frac{1}{V_w} & 0 & \frac{V_x}{V_w} \\ + 0 & \frac{1}{V_h} & \frac{V_y}{V_h} \\ 0 & 0 & 1 \end{array}\right) - \left( \begin{array}{c} x \\ y \\ 1 \end{array}\right)\label{view-transformation-matrix} + \left( \begin{array}{c} X \\ Y \\ 1 \end{array}\right)\label{view-transformation-matrix} \end{align} +\begin{figure}[H] + \centering + \includegraphics[width=0.7\textwidth]{figures/view_transformation_minimal.pdf} + \caption{Illustration of view transformation \eqref{view-transformation}}\label{view_transformation_minimal.pdf} +\end{figure} + +\subsection{View Transformations} Moving the mouse\footnote{or on a touch screen, swiping the screen} by a distance $(\Delta x, \Delta y)$ relative to the size of the view should translate it by the same amount\cite{}: \begin{align} - v_x \to v_x + \Delta x \\ - v_y \to v_y + \Delta y + V_x \to V_x + \Delta x \\ + V_y \to V_y + \Delta y \end{align} The document can be scaled by a factor of $s$ about a point $(x_0,y_0)$ specified relative to the view (such as the position of the mouse cursor)\cite{}: \begin{align} - v_x \to v_x + x_0 v_w(1 - s) \\ - v_y \to v_y + y_0 v_h(1 - s) \\ - v_w \to s v_w \\ - v_h \to s v_h + V_x \to V_x + x_0 V_w(1 - s) \\ + V_y \to V_y + y_0 V_h(1 - s) \\ + V_w \to s V_w \\ + V_h \to s V_h \end{align} The effect of this transformation is that, measured relative to the view rectangle, the distance of primitives with coordinates $(x, y)$ to the point $(x_0, y_0)$ will decrease by a factor of $s$. For $s < 1$ the operation is ``zooming out'' and for $s > 1$, ``zooming in''. -{\bf TODO} -\begin{itemize} - \item Intermediate coordinate systems... - \item Write Matrix operations properly - \item Link with the results where applying \eqref{view-transformation} directly leads to disaster - \item This is because for $v_w << 1$, an error of $1 ulp$ in $x - v_x$ is comparable with $v_w$, ie: Can increase to the order of the size of the display (or more) -\end{itemize} - %TODO List % Mention that these transformations affect precision more than eg: drawing a line % Discuss floating point errors that could occur? diff --git a/chapters/Background/FixedPoint.tex b/chapters/Background/FixedPoint.tex index 352e9d3..4ef2f6c 100644 --- a/chapters/Background/FixedPoint.tex +++ b/chapters/Background/FixedPoint.tex @@ -1,8 +1,8 @@ -A positive real number $z$ may be written as the sum of smaller integers ``digits'' $d_i < z$ multiplied by powers of a base $\beta$. +A positive real number $z$ may be written as the sum of smaller integers ``digits'' $d_i$ multiplied by powers of a base $\beta$. \begin{align} - z &= \displaystyle\sum_{i=-\infty}^{\infty} d_i \beta^{i}\label{fixedpointZ} + z &= d_0 \beta^0 + d_1 \beta^1 + d_2 \beta^2 + \text{ ...} = \displaystyle\sum_{i=-\infty}^{\infty} d_i \beta^{i}\label{fixedpointZ} \end{align} -Where each digit $d_i < \beta$ the base. A set of $\beta$ unique symbols are used to represent values of $d_i$. +Where each digit $d_i < \beta$. A set of $\beta$ unique symbols are used to represent values of $d_i$. A seperate sign '-' can be used to represent negative reals using equation \eqref{fixedpointZ}. To express a real number using equation \eqref{fixedpointZ} in practice we are limited to a finite number of terms between $i = -m$ and $i = n$. Fixed point representations are capable of representing a discrete set of numbers $0 \leq |z| \leq \beta^{n+1}-\beta^{-m}$ seperated by $\Delta z = \beta^{-m} \leq 1$. In the case $m = 0$, only integers can be represented. @@ -13,7 +13,7 @@ Example integer representation in base 10 (decimal) and base 2 (binary): 1011000110010_2 &= 1\times2^{12} + 0\times2^{11} + \text{ ...} + 0\times2^0 \end{align*} -{\bf FIXME} Add Maths reference (Cantor's Diagonal argument) without going into all the Pure maths details +%{\bf FIXME} Add Maths reference (Cantor's Diagonal argument) without going into all the Pure maths details diff --git a/chapters/Background/FloatingPointOnTheGPU.tex b/chapters/Background/FloatingPointOnTheGPU.tex index 0d40fb1..d85bade 100644 --- a/chapters/Background/FloatingPointOnTheGPU.tex +++ b/chapters/Background/FloatingPointOnTheGPU.tex @@ -4,15 +4,7 @@ Traditionally, vector images have been rasterized by the CPU before being sent to a specialised Graphics Processing Unit (GPU) for drawing\cite{computergraphics2}. Rasterisation of simple primitives such as lines and triangles have been supported directly by GPUs for some time through the OpenGL standard\cite{openglspec}. However complex shapes (including those based on B{\'e}zier curves such as font glyphs) must either be rasterised entirely by the CPU or decomposed into simpler primitives that the GPU itself can directly rasterise. There is a significant body of research devoted to improving the performance of rendering such primitives using the latter approach, mostly based around the OpenGL\cite{openglspec} API\cite{robart2009openvg, leymarie1992fast, frisken2000adaptively, green2007improved, loop2005resolution, loop2007rendering}. Recently Mark Kilgard of the NVIDIA Corporation described an extension to OpenGL for NVIDIA GPUs capable of drawing and shading vector paths\cite{kilgard2012gpu,kilgard300programming}. From this development it seems that rasterization of vector graphics may eventually become possible upon the GPU. -It is not entirely clear how well supported the IEEE-754 standard for floating point computation is amongst GPUs\footnote{Informal technical articles are abundant on the internet --- Eg: Regarding the Dolphin Wii GPU Emulator: \url{https://dolphin-emu.org/blog} (accessed 2014-05-22)}. Although the OpenGL API does use IEEE-754 number representations, research by Hillesland and Lastra in 2004 suggested that many GPUs were not internally compliant with the standard\cite{hillesland2004paranoia}. +It is not entirely clear how well supported the IEEE-754 standard for floating point computation is amongst GPUs\footnote{Informal technical articles are abundant on the internet --- Eg: Regarding the Dolphin Wii GPU Emulator: \url{https://dolphin-emu.org/blog} (accessed 2014-05-22)}. Although the OpenGL API does use IEEE-754 number representations, research by Hillesland and Lastra in 2004 suggested that many GPUs were not internally compliant with the standard\cite{hillesland2004paranoia}. In Section \ref{} we illustrate how the use of -In order to explore this, we implemented a simple fragment shader to render a circle. Points $x^2 + y^2 < 1$ should be black. When scaled to bounds of width $\approx 10^{-6}$ the edges of the circle become jagged due to imprecision. However, the behaviour is quite different depending on GPU model. A CPU renderer was also implemented to evaluate the same function using IEEE-754 singles. - -\begin{figure}[H] - \centering - \includegraphics[width=0.7\textwidth]{figures/gpufloats.pdf} - \caption{Difference in evaluating $x^2 + y^2 < 1$ for the x86\_64 and various GPUs\\ - The view bounds are identical} -\end{figure} %Arbitrary precision arithmetic, is provided by many software libraries for CPU based calculations diff --git a/chapters/Background/Floats.tex b/chapters/Background/Floats.tex index 65a99e4..1be1113 100644 --- a/chapters/Background/Floats.tex +++ b/chapters/Background/Floats.tex @@ -4,7 +4,6 @@ \subsection{Floating Point Operations} -{\bf FIXME:} Appendix? \input{chapters/Background/Floats/Operations} @@ -12,4 +11,4 @@ Arbitrary precision floating point numbers are implemented in a variety of software libraries which will dynamically allocate extra bits for the exponent or mantissa as required. An example is the GNU MPFR library discussed by Fousse in 2007\cite{fousse2007mpfr}. Although many arbitrary precision libraries already existed, MPFR intends to be fully compliant with some of the more obscure IEEE-754 requirements such as rounding rules and exceptions. -As we have seen, it is trivial to find real numbers that would require an infinite number of bits to represent exactly. Implementations of ``arbitrary'' precision must carefully determine at what point rounding should occur so as to balance performance with memory usage. +It is trivial to find real numbers that would require an infinite number of bits to represent exactly (for example, $\frac{1}{3} = 0.333333\text{...}$). The GMP and MPFR libraries require a fixed (but arbitrarily large) precision be set; although it is possible to increase or decrease the precision of individual numbers as desired. diff --git a/chapters/Background/Floats/Definition.tex b/chapters/Background/Floats/Definition.tex index 33f1a15..d8fa885 100644 --- a/chapters/Background/Floats/Definition.tex +++ b/chapters/Background/Floats/Definition.tex @@ -1,16 +1,15 @@ Whilst a Fixed Point representation keeps the ``point'' (the location considered to be $i = 0$ in \eqref{fixedpointZ}) at the same position in a string of bits, Floating point representations can be thought of as scientific notation; an ``exponent'' and fixed point value are encoded, with multiplication by the exponent moving the position of the point. -{\bf FIXME: Cite properly} The use of floating point arithmetic in computer systems was pioneered by Knuth\cite{}, Goldberg\cite{goldbern1967twentyseven}, Dekker\cite{}, and others, but modern systems are largely compatable with the IEEE-754 standard pioneered by William Kahan in 1985 \cite{ieee754std1985} and revised (also with contributions from Kahan) in 2008\cite{ieee754std2008}. +The use of floating point arithmetic in computer systems was pioneered by Knuth, Goldberg{goldbern1967twentyseven}, Dekker, and others\cite{HFP}, but modern systems are largely compatable with the IEEE-754 standard pioneered by William Kahan in 1985 \cite{ieee754std1985} and revised (also with contributions from Kahan) in 2008\cite{ieee754std2008}. A floating point number $x$ is commonly represented by a tuple of values $(s, e, m)$ in base $B$ as\cite{HFP, ieee2008-754}: $x = (-1)^{s} \times m \times B^{e}$ -Where $s$ is the sign and may be zero or one, $m$ is commonly called the ``mantissa'' and $e$ is the exponent. Whilst $e$ is an integer in some range $\pm e_max$, the mantissa $m$ is a fixed point value in the range $0 < m < B$. +Where $s$ is the sign and may be zero or one, $m$ is commonly called the ``mantissa'' and $e$ is the exponent. Whilst $e$ is an integer in some range $\pm e_max$, the mantissa $m$ is a fixed point value in the range $0 < m < B$. The choice of base $B = 2$ in the original IEEE-754 standard matches the nature of modern hardware. It has also been found that this base in general gives the smallest rounding errors\cite{HFP}. - -The choice of base $B = 2$ in the original IEEE-754 standard matches the nature of modern hardware. It has also been found that this base in general gives the smallest rounding errors\cite{HFP}. Early computers had in fact used a variety of representations including $B=3$ or even $B=7$\cite{goldman1991whatevery}, and the revised IEEE-754 standard specifies a decimal representation $B = 10$ intended for use in financial applications\cite{ieee754std2008}\footnote{Eg: The smallest valid unit of currency \$0.01 could not be represented exactly in base 2}. From now on we will restrict ourselves to considering base 2 floats. +%Early computers had in fact used a variety of representations including $B=3$ or even $B=7$\cite{goldman1991whatevery}, and the revised IEEE-754 standard specifies a decimal representation $B = 10$ intended for use in financial applications\cite{ieee754std2008}\footnote{Eg: The smallest valid unit of currency \$0.01 could not be represented exactly in base 2}. From now on we will restrict ourselves to considering base 2 floats. The IEEE-754 encoding of $s$, $e$ and $m$ requires a fixed number of continuous bits dedicated to each value. Originally two encodings were defined: binary32 and binary64. $s$ is always encoded in a single leading bit, whilst (8,23) and (11,53) bits are used for the (exponent, mantissa) encodings respectively. -The encoding of $m$ in the IEEE-754 standard is not exactly equivelant to a fixed point value. By assuming an implicit leading bit (ie: restricting $1 \leq m < 2$) except for when $e = 0$, floating point values are gauranteed to have a unique representations; these representations are said to be ``normalised''. When $e = 0$ the leading bit is not implied; these representations are called ``denormals'' because multiple representations may map to the same real value. The idea of using an implicit bit appears to have been considered by Goldberg as early as 1967\cite{goldbern1967twentyseven}. +The encoding of $m$ in the IEEE-754 standard is not exactly equivelant to a fixed point value. By assuming an implicit leading bit (ie: restricting $1 \leq m < 2$) except for when $e = 0$, floating point values are gauranteed to have a unique representations; these representations are said to be ``normalised''. When $e = 0$ the leading bit is not implied; these representations are called ``denormals'' because multiple representations may map to the same real value. The idea of using an implicit bit appears to have been considered by Goldberg as early as 1967\cite{goldbern1967twentyseven}, and it leads to an increase of precision near the origin. diff --git a/chapters/Background/Floats/Operations.tex b/chapters/Background/Floats/Operations.tex index 5624892..a527c39 100644 --- a/chapters/Background/Floats/Operations.tex +++ b/chapters/Background/Floats/Operations.tex @@ -1,6 +1,11 @@ -Real values which cannot be represented exactly in a floating point representation must be rounded to the nearest floating point value. The results of a floating point operation will in general be such values and thus there is a rounding error possible in any floating point operation. Referring to Figure \ref{floats.pdf} it can be seen that the largest possible rounding error is half the distance between successive floats; this means that rounding errors increase as the value to be represented increases. For the result of a particular operation, the maximum possible rounding error can be determined and is commonly expressed in ``units in the last place'' (ulp), with 1 ulp equivelant to half the distance between successive floats\cite{goldberg1991whatevery}. +Real values which cannot be represented exactly in a floating point representation must be rounded to the nearest floating point value. The results of a floating point operation will in general be such values and thus there is a rounding error possible in any floating point operation\cite{HFP}. +Referring to Figure \ref{floats.pdf} it can be seen that the largest possible rounding error is half the distance between successive floats; this means that rounding errors increase as the value to be represented increases. For the result of a particular operation, the maximum possible rounding error can be determined and is commonly expressed in ``units in the last place'' (ulp), with 1 ulp equivelant to half the distance between successive floats\cite{goldberg1991whatevery}. + + +\begin{comment} +Floating point operations can in principle be performed using integer operations, but specialised Floating Point Units (FPUs) are an almost universal component of modern processors\cite{kelley1997acmos}. The improvement of FPUs remains highly active in several areas including: efficiency\cite{seidel2001onthe}; accuracy of operations\cite{dieter2007lowcost}; and even the adaptation of algorithms originally used in software, such as Kahan's Fast2Sum algorithm\cite{kadric2013accurate}. {\bf Put this stuff in an Appendix?} @@ -25,4 +30,4 @@ This is equivelant to shifting the fixed point in $m_2$ by $e_2 - e_1$ to the le Multiplication and Division are not inverses. -Floating point operations can in principle be performed using integer operations, but specialised Floating Point Units (FPUs) are an almost universal component of modern processors\cite{kelley1997acmos}. The improvement of FPUs remains highly active in several areas including: efficiency\cite{seidel2001onthe}; accuracy of operations\cite{dieter2007lowcost}; and even the adaptation of algorithms originally used in software, such as Kahan's Fast2Sum algorithm\cite{kadric2013accurate}. +\end{comment} diff --git a/chapters/Background/Floats/Visualisation.tex b/chapters/Background/Floats/Visualisation.tex index 1588b03..41bbda3 100644 --- a/chapters/Background/Floats/Visualisation.tex +++ b/chapters/Background/Floats/Visualisation.tex @@ -1,5 +1,5 @@ -Figure \ref{floats.pdf} shows the positive real numbers which can be represented exactly by an 8 bit floating point number encoded in the IEEE-754 format. We show two encodings using (1,2,5) and (1,3,4) bits to encode (sign, exponent, mantissa) respectively. For each distinct value of the exponent, the successive floating point representations lie on a straight line with constant slope. As the exponent increases, larger values are represented, but the distance between successive values increases; this can be seen in Figure\ref{}. The marked single point discontinuity at \verb/0x10/ and \verb/0x20/ occur when $e$ leaves the denormalised region and the encoding of $m$ changes. We have also plotted a fixed point representation for comparison; fixed point and integer representations appear as straight lines - the distance between points is always constant. +Figure \ref{floats.pdf} shows the positive real numbers which can be represented exactly by an 8 bit floating point number encoded in the IEEE-754 format. We show two encodings using (1,2,5) and (1,3,4) bits to encode (sign, exponent, mantissa) respectively. For each distinct value of the exponent, the successive floating point representations lie on a straight line with constant slope. As the exponent increases, larger values are represented, but the distance between successive values increases; this can be seen in Figure\ref{}. The marked single point discontinuity at \verb/0x10/ and \verb/0x20/ occur when $e$ leaves the denormalised region and the encoding of $m$ changes. We have also plotted a fixed point representation for comparison; fixed point and integer representations appear on straight lines. \begin{comment} The earlier example $7.25$ would be converted to a (1,3,4) floating point representation as follows: diff --git a/chapters/Background/Overview.tex b/chapters/Background/Overview.tex index 7b4256b..8b13789 100644 --- a/chapters/Background/Overview.tex +++ b/chapters/Background/Overview.tex @@ -1 +1 @@ -An overview will go here. + diff --git a/chapters/Background/Rendering.tex b/chapters/Background/Rendering.tex index 9a9bbdb..ce9d13a 100644 --- a/chapters/Background/Rendering.tex +++ b/chapters/Background/Rendering.tex @@ -4,10 +4,6 @@ \input{chapters/Background/Rendering/StraightLines} \subsection{B\'{e}zier Splines} \input{chapters/Background/Rendering/BezierSplines} -\subsection{Filled Paths} -\subsection{Compositing} -{\bf FIXME} Really won't have time to mention these? -They are important, but we didn't end up implementing them anyway. \subsection{Fonts} \input{chapters/Background/Rendering/Fonts} diff --git a/chapters/Introduction.tex b/chapters/Introduction.tex index 1d31e79..005853a 100644 --- a/chapters/Introduction.tex +++ b/chapters/Introduction.tex @@ -2,10 +2,10 @@ Early electronic document formats such as PostScript were motivated by a need to print documents onto a paper medium. In the PostScript standard, this lead to a model of the document as a program; a series of instructions to be executed by an interpreter which would result in ``ink'' being placed on ``pages'' of a fixed size\cite{plrm}. The ubiquitous Portable Document Format (PDF) standard provides many enhancements to PostScript taking into account desktop publishing requirements\cite{cheng2002portable}, but it is still fundamentally based on the same imaging model\cite{pdfref17}. This idea of a document as a static ``page'' has lead to limitations on what could be achieved with a digital document viewers \cite{hayes2012pixels}. -%The emergence of the internet, web browsers, XML/HTML, JavaScript and related technologies has seen a revolution in the ways in which information can be presented digitally, and the PDF standard itself has begun to move beyond static text and figures\cite{hayes2012pixels, barnes2013embedding}. However, the popular document formats are still designed with the intention of showing information at either a single, fixed level of detail, or a small range of levels. +The emergence of the internet, web browsers, XML/HTML, JavaScript and related technologies has seen a revolution in the ways in which information can be presented digitally, and the PDF standard itself has begun to move beyond static text and figures\cite{hayes2012pixels, barnes2013embedding}. However, the popular document formats are still designed with the intention of showing information at either a single, fixed level of detail, or a small range of levels. As most digital display devices are smaller than physical paper medium, all useful viewers are able to ``zoom'' to a subset of the document. Vector graphics formats including PostScript, PDF and SVG support rasterisation at different zoom levels\cite{plrm, pdfref17, svg2011-1.1}, but the use of fixed precision floating point numbers causes problems due to imprecision either far from the origin, or at a high level of detail\cite{goldberg1991whatevery, goldberg1992thedesign}. There are many possible applications for documents in which precision is unlimited. Several areas of use include: visualisation of extremely large or infinite data sets; visualisation of high precision numerical computations; digital artwork; computer aided design; and maps. -We have implemented a proof of concept document viewer compatable with a subset of the SVG standard, which has allowed us to explore the limitations of floating point arithmetic and possible approaches to achieving arbitrary precision document formats. Using the Rational representation of the GNU Multiple Precision (GMP) library\cite{granlund2014GMP} we are able to implement correct rendering of SVG test images seperated by arbitrary distances. We demonstrate the trade off between performance cost and the accuracy of rendering +In collaboration with Gow\cite{} we have implemented a proof of concept document viewer compatable with a subset of the SVG standard, which has allowed us to explore the limitations of floating point arithmetic and possible approaches to achieving arbitrary precision document formats. Using the Rational representation of the GNU Multiple Precision (GMP) library\cite{granlund2004GMP} we are able to implement correct rendering of SVG test images seperated by arbitrary distances. We present measurements of rendering accuracy and performance for our implementation. diff --git a/chapters/Process.tex b/chapters/Process.tex index 3e64319..934e708 100644 --- a/chapters/Process.tex +++ b/chapters/Process.tex @@ -1,133 +1,84 @@ \chapter{Methods and Design} -{\bf TODO} Write most of this section. I suspect I will have to be very selective about what to fit in considering the word limit. - -\section{Collaborative Process} -\begin{itemize} - \item Collaborated with David Gow on the design and implementation of the SVG viewer - \item Individual work: Applying GMP Rationals (Sam), Quadtree (David) - \begin{itemize} - \item CPU renderer, SVG parsing, Control Panel, Python Scripts - Sam - \item Most of the OpenGL stuff, Scaling/Translating controls - David - \item Other parts were worked on by everyone - \end{itemize} - \item Used git to collaborate \url{https://git.ucc.asn.au} - \item Used preprocessor defines to not interfere with each other's code too much - \item David used a \verb/goto/ letting the team down -\end{itemize} \section{Structure of Software} -\begin{itemize} - \item CPU and GPU renderer supported - \begin{itemize} - \item See figure in ``Floating Point Operations on the CPU and GPU'' - \end{itemize} - \item Rendering of Cubic B\'{e}ziers (no antialiasing) - \item Partial implementation of shading Paths on CPU (abandoned) - \item Ability to move the view around the document with the mouse - \item Ability to insert an SVG into the view location - \item \verb/typedef/ for number representations - \item Ability to control program through scripts or stdio - \item Hacky python scripts to produce plots by abusing this -\end{itemize} + +A custom vector graphics viewer called IPDF\footnote{The original name ``Infinite Precision Document Format'' stuck, although the word ``Infinite'' is highly misleading} was implemented for this project in collaboration with David Gow\cite{}. We will give a brief overview of the features and limitations of this software. + +\subsection{Document Structure} + +IPDF is built around Objects which can be rendered either on the CPU (directly altering a bitmap and then uploading to the GPU) or the GPU (via the use of OpenGL GLSL shader programs). + +Initially only very simple shapes (Rectangles and Circles) were supported, but in order to produce a meaningful demonstration of arbitrary precision viewing, Paths formed from Quadratic or Cubic B\'{e}ziers as specified by the SVG standard were added. Shading of paths is partially implemented. + +\subsection{Rendering Process} + +As discussed in Section \ref{} it is not clear to what extend GPUs comply with the IEEE-754 standard, and arbitrary precision arithmetic is most easily implemented on the CPU; for this reason a CPU renderer and GPU renderer were implemented. + +All Objects are represented by their bounding rectangles; in the case of B\'{e}zier curves the control points are stored relative to the bounding rectangle. The rendering process involves converting the bounding rectangle coordinates from Document to Screen space as discussed in Section \ref{}. For both GPU and CPU rendering a B\'{e}zier in screen space is decomposed into straight lines; the CPU renders these lines using Bresenham's algorithm. + + + +\subsection{Interactivity} + +There are two ways to control the IPDF software; manually through use of keyboard and mouse and a Qt4\cite{} based control panel, or automatically through a script containing a sequence of commands to transform the view or insert SVGs. In both cases SVGs can be inserted scaled to the current View rectangle. + +\subsection{Version Control} + +The Git version control system was used to collaborate on this project; the main repository may be viewed at \url{http://git.ucc.asn.au/?p=ipdf/code.git} \section{Approaches to Arbitrary Precision} -\begin{itemize} - \item Replace \emph{all} operations with arbitrary precision (ie: Rationals) - Horrendously slow - \item Change approach to applying coordinate transform \eqref{view-transformation} - \item Apply view transformations directly to objects as the view is transformed, rather than just before rendering - \begin{itemize} - \item Allows much better precision and range with just regular IEEE-754 floats - \item But there is an accumulated rounding error, particularly when zooming out and back in, which is bad - \end{itemize} - \item As above, but introduce intermediate coordinate system; use the Path elements - \begin{itemize} - \item Rendering of individual paths is consistent but overall they drift apart - \end{itemize} - \item As above, but specify Path coordinates with arbitrary precision rationals - \begin{itemize} - \item Works well, rationals slow down though - \end{itemize} -\end{itemize} -\section{Number Representations Trialed} -\begin{itemize} - \item IEEE-754 single, double, extended - \item Custom implementation of Rationals with \verb/int64_t/ - \begin{itemize} - \item Very limited since the integers grow exponentially and overflow - \end{itemize} - \item Custom implementation of Rationals with custom Arbitrary precision integers - \begin{itemize} - \item Actually works - \item Implementation of division is too slow to be feasible - \end{itemize} - \item Custom rationals but with GMP arbitrary precision integers - \begin{itemize} - \item Our implementation of GCD is not feasible - \end{itemize} - \item Paranoid Numbers; store a operation tree of IEEE-754 floats and simplify the tree wherever \verb/FE_INEXACT/ is \emph{not} raised - \begin{itemize} - \item This was a really, really, really, bad idea - \end{itemize} - \item Just use GMP rationals already - \begin{itemize} - \item Works - \end{itemize} - - \item MPFR floats - \begin{itemize} - \item They work, but they don't truly give arbitrary precision - \item Because you have to specify the maximum precision - \item However, this can be changed at runtime - \item Future work: Trial MPFR floats changing the precision as needed - \end{itemize} - -\end{itemize} +\subsection{Na\"{i}ve Approach} + +A na\"{i}ve approach would be to replace all floating point operations with arbitrary precision operations, and this was in fact tried in early experiments. This approach requires use of the CPU renderer, as GLSL is restricted to floating point representations. A type definition \texttt{Real} on the CPU can be selected at compile time. + +Unfortunately truly arbitrary precision number representations were found to be far too inefficient for practical purposes --- for example, rendering a frame with GMP Rationals could take up to 60 seconds at the default view. + + +\begin{comment} +\subsubsection{Number Representations Trialed} + +\begin{enumerate} + \item IEEE-754 single, double, extended (control) + \item Custom implementation of Rationals with 64 bit integers + \item Custom implementation of Rationals with custom Arbitrary Precision Integers + \item Custom implementation of Rationals but with GMP integers + \item GMP Rationals + \item MPFR Arbitrary Precision Floats + \item iRRAM ``exact'' real arithmetic\cite{} +\end{enumerate} +\end{comment} + +\subsection{Intermediate Coordinate Systems} + +When an object is visible on the screen it is only necessary to render it accurately to within the nearest pixel. +As shown in the Results Section \ref{}, introducing an intermediate coordinate system for a large number of objects and applying transformations to this coordinate system instead of individual objects produces the best results both in terms of reduced rounding errors using floating point arithmetic, and reduced number of required arbitrary precision operations. + +\subsection{Quadtree Document Division} + +An approach identified by Gow\cite{} is to construct intermediate coordinate systems as the user manipulates the view. + + \section{Libraries Used} + +The libraries used to compile the IPDF software are: \begin{itemize} \item SDL2 - Simple Direct media Library \begin{itemize} \item Used for window management and to obtain an OpenGL context - \item Also provides BMP handling which is useful - \end{itemize} - \item Qt4 (optional) - \begin{itemize} - \item Open source toolkit for Dialog based applications - \item We can optionally compile with a Qt4 based control panel - \item This is useful for interacting with the document - \item Has way more features than we actually use it for - \end{itemize} - \item OpenGL - Standard API for rendering on GPUs - \begin{itemize} - \item Using GLSL shaders - \item B\'{e}ziers are rendered using a Geometry shader which produces line segments - \end{itemize} - \item PugiXML - Open source XML parsing library - \begin{itemize} - \item Used to parse SVGs + \item Provides Bitmap handling functions \end{itemize} + \item Qt4 (optional) --- Open source toolkit for Dialog based applications + \item OpenGL (4.4) --- The standard API for controlling GPUs + \item PugiXML --- Open source XML parsing library used to implement parsing of SVGs \item GNU Multiple Precision (GMP) \begin{itemize} \item Implements arbitrary precision integers, floats, and rationals - \item We can use the arbitrary precision integers with a custom rational type - \item Or just use the GMP rational type (much better) - \item We don't use the floats, because they are hardware dependent - \end{itemize} - \item MPFR - \begin{itemize} - \item MPFR is built on GMP but ensures IEEE-754 consistent rounding behaviour - \item (Not hardware dependent) - \item We can compile with MPFR floats but the precision is currently fixed at compile time + \item Highly optimised using CPU specific assembly instructions \end{itemize} + \item MPFR --- built on GMP but ensures IEEE-754 consistent rounding behaviour \end{itemize} -\section{Design of Performance Tests} -\begin{itemize} - \item This is mostly covered in the Results chapter - \item Control the program through stdin using a python script - \item Results plotted with matplotlib -\end{itemize} - diff --git a/chapters/Progress.tex b/chapters/Progress.tex deleted file mode 100644 index e37865d..0000000 --- a/chapters/Progress.tex +++ /dev/null @@ -1,106 +0,0 @@ -\chapter{Progress Report}\label{Progress} - -We describe the current state of our project in relation to the aims outlined in Chapter \ref{Introduction}. At this stage work on the project has been done in collaboration with David Gow; however the Project Proposals and Literature Reviews were produced individually. - -\section{Literature Review} -The literature examined in Chapter\ref{Background} can broadly classed into three different areas (with major references indicated): -\begin{enumerate} - \item Rendering Vector Graphics \cite{computergraphics2, knuth1983metafont, kilgard2012gpu} - \begin{itemize} - \item Rasterisation of Vector Graphics is non-trivial but well understood - \item Traditionally most rasterisation has been performed on the CPU and drawing on a dedicated GPU; current interest is in techniques for utilising the GPU directly to rasterise vector graphics - \end{itemize} - \item Representations of Vector Documents \cite{hayes2012pixels, plrm, knuth1984texbook, svg2011-1.1, pdfref17} - \begin{itemize} - \item Traditional approaches are be based on a programmatic model (PostScript, {\TeX}, DVI) - \item The Document Object Model (DOM) used by web technologies is a powerful way to produce dynamic documents (HTML5, SVG, Javascript) - \item These approaches can overlap (PDF) - \end{itemize} - \item Number Representations \cite{ieee754std2008, HFP, goldberg1991whatevery, fousse2007mpfr} - \begin{itemize} - \item Most document standards either specify, suggest, or imply a IEEE-754 floating point representation ({\TeX} is an exception) - \item IEEE-754 is widely used, although there are instances of languages or processors which do not conform exactly to the standard - \item Some GPUs in particular may not conform to IEEE-754, possibly trading some accuracy for performance - \item Arbitrary precision floating point arithmetic is possible through several libraries - \end{itemize} -\end{enumerate} - -To improve the Literature Review we could consider the following topics in more detail: -\begin{enumerate} - \item Additional approaches to arbitrary precision possibly including symbolic computation - \begin{itemize} - \item The Mathematica computational package claims to use symbolic computation, but we have yet to explore this field - \end{itemize} - \item Floating point errors in the context of computing B\'{e}zier Curves or similar - \item Algorithms for reducing overall error other than Fast2Sum - \item Alternative number representations such as rationals (eg: $\frac{1}{3}$) - \item How well GPUs conform or do not conform to IEEE-754 in more detail - \item Additional aspects of rendering vector documents including shading -\end{enumerate} - - -\section{Development of Testbed Software} - -We have produced a basic Document Viewer capable of rendering simple primitives under translation and scaling. The OpenGL 3.1 API is used to interface with graphics hardware. This software has the following features: -\begin{enumerate} - \item A type name \verb/Real/ is used in place of the standard floating point types \verb/float/, \verb/double/ or \verb/long double/. This type name can be redefined to refer to one of the standard types or a custom real number representation, allowing us to easily recompile and test our software for different representations. - \item Screenshots can be overlaid on top of each other to get a pixel comparison of the graphical output of different versions of the program - \item Test documents can be loaded and saved so that we can compare different versions of the program on identical inputs - \item The time for rendering can be measured - \item Coordinate transformations may be performed on either the GPU or CPU -\end{enumerate} - -We have noticed the CPU produces more precise coordinate transformations at large ``zoom'' levels, but is significantly slower than the GPU. We have yet to quantitatively measure this difference. - -\section{Floating Point Arithmetic} - -Algorithms for floating point arithmetic may be implemented in software (CPU) or on dedicated hardware (FPU). We have made progress towards both approaches. - -An open source Virtual FPU implemented in the VHDL language has been successfully compiled and can be substituted into our testbed software in place of native arithmetic running on the CPU. The timing diagram for this FPU throughout the execution of test programs can be extracted. Currently the virtual FPU is restricted to 32 bit floats and the square root operation is unimplemented. - -Mainly motivated by producing Figure \ref{floats.pdf} we have also implemented functions to convert an arbitrary \verb/Real/ type (which may be IEEE-754 floats) to and from a fixed size floating point representation of our choosing. We have not implemented any operations for floating point arithmetic using these representations. - -By using the functions to convert real numbers to variable precision floats as an interface for the virtual FPU, we hope to illustrate the limitations of floating point arithmetic more clearly than would be possible using IEEE-754 binary32 as is native to the C and C++ languages. Using the virtual FPU instead of a CPU based software library will prove useful for determining the exact performance of floating point operations. - -\section{Prototype Document Formats} - -Our testbed software is capable of reading primitive attributes from either a binary file or XML plain text file. Our format is conceptually similar to the Document Object Model, although there is currently only one generation in the tree as no primitives can contain other elements as of yet. - -If time permits, we plan to extend our XML format to cover a subset of the SVG standard. This may allow us to compare the rasterisation of an SVG using our own software and traditional software relying on IEEE-754 floats. - -Some of the figures produced for Chapter \ref{Background} may prove useful as standard test images for comparing the qualitative performance of versions of our software. - -\section{Version Control and Backup of Work} - -Git is a distributed version control system widely used in the development of open source software. All rescources created for or used by this project have been placed in git repositories on several servers. The repositories are publically accessable at \url{http://git.ucc.asn.au}, \url{http://szmoore.net/ipdf}. - -\section{Timeline} - -Deadlines enforced by the faculty of Engineering Computing and Mathematics are \emph{italicised}.\footnote{David Gow is being assessed under the 2014 rules for a BEng (Software) Final Year Project, whilst the author is being assessed under the 2014 rules for a BEng (Mechatronics) Final Year Project; deadlines and requirements as shown in Gow's proposal\cite{proposalGow} may differ}. - -\begin{center} -\begin{tabular}{l|p{0.5\textwidth}} - {\bf Date} & {\bf Milestone} \\ - \hline - $1^{\text{st}}$ May & Testbed Software (basic document format and viewer) completed and approaches for extending to allow infinite precision identified. \\ - \hline - $17^{\text{th}}$ May & Draft Progress Report and Literature Review \\ - \hline - $26^{\text{th}}$ May & \emph{Progress Report and Literature Review due.}\\ - \hline - $9^{\text{th}}$ June & Demonstrations of limitations of floating point precision in the Testbed software. \\ - $1^{\text{st}}$ July & At least one implementation of arbitrary precision for basic primitives (lines, polygons, curves) completed. Other implementations, advanced features, and areas for more detailed research identified. \\ - \hline - $1^{\text{st}}$ August & Experiments and comparison of various arbitrary precision implementations completed. \\ - \hline - $1^{\text{st}}$ September & Advanced features implemented and tested, work underway on Final Report. \\ - \hline - TBA & \emph{Conference Abstract and Presentation due.} \\ - \hline - $10^{\text{th}}$ October & \emph{Draft of Final Report due.} \\ - \hline - $27^{\text{th}}$ October & \emph{Final Report due.}\\ - \hline -\end{tabular} -\end{center} - diff --git a/chapters/Progress/Progress.tex b/chapters/Progress/Progress.tex deleted file mode 100644 index e37865d..0000000 --- a/chapters/Progress/Progress.tex +++ /dev/null @@ -1,106 +0,0 @@ -\chapter{Progress Report}\label{Progress} - -We describe the current state of our project in relation to the aims outlined in Chapter \ref{Introduction}. At this stage work on the project has been done in collaboration with David Gow; however the Project Proposals and Literature Reviews were produced individually. - -\section{Literature Review} -The literature examined in Chapter\ref{Background} can broadly classed into three different areas (with major references indicated): -\begin{enumerate} - \item Rendering Vector Graphics \cite{computergraphics2, knuth1983metafont, kilgard2012gpu} - \begin{itemize} - \item Rasterisation of Vector Graphics is non-trivial but well understood - \item Traditionally most rasterisation has been performed on the CPU and drawing on a dedicated GPU; current interest is in techniques for utilising the GPU directly to rasterise vector graphics - \end{itemize} - \item Representations of Vector Documents \cite{hayes2012pixels, plrm, knuth1984texbook, svg2011-1.1, pdfref17} - \begin{itemize} - \item Traditional approaches are be based on a programmatic model (PostScript, {\TeX}, DVI) - \item The Document Object Model (DOM) used by web technologies is a powerful way to produce dynamic documents (HTML5, SVG, Javascript) - \item These approaches can overlap (PDF) - \end{itemize} - \item Number Representations \cite{ieee754std2008, HFP, goldberg1991whatevery, fousse2007mpfr} - \begin{itemize} - \item Most document standards either specify, suggest, or imply a IEEE-754 floating point representation ({\TeX} is an exception) - \item IEEE-754 is widely used, although there are instances of languages or processors which do not conform exactly to the standard - \item Some GPUs in particular may not conform to IEEE-754, possibly trading some accuracy for performance - \item Arbitrary precision floating point arithmetic is possible through several libraries - \end{itemize} -\end{enumerate} - -To improve the Literature Review we could consider the following topics in more detail: -\begin{enumerate} - \item Additional approaches to arbitrary precision possibly including symbolic computation - \begin{itemize} - \item The Mathematica computational package claims to use symbolic computation, but we have yet to explore this field - \end{itemize} - \item Floating point errors in the context of computing B\'{e}zier Curves or similar - \item Algorithms for reducing overall error other than Fast2Sum - \item Alternative number representations such as rationals (eg: $\frac{1}{3}$) - \item How well GPUs conform or do not conform to IEEE-754 in more detail - \item Additional aspects of rendering vector documents including shading -\end{enumerate} - - -\section{Development of Testbed Software} - -We have produced a basic Document Viewer capable of rendering simple primitives under translation and scaling. The OpenGL 3.1 API is used to interface with graphics hardware. This software has the following features: -\begin{enumerate} - \item A type name \verb/Real/ is used in place of the standard floating point types \verb/float/, \verb/double/ or \verb/long double/. This type name can be redefined to refer to one of the standard types or a custom real number representation, allowing us to easily recompile and test our software for different representations. - \item Screenshots can be overlaid on top of each other to get a pixel comparison of the graphical output of different versions of the program - \item Test documents can be loaded and saved so that we can compare different versions of the program on identical inputs - \item The time for rendering can be measured - \item Coordinate transformations may be performed on either the GPU or CPU -\end{enumerate} - -We have noticed the CPU produces more precise coordinate transformations at large ``zoom'' levels, but is significantly slower than the GPU. We have yet to quantitatively measure this difference. - -\section{Floating Point Arithmetic} - -Algorithms for floating point arithmetic may be implemented in software (CPU) or on dedicated hardware (FPU). We have made progress towards both approaches. - -An open source Virtual FPU implemented in the VHDL language has been successfully compiled and can be substituted into our testbed software in place of native arithmetic running on the CPU. The timing diagram for this FPU throughout the execution of test programs can be extracted. Currently the virtual FPU is restricted to 32 bit floats and the square root operation is unimplemented. - -Mainly motivated by producing Figure \ref{floats.pdf} we have also implemented functions to convert an arbitrary \verb/Real/ type (which may be IEEE-754 floats) to and from a fixed size floating point representation of our choosing. We have not implemented any operations for floating point arithmetic using these representations. - -By using the functions to convert real numbers to variable precision floats as an interface for the virtual FPU, we hope to illustrate the limitations of floating point arithmetic more clearly than would be possible using IEEE-754 binary32 as is native to the C and C++ languages. Using the virtual FPU instead of a CPU based software library will prove useful for determining the exact performance of floating point operations. - -\section{Prototype Document Formats} - -Our testbed software is capable of reading primitive attributes from either a binary file or XML plain text file. Our format is conceptually similar to the Document Object Model, although there is currently only one generation in the tree as no primitives can contain other elements as of yet. - -If time permits, we plan to extend our XML format to cover a subset of the SVG standard. This may allow us to compare the rasterisation of an SVG using our own software and traditional software relying on IEEE-754 floats. - -Some of the figures produced for Chapter \ref{Background} may prove useful as standard test images for comparing the qualitative performance of versions of our software. - -\section{Version Control and Backup of Work} - -Git is a distributed version control system widely used in the development of open source software. All rescources created for or used by this project have been placed in git repositories on several servers. The repositories are publically accessable at \url{http://git.ucc.asn.au}, \url{http://szmoore.net/ipdf}. - -\section{Timeline} - -Deadlines enforced by the faculty of Engineering Computing and Mathematics are \emph{italicised}.\footnote{David Gow is being assessed under the 2014 rules for a BEng (Software) Final Year Project, whilst the author is being assessed under the 2014 rules for a BEng (Mechatronics) Final Year Project; deadlines and requirements as shown in Gow's proposal\cite{proposalGow} may differ}. - -\begin{center} -\begin{tabular}{l|p{0.5\textwidth}} - {\bf Date} & {\bf Milestone} \\ - \hline - $1^{\text{st}}$ May & Testbed Software (basic document format and viewer) completed and approaches for extending to allow infinite precision identified. \\ - \hline - $17^{\text{th}}$ May & Draft Progress Report and Literature Review \\ - \hline - $26^{\text{th}}$ May & \emph{Progress Report and Literature Review due.}\\ - \hline - $9^{\text{th}}$ June & Demonstrations of limitations of floating point precision in the Testbed software. \\ - $1^{\text{st}}$ July & At least one implementation of arbitrary precision for basic primitives (lines, polygons, curves) completed. Other implementations, advanced features, and areas for more detailed research identified. \\ - \hline - $1^{\text{st}}$ August & Experiments and comparison of various arbitrary precision implementations completed. \\ - \hline - $1^{\text{st}}$ September & Advanced features implemented and tested, work underway on Final Report. \\ - \hline - TBA & \emph{Conference Abstract and Presentation due.} \\ - \hline - $10^{\text{th}}$ October & \emph{Draft of Final Report due.} \\ - \hline - $27^{\text{th}}$ October & \emph{Final Report due.}\\ - \hline -\end{tabular} -\end{center} - diff --git a/chapters/Results.tex b/chapters/Results.tex index 1d4d939..6f07e3d 100644 --- a/chapters/Results.tex +++ b/chapters/Results.tex @@ -1,7 +1,5 @@ \chapter{Results and Discussion} -{\bf Note: Need to be more consistent, I often refer to B\'{e}ziers and Objects interchangably (since the original design was based around an Object and B\'{e}zier was just one possible Object, but we have moved on to pretty much only caring about B\'{e}ziers now)} - \section{Qualitative Rendering Accuracy} Our ultimate goal is to be able to insert detail at an arbitrary point in the document. Therefore, we are interested in how the same test SVG would appear when scaled to the view coordinates, as the view coordinates are varied. @@ -119,8 +117,19 @@ By considering Figure \ref{loss_of_precision_grid_0.5.pdf} and \ref{cumulative_e \section{Performance Measurements whilst Rendering} As discussed above, we succeeded in preserving rendering accuracy as defined above for an arbitrary view. -However this comes at a performance cost, as the size of the number representation must grow accordingly. +However this comes at a performance cost, as the size of the Rational number representation must grow accordingly. Figures \ref{memory.pdf} and \ref{time.pdf} were obtained by repeatedly clearing the document, scaling, and adding a fixed number of B\'{e}zier curves. + +\begin{figure}[H] + \centering + \includegraphics[width=0.8\textwidth]{figures/memory.pdf} + \label{memory.pdf} + \caption{Memory used per Rational whilst zooming in} +\end{figure} -{\bf TODO: Insert performance measurements here} +\begin{figure}[H] + \centering + \includegraphics[width=0.8\textwidth]{figures/time.pdf} + \label{time.pdf} + \caption{Time taken to scale about the fixed point} +\end{figure} -{\bf TODO: Also, would be nice to show a graph (log scale) where something goes past $10^{\pm320}$ (absolute limit for doubles, previous figures are all within range of representable floats} diff --git a/figures/gpufloats.pdf b/figures/gpufloats.pdf index 70b0eff..afde44d 100644 Binary files a/figures/gpufloats.pdf and b/figures/gpufloats.pdf differ diff --git a/figures/gpufloats.svg b/figures/gpufloats.svg index 76eb9ae..492c50f 100644 --- a/figures/gpufloats.svg +++ b/figures/gpufloats.svg @@ -14,8 +14,8 @@ height="1182.4047" id="svg2" version="1.1" - inkscape:version="0.48.4 r9939" - sodipodi:docname="comparison.svg"> + inkscape:version="0.48.5 r10040" + sodipodi:docname="gpufloats.pdf"> @@ -82,7 +82,7 @@ image/svg+xml - + @@ -105,520 +105,7 @@ @@ -657,7 +144,7 @@ RUVFe48DAAA4hPx/uMxqnRhMWTgAAAAASUVORK5CYII= y="471.46744" x="488.59012" id="tspan3350-7" - sodipodi:role="line">nVidia shader + sodipodi:role="line">nVidia fglrx shader + sodipodi:role="line">AMD/ATI intel shader + sodipodi:role="line">intel diff --git a/figures/loss_of_precision_grid_0.5.pdf b/figures/loss_of_precision_grid_0.5.pdf index f2a3f41..d72dbed 100644 Binary files a/figures/loss_of_precision_grid_0.5.pdf and b/figures/loss_of_precision_grid_0.5.pdf differ diff --git a/figures/memory.pdf b/figures/memory.pdf new file mode 100644 index 0000000..37852a4 Binary files /dev/null and b/figures/memory.pdf differ diff --git a/figures/time.pdf b/figures/time.pdf new file mode 100644 index 0000000..5b56ecc Binary files /dev/null and b/figures/time.pdf differ diff --git a/figures/view_transformation.pdf b/figures/view_transformation.pdf index b46b55c..78896c3 100644 Binary files a/figures/view_transformation.pdf and b/figures/view_transformation.pdf differ diff --git a/figures/view_transformation.svg b/figures/view_transformation.svg new file mode 100644 index 0000000..9f2223f --- /dev/null +++ b/figures/view_transformation.svg @@ -0,0 +1,492 @@ + + + +image/svg+xmlDisplay (S) +Document(D)View (V) +0,01,1 +Document via View to Display (S) +V + \ No newline at end of file diff --git a/figures/view_transformation_fail.pdf b/figures/view_transformation_fail.pdf index a107e4b..8242466 100644 Binary files a/figures/view_transformation_fail.pdf and b/figures/view_transformation_fail.pdf differ diff --git a/figures/view_transformation_fail.svg b/figures/view_transformation_fail.svg index cbe1ae0..2d43fb6 100644 --- a/figures/view_transformation_fail.svg +++ b/figures/view_transformation_fail.svg @@ -23,16 +23,16 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="0.7" - inkscape:cx="339.14655" - inkscape:cy="18.469407" + inkscape:zoom="0.98994949" + inkscape:cx="464.93962" + inkscape:cy="279.91133" inkscape:document-units="px" - inkscape:current-layer="g10198" + inkscape:current-layer="g10196" showgrid="false" - inkscape:window-width="1280" - inkscape:window-height="996" + inkscape:window-width="1366" + inkscape:window-height="692" inkscape:window-x="0" - inkscape:window-y="0" + inkscape:window-y="24" inkscape:window-maximized="1" showguides="true" inkscape:guide-bbox="true" @@ -164,109 +164,7 @@ font-stretch="normal" font-size-adjust="none" letter-spacing="normal" - word-spacing="normal"> + word-spacing="normal" /> + + + + + style="opacity:0.68181817;fill:none;stroke:#ff0000;stroke-width:2;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="path3607" + sodipodi:cx="341.43155" + sodipodi:cy="39.257938" + sodipodi:rx="15.152288" + sodipodi:ry="11.111678" + d="m 356.58384,39.257938 a 15.152288,11.111678 0 1 1 -30.30458,0 15.152288,11.111678 0 1 1 30.30458,0 z" + transform="matrix(1.1519586,0,0,1.2981254,49.752887,128.09781)" /> + style="opacity:0.68181817;fill:none;stroke:#ff0000;stroke-width:2;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="path3607-6" + sodipodi:cx="341.43155" + sodipodi:cy="39.257938" + sodipodi:rx="15.152288" + sodipodi:ry="11.111678" + d="m 356.58384,39.257938 a 15.152288,11.111678 0 1 1 -30.30458,0 15.152288,11.111678 0 1 1 30.30458,0 z" + transform="matrix(2.9915824,0,0,1.4177716,-803.85992,113.35434)" /> + + + Round to floats near Vx + Increases error in X diff --git a/figures/view_transformation_minimal.pdf b/figures/view_transformation_minimal.pdf new file mode 100644 index 0000000..1af0dcb Binary files /dev/null and b/figures/view_transformation_minimal.pdf differ diff --git a/presentation/example_uwa_eng.nav b/presentation/example_uwa_eng.nav deleted file mode 100644 index fd801fd..0000000 --- a/presentation/example_uwa_eng.nav +++ /dev/null @@ -1,47 +0,0 @@ -\beamer@endinputifotherversion {3.33pt} -\headcommand {\slideentry {0}{0}{1}{1/1}{}{0}} -\headcommand {\beamer@framepages {1}{1}} -\headcommand {\slideentry {0}{0}{2}{2/2}{}{0}} -\headcommand {\beamer@framepages {2}{2}} -\headcommand {\sectionentry {1}{Motivation \& Background}{3}{Motivation \& Background}{0}} -\headcommand {\beamer@sectionpages {1}{2}} -\headcommand {\beamer@subsectionpages {1}{2}} -\headcommand {\slideentry {1}{0}{3}{3/3}{}{0}} -\headcommand {\beamer@framepages {3}{3}} -\headcommand {\slideentry {1}{0}{4}{4/4}{}{0}} -\headcommand {\beamer@framepages {4}{4}} -\headcommand {\slideentry {1}{0}{5}{5/5}{}{0}} -\headcommand {\beamer@framepages {5}{5}} -\headcommand {\sectionentry {2}{Some theory}{6}{Some theory}{0}} -\headcommand {\beamer@sectionpages {3}{5}} -\headcommand {\beamer@subsectionpages {3}{5}} -\headcommand {\slideentry {2}{0}{6}{6/6}{}{0}} -\headcommand {\beamer@framepages {6}{6}} -\headcommand {\sectionentry {3}{Field Methods}{7}{Field Methods}{0}} -\headcommand {\beamer@sectionpages {6}{6}} -\headcommand {\beamer@subsectionpages {6}{6}} -\headcommand {\slideentry {3}{0}{7}{7/7}{}{0}} -\headcommand {\beamer@framepages {7}{7}} -\headcommand {\slideentry {3}{0}{8}{8/8}{}{0}} -\headcommand {\beamer@framepages {8}{8}} -\headcommand {\slideentry {3}{0}{9}{9/9}{}{0}} -\headcommand {\beamer@framepages {9}{9}} -\headcommand {\sectionentry {4}{Modeling}{10}{Modeling}{0}} -\headcommand {\beamer@sectionpages {7}{9}} -\headcommand {\beamer@subsectionpages {7}{9}} -\headcommand {\slideentry {4}{0}{10}{10/10}{}{0}} -\headcommand {\beamer@framepages {10}{10}} -\headcommand {\sectionentry {5}{Modeling2}{11}{Modeling2}{0}} -\headcommand {\beamer@sectionpages {10}{10}} -\headcommand {\beamer@subsectionpages {10}{10}} -\headcommand {\slideentry {5}{0}{11}{11/11}{}{0}} -\headcommand {\beamer@framepages {11}{11}} -\headcommand {\slideentry {5}{0}{12}{12/12}{}{0}} -\headcommand {\beamer@framepages {12}{12}} -\headcommand {\slideentry {5}{0}{13}{13/13}{}{0}} -\headcommand {\beamer@framepages {13}{13}} -\headcommand {\beamer@partpages {1}{13}} -\headcommand {\beamer@subsectionpages {11}{13}} -\headcommand {\beamer@sectionpages {11}{13}} -\headcommand {\beamer@documentpages {13}} -\headcommand {\def \inserttotalframenumber {13}} diff --git a/presentation/example_uwa_eng.snm b/presentation/example_uwa_eng.snm deleted file mode 100644 index e69de29..0000000 diff --git a/presentation/presentation.nav b/presentation/presentation.nav deleted file mode 100644 index 761a13a..0000000 --- a/presentation/presentation.nav +++ /dev/null @@ -1,73 +0,0 @@ -\beamer@endinputifotherversion {3.33pt} -\headcommand {\slideentry {0}{0}{1}{1/1}{}{0}} -\headcommand {\beamer@framepages {1}{1}} -\headcommand {\slideentry {0}{0}{2}{2/2}{}{0}} -\headcommand {\beamer@framepages {2}{2}} -\headcommand {\sectionentry {1}{Motivation}{3}{Motivation}{0}} -\headcommand {\beamer@sectionpages {1}{2}} -\headcommand {\beamer@subsectionpages {1}{2}} -\headcommand {\slideentry {1}{0}{3}{3/3}{}{0}} -\headcommand {\beamer@framepages {3}{3}} -\headcommand {\slideentry {1}{0}{4}{4/4}{}{0}} -\headcommand {\beamer@framepages {4}{4}} -\headcommand {\sectionentry {2}{Floating Point}{5}{Floating Point}{0}} -\headcommand {\beamer@sectionpages {3}{4}} -\headcommand {\beamer@subsectionpages {3}{4}} -\headcommand {\slideentry {2}{0}{5}{5/5}{}{0}} -\headcommand {\beamer@framepages {5}{5}} -\headcommand {\slideentry {2}{0}{6}{6/6}{}{0}} -\headcommand {\beamer@framepages {6}{6}} -\headcommand {\slideentry {2}{0}{7}{7/7}{}{0}} -\headcommand {\beamer@framepages {7}{7}} -\headcommand {\slideentry {2}{0}{8}{8/8}{}{0}} -\headcommand {\beamer@framepages {8}{8}} -\headcommand {\slideentry {2}{0}{9}{9/9}{}{0}} -\headcommand {\beamer@framepages {9}{9}} -\headcommand {\sectionentry {3}{Vector Graphics Viewer}{10}{Vector Graphics Viewer}{0}} -\headcommand {\beamer@sectionpages {5}{9}} -\headcommand {\beamer@subsectionpages {5}{9}} -\headcommand {\slideentry {3}{0}{10}{10/10}{}{0}} -\headcommand {\beamer@framepages {10}{10}} -\headcommand {\slideentry {3}{0}{11}{11/11}{}{0}} -\headcommand {\beamer@framepages {11}{11}} -\headcommand {\sectionentry {4}{Precision Issues}{12}{Precision Issues}{0}} -\headcommand {\beamer@sectionpages {10}{11}} -\headcommand {\beamer@subsectionpages {10}{11}} -\headcommand {\slideentry {4}{0}{12}{12/12}{}{0}} -\headcommand {\beamer@framepages {12}{12}} -\headcommand {\slideentry {4}{0}{13}{13/13}{}{0}} -\headcommand {\beamer@framepages {13}{13}} -\headcommand {\slideentry {4}{0}{14}{14/14}{}{0}} -\headcommand {\beamer@framepages {14}{14}} -\headcommand {\sectionentry {5}{Arbitrary Precision Rationals}{15}{Arbitrary Precision Rationals}{0}} -\headcommand {\beamer@sectionpages {12}{14}} -\headcommand {\beamer@subsectionpages {12}{14}} -\headcommand {\slideentry {5}{0}{15}{15/15}{}{0}} -\headcommand {\beamer@framepages {15}{15}} -\headcommand {\slideentry {5}{0}{16}{16/16}{}{0}} -\headcommand {\beamer@framepages {16}{16}} -\headcommand {\sectionentry {6}{Demonstration}{17}{Demonstration}{0}} -\headcommand {\beamer@sectionpages {15}{16}} -\headcommand {\beamer@subsectionpages {15}{16}} -\headcommand {\slideentry {6}{0}{17}{17/17}{}{0}} -\headcommand {\beamer@framepages {17}{17}} -\headcommand {\sectionentry {7}{Conclusions}{18}{Conclusions}{0}} -\headcommand {\beamer@sectionpages {17}{17}} -\headcommand {\beamer@subsectionpages {17}{17}} -\headcommand {\slideentry {7}{0}{18}{18/18}{}{0}} -\headcommand {\beamer@framepages {18}{18}} -\headcommand {\slideentry {7}{0}{19}{19/19}{}{0}} -\headcommand {\beamer@framepages {19}{19}} -\headcommand {\slideentry {7}{0}{20}{20/20}{}{0}} -\headcommand {\beamer@framepages {20}{20}} -\headcommand {\slideentry {7}{0}{21}{21/21}{}{0}} -\headcommand {\beamer@framepages {21}{21}} -\headcommand {\slideentry {7}{0}{22}{22/22}{}{0}} -\headcommand {\beamer@framepages {22}{22}} -\headcommand {\slideentry {7}{0}{23}{23/23}{}{0}} -\headcommand {\beamer@framepages {23}{23}} -\headcommand {\beamer@partpages {1}{23}} -\headcommand {\beamer@subsectionpages {18}{23}} -\headcommand {\beamer@sectionpages {18}{23}} -\headcommand {\beamer@documentpages {23}} -\headcommand {\def \inserttotalframenumber {23}} diff --git a/presentation/presentation.pdf b/presentation/presentation.pdf index 955ca05..95391bf 100644 Binary files a/presentation/presentation.pdf and b/presentation/presentation.pdf differ diff --git a/presentation/presentation.snm b/presentation/presentation.snm deleted file mode 100644 index e69de29..0000000 diff --git a/presentation/presentation.tex b/presentation/presentation.tex index 8b4108c..d98b820 100644 --- a/presentation/presentation.tex +++ b/presentation/presentation.tex @@ -35,7 +35,7 @@ % affiliation. \institute[UWA]% (optional) {Universities of Western Australia} -{Supervisors: Tim French, Rowan Davies} +{Supervisors: Tim French, Rowan Davies \\ Colleagues: David Gow} \date[CSS 2009]{\today} % change the actual date %\titlegraphic{\includegraphics[width=3cm]{./Logos/WAMSI.png}} @@ -95,6 +95,15 @@ \end{frame} +\begin{frame} +\begin{itemize} + \item Vector graphics scale better than raster graphics +\end{itemize} + \centering + \includegraphics[scale=0.7528125, viewport=210 85 280 150,clip, width=0.45\textwidth]{../figures/fox-vector.pdf} + \includegraphics[scale=0.7528125, viewport=0 85 70 150,clip, width=0.45\textwidth]{../figures/fox-raster.png} +\end{frame} + @@ -102,7 +111,7 @@ \begin{frame} \frametitle{Is there a zoom limit?} \centering -\includegraphics{../figures/koch1.pdf} +\includegraphics{../figures/koch.pdf} \end{frame} \section{Floating Point} @@ -112,6 +121,13 @@ \begin{itemize} \item SVG, PostScript, PDF specify IEEE-754 \emph{single} floating point number representations \item Range of values: $\approx 3 \times 10^{-38} \to 3 \times 10^{+38}$ + \item Bigger than size of Universe? +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Floating Point Definition} +\begin{itemize} \item Rough Floating Point Definition\footnote{IEEE-754 is more complicated}: \begin{align} @@ -119,7 +135,6 @@ \end{align} \item $m$ and $E$ are encoded in a \emph{fixed length} string of bits \item Floating Point $\approx$ Scientific Notation for computers - \end{itemize} \end{frame} @@ -137,6 +152,7 @@ \frametitle{Visualisation of Floats II} \begin{itemize} \item Difference between successive floats + \item Further from origin $\implies$ less precision \end{itemize} \centering \includegraphics[width=0.8\textwidth]{../figures/floats_diff.pdf} @@ -144,10 +160,15 @@ \begin{frame} \frametitle{Precision is limited} + \begin{itemize} + \item Eg: Fox scaled to width of $\approx 10^{-6}$ viewed at zoom of $\approx 10^{8}$ + \item (Outline should look like images in first slide) + \end{itemize} \centering \includegraphics[width=0.8\textwidth]{../figures/fox-vector_highzoom1.png} \end{frame} + \begin{frame} \frametitle{Structure of Vector Graphics} \begin{itemize} @@ -171,6 +192,18 @@ \includegraphics[width=0.5\textwidth]{../figures/fox-vector_face_with_bezbounds.png} \end{frame} +\begin{frame} +\frametitle{Vector Graphics Viewer Features} +\begin{itemize} + \item GPU (OpenGL) or CPU (custom) rendering + \item Import SVG into current View location + \item Control through scripts (Python) or Qt4 GUI +\end{itemize} +\centering +\includegraphics[width=0.4\textwidth]{../figures/controlpanel_screenshot.png} + +\end{frame} + \begin{frame} \frametitle{Viewing Vector Graphics} @@ -253,6 +286,16 @@ \end{frame} +\begin{frame} + \frametitle{Quantitative Results} + \begin{itemize} + \item Invariance of grid of lines after scaling + \end{itemize} + \centering + \includegraphics[width=0.8\textwidth]{../figures/cumulative_error_grid.pdf} +\end{frame} + + \section{Demonstration} @@ -282,17 +325,26 @@ \begin{itemize} \item Implement more of the SVG standard \item Trial alternative number representations - \item Allow for saving and loading SVGs with arbitrary precision + \item Allow for saving and loading + \item Optimisations, eg: clip objects that are not visible + \item Compile for Windows (MinGW) \end{itemize} \end{frame} -%\section{References} + \begin{frame} - \frametitle{References \& More information} + \frametitle{Acknowledgements} \begin{itemize} \item Work on SVG viewer collaborative with David Gow \begin{itemize} \item See David Gow's presentation about Quadtrees \end{itemize} + \item Supervisors: Tim French and Rowan Davies + \end{itemize} +\end{frame} +%\section{References} +\begin{frame} + \frametitle{References \& More information} + \begin{itemize} \item Muller et al, \emph{Handbook of Floating Point Arithmetic}, \item Hearn, Baker \emph{Computer Graphics} \item Kahan et al, \emph{IEEE-754} (1985 and 2008 revision) @@ -303,24 +355,26 @@ \end{frame} %\section{Questions} - - \begin{frame} -\frametitle{Q: Why not just increase \\ floating point precision?} -\begin{itemize} - \item Any fixed precision format will still give inexact results - \item Eg: Accuracy of rendering a grid -\end{itemize} +\frametitle{Q: Why not just increase float precision?} + \begin{itemize} + \item GPU uses singles anyway + \item Can use CPU for bounds transforms + \item But eventually lose precision for any \emph{fixed} precision float + \end{itemize} + \centering + \includegraphics[width=0.8\textwidth]{{../figures/loss_of_precision_grid_0.5}.pdf} \end{frame} \begin{frame} + \frametitle{Q: Arbitrary precision floats?} \begin{align} X &= m \times 2^{E} \end{align} \begin{itemize} \item $m$ and $E$ are of arbitrary size - \item Implemented by MPFR or GMP + \item Implemented by MPFR (based on GMP) \item Difficulties: \begin{itemize} \item Need to manually set precision (size) of $m$ @@ -329,6 +383,7 @@ \frac{1}{3} &= 0.3333333333333333333333 \text{ ... } \times 10^0 \end{align} \item How do you choose when to increase precision? + \item GMP Rational implementation automatically increases size, but MPFR floats do not \end{itemize} \end{itemize} \end{frame} @@ -345,5 +400,36 @@ \end{frame} +\begin{frame} + \frametitle{Quantitative?} +% \begin{figure}[H] + \centering + \includegraphics[width=0.4\textwidth]{../figures/grid_0_1e-6.png} + \includegraphics[width=0.4\textwidth]{../figures/{grid_0.5_1e-6}.png} \\ + \includegraphics[width=0.4\textwidth]{../figures/grid_1_1e-6.png} + \includegraphics[width=0.4\textwidth]{../figures/grid_2_1e-6.png} + %\caption{Effect of applying \eqref{view-transformation} to a grid of lines seperated by 1 pixel \\ + %a) Near origin (denormals) b), c), d) Increasing the exponent of $(v_x,v_y)$ by 1}\label{grid-precision} +%\end{figure} + + +\end{frame} + +\begin{frame} + \frametitle{Bresenham and Wu} + \centering + \includegraphics[width=0.5\textwidth]{../figures/line1.pdf} + \includegraphics[width=0.5\textwidth]{../figures/line2.pdf} +\end{frame} + +\begin{frame} + \frametitle{Bonus: IEEE-754 on GPUs} + \begin{itemize} + \item Inconsistent behaviour of calculations on different GPUs + \item {\small Eg: $x^2 + y^2 < 1$ (shading a circle) zoomed in on the edge.} + \end{itemize} + \centering + \includegraphics[width=0.4\textwidth]{../figures/gpufloats.pdf} +\end{frame} \end{document} diff --git a/presentation/presentationWORKINADOBE.pdf b/presentation/presentationWORKINADOBE.pdf new file mode 100644 index 0000000..56b9ed4 Binary files /dev/null and b/presentation/presentationWORKINADOBE.pdf differ diff --git a/thesis.pdf b/thesis.pdf index a99c352..4abdfc7 100644 Binary files a/thesis.pdf and b/thesis.pdf differ diff --git a/thesis.tex b/thesis.tex index ec75412..b3e6dee 100644 --- a/thesis.tex +++ b/thesis.tex @@ -1,5 +1,5 @@ \documentclass[a4paper,10pt,titlepage]{report} -\linespread{1.3} +\linespread{1.2} \usepackage{setspace} \onehalfspacing \parskip 10pt % sets spacing between paragraphs