diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/MESA_drm_image.spec | 149 | ||||
| -rw-r--r-- | docs/contents.html | 1 | ||||
| -rw-r--r-- | docs/developers.html | 26 | ||||
| -rw-r--r-- | docs/intro.html | 8 | ||||
| -rw-r--r-- | docs/news.html | 18 | ||||
| -rw-r--r-- | docs/relnotes-7.9.html | 4 | ||||
| -rw-r--r-- | docs/shading.html | 190 | ||||
| -rw-r--r-- | docs/subset-A.html | 3 |
8 files changed, 223 insertions, 176 deletions
diff --git a/docs/MESA_drm_image.spec b/docs/MESA_drm_image.spec new file mode 100644 index 0000000000..118501c3d3 --- /dev/null +++ b/docs/MESA_drm_image.spec @@ -0,0 +1,149 @@ +Name + + MESA_drm_image + +Name Strings + + EGL_MESA_drm_image + +Contact + + Kristian Høgsberg <krh@bitplanet.net> + +Status + + Proposal + +Version + + Version 2, August 25, 2010 + +Number + + EGL Extension #not assigned + +Dependencies + + Reguires EGL 1.4 or later. This extension is written against the + wording of the EGL 1.4 specification. + + EGL_KHR_base_image is required. + +Overview + + This extension provides entry points for integrating EGLImage with the + Linux DRM mode setting and memory management drivers. The extension + lets applications create EGLImages without a client API resource and + lets the application get the DRM buffer handles. + +IP Status + + Open-source; freely implementable. + +New Procedures and Functions + + EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy, + const EGLint *attrib_list); + + EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy, + EGLImageKHR image, + EGLint *name, + EGLint *handle, + EGLint *stride); + +New Tokens + + Accepted in the <attrib_list> parameter of eglCreateDRMImageMESA: + + EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 + EGL_DRM_BUFFER_USE_MESA 0x31D1 + + Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute: + + EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2 + + Bits accepted in EGL_DRM_BUFFER_USE_MESA: + + EGL_DRM_BUFFER_USE_SCANOUT_MESA 0x0001 + EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002 + + Accepted in the <target> parameter of eglCreateImageKHR: + + EGL_DRM_BUFFER_MESA 0x31D3 + + Use when importing drm buffer: + + EGL_DRM_BUFFER_STRIDE_MESA 0x31D4 + EGL_DRM_BUFFER_FORMAT_MESA 0x31D0 + +Additions to the EGL 1.4 Specification: + + To create a DRM EGLImage, call + + EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy, + const EGLint *attrib_list); + + In the attribute list, pass EGL_WIDTH, EGL_EIGHT and format and + use in the attrib list using EGL_DRM_BUFFER_FORMAT_MESA and + EGL_DRM_BUFFER_USE_MESA. The only format specified by this + extension is EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel + is a CPU-endian, 32-bit quantity, with alpha in the upper 8 bits, + then red, then green, then blue. The bit values accepted by + EGL_DRM_BUFFER_USE_MESA are EGL_DRM_BUFFER_USE_SCANOUT_MESA and + EGL_DRM_BUFFER_USE_SHARE_MESA. EGL_DRM_BUFFER_USE_SCANOUT_MESA + requests that the created EGLImage should be usable as a scanout + buffer with the DRM kernel modesetting API. The + EGL_DRM_BUFFER_USE_SHARE_MESA bit requests that the EGLImage can + be shared with other processes by passing the underlying DRM + buffer name. + + To create a process local handle or a global DRM name for a + buffer, call + + EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy, + EGLImageKHR image, + EGLint *name, + EGLint *handle, + EGLint *stride); + + If <name> is non-NULL, a global name is assigned to the image and + written to <name>, the handle (local to the DRM file descriptor, + for use with DRM kernel modesetting API) is written to <handle> if + non-NULL and the stride (in bytes) is written to <stride>, if + non-NULL. + + Import a shared buffer by calling eglCreateImageKHR with + EGL_DRM_BUFFER_MESA as the target, using EGL_WIDTH, EGL_HEIGHT, + EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_STRIDE_MESA + in the attrib list. + +Issues + + 1. Why don't we use eglCreateImageKHR with a target that + indicates that we want to create an EGLImage from scratch? + + RESOLVED: The eglCreateImageKHR entry point is reserved for + creating an EGLImage from an already existing client API + resource. This is fine when we're creating the EGLImage from + an existing DRM buffer name, it doesn't seem right to overload + the function to also allocate the underlying resource. + + 2. Why don't we use an eglQueryImageMESA type functions for + querying the DRM EGLImage attributes (name, handle, and stride)? + + RESOLVED: The eglQueryImage function has been proposed often, + but it goes against the EGLImage design. EGLImages are opaque + handles to a 2D array of pixels, which can be passed between + client APIs. By referenceing an EGLImage in a client API, the + EGLImage target (a texture, a renderbuffer or such) can be + used to query the attributes of the EGLImage. We don't have a + full client API for creating and querying DRM buffers, though, + so we use a new EGL extension entry point instead. + +Revision History + + Version 1, June 3, 2010 + Initial draft (Kristian Høgsberg) + Version 2, August 25, 2010 + Flesh out the extension a bit, add final EGL tokens, capture + some of the original discussion in the issues section. diff --git a/docs/contents.html b/docs/contents.html index cca20ecaae..cf1661e4ea 100644 --- a/docs/contents.html +++ b/docs/contents.html @@ -69,7 +69,6 @@ a:visited { <li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a> <li><a href="repository.html" target="MainFrame">Source Code Repository</a> <li><a href="sourcetree.html" target="MainFrame">Source Code Tree</a> -<li><a href="memory.html" target="MainFrame">DRI Memory Management</a> <li><a href="glu.html" target="MainFrame">SGI's GLU</a> <li><a href="utilities.html" target="MainFrame">Utilities</a> <li><a href="helpwanted.html" target="MainFrame">Help Wanted</a> diff --git a/docs/developers.html b/docs/developers.html index 410f1ac5e8..8960e7cb48 100644 --- a/docs/developers.html +++ b/docs/developers.html @@ -12,12 +12,14 @@ Both professional and volunteer developers contribute to Mesa. </p> <p> -<a href="http://www.tungstengraphics.com/" target="_parent">Tungsten Graphics</a> +<a href="http://www.vmware.com/" target="_parent">VMware</a> employs several of the main Mesa developers including Brian Paul and Keith Whitwell. -Much of the on-going work in Mesa is done through Tungsten Graphics engineering -contracts. -Prominent examples of this work includes: +</p> + +<p> +In the past, Tungsten Graphics contracts implemented many Mesa features +including: </p> <ul> <li>DRI drivers for Intel i965, i945, i915 and other chips @@ -29,23 +31,19 @@ Prominent examples of this work includes: <p> Other companies including <a href="http://www.intellinuxgraphics.org/index.html" target="_parent">Intel</a> -and IBM also actively contribute to the project. +and RedHat also actively contribute to the project. +Intel has recently contributed the new GLSL compiler in Mesa 7.9. </p> <p> -Volunteers have made significant contributions to all parts of Mesa, including -complete device drivers. +<a href="http://www.lunarg.com/" target="_parent">LunarG</a> can be contacted +for custom Mesa / 3D graphics development. </p> - -<H1>Custom Development</H1> <p> -Contact <a href="http://www.tungstengraphics.com/" target="_parent"> -Tungsten Graphics</a> -for information about custom development in Mesa, OpenGL, X and other -graphics technologies. +Volunteers have made significant contributions to all parts of Mesa, including +complete device drivers. </p> - </body> </html> diff --git a/docs/intro.html b/docs/intro.html index aae2e6e192..0806caf388 100644 --- a/docs/intro.html +++ b/docs/intro.html @@ -111,11 +111,9 @@ It implements the OpenGL 1.3 specification. <p> -November 2001: I cofound <a href="http://www.tungstengraphics.com" target="_parent"> -Tungsten Graphics, Inc.</a> with Keith Whitwell, Jens Owen, David Dawes and -Frank LaMonica. -I continue to develop Mesa as part of my resposibilities with Tungsten -Graphics and as a spare-time project. +November 2001: I cofounded Tungsten Graphics, Inc. with Keith Whitwell, +Jens Owen, David Dawes and Frank LaMonica. +Tungsten Graphics was acquired by VMware in December 2008. </p> <p> diff --git a/docs/news.html b/docs/news.html index b7731cdaf3..09385ad35e 100644 --- a/docs/news.html +++ b/docs/news.html @@ -11,6 +11,14 @@ <H1>News</H1> +<h2>June 16, 2010</h2> + +<p> +<a href="relnotes-7.8.2.html">Mesa 7.8.2</a> is released. This is a bug-fix +release collecting fixes since the 7.8.1 release. +</p> + + <h2>April 5, 2010</h2> <p> @@ -157,9 +165,6 @@ Added a new page describing the <a href="cell.html">Mesa Cell driver</a>. <p> Gallium3D is the codename for the new Mesa device driver architecture which is currently under development. -A <a href="http://wiki.freedesktop.org/wiki/Software/gallium" -target="_parent"> summary</a> of the architecture can be found on the -Tungsten Graphics website. </p> <p> Gallium3D development is taking place on the <em>gallium-0.1</em> branch @@ -210,11 +215,8 @@ shading language and built-in functions. <h2>April 2007</h2> <p> -Thomas Hellström of -<a href="http://www.tungstengraphics.com" target="_parent"> -Tungsten Graphics</a> has written a whitepaper describing the new -<a href="http://www.tungstengraphics.com/mm.pdf">DRI memory management -system</a>. +Thomas Hellström of Tungsten Graphics has written a whitepaper +describing the new DRI memory management system</a>. </p> <h2>December 5, 2006</h2> diff --git a/docs/relnotes-7.9.html b/docs/relnotes-7.9.html index 457dd8fd05..2cc7c4ec62 100644 --- a/docs/relnotes-7.9.html +++ b/docs/relnotes-7.9.html @@ -34,7 +34,11 @@ tbd <h2>New features</h2> <ul> +<li>New, improved GLSL compiler written by Intel. + See the <a href="shading.html"> Shading Language</a> page for + more information. <li>GL_EXT_timer_query extension (i965 driver only) +<li>GL_EXT_framebuffer_multisample extension (intel drivers, MAX_SAMPLES = 1) <li>GL_ARB_texture_swizzle extension (alias of GL_EXT_texture_swizzle) <li>GL_ARB_draw_elements_base_vertex, GL_ARB_fragment_program_shadow and GL_EXT_draw_buffers2 in Gallium drivers diff --git a/docs/shading.html b/docs/shading.html index 750884cf36..c41d4a9be2 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -39,19 +39,19 @@ list of keywords to control some aspects of the GLSL compiler and shader execution. These are generally used for debugging. </p> <ul> -<li>dump - print GLSL shader code to stdout at link time -<li>log - log all GLSL shaders to files. +<li><b>dump</b> - print GLSL shader code to stdout at link time +<li><b>log</b> - log all GLSL shaders to files. The filenames will be "shader_X.vert" or "shader_X.frag" where X the shader ID. -<li>nopt - disable compiler optimizations -<li>opt - force compiler optimizations -<li>uniform - print message to stdout when glUniform is called -<li>nopvert - force vertex shaders to be a simple shader that just transforms +<li><b>nopt</b> - disable compiler optimizations +<li><b>opt</b> - force compiler optimizations +<li><b>uniform</b> - print message to stdout when glUniform is called +<li><b>nopvert</b> - force vertex shaders to be a simple shader that just transforms the vertex position with ftransform() and passes through the color and texcoord[0] attributes. -<li>nopfrag - force fragment shader to be a simple shader that passes +<li><b>nopfrag</b> - force fragment shader to be a simple shader that passes through the color attribute. -<li>useprog - log glUseProgram calls to stderr +<li><b>useprog</b> - log glUseProgram calls to stderr </ul> <p> Example: export MESA_GLSL=dump,nopt @@ -59,30 +59,28 @@ Example: export MESA_GLSL=dump,nopt <a name="120"> -<h2>GLSL 1.20 support</h2> +<h2>GLSL Version</h2> <p> -GLSL version 1.20 is supported in Mesa 7.3 and later. -Among the features/differences of GLSL 1.20 are: +The GLSL compiler currently supports version 1.20 of the shading language. +</p> + +<p> +Several GLSL extensions are also supported: +</p> <ul> -<li><code>mat2x3, mat2x4</code>, etc. types and functions -<li><code>transpose(), outerProduct(), matrixCompMult()</code> functions -(but untested) -<li>precision qualifiers (lowp, mediump, highp) -<li><code>invariant</code> qualifier -<li><code>array.length()</code> method -<li><code>float[5] a;</code> array syntax -<li><code>centroid</code> qualifier -<li>unsized array constructors -<li>initializers for uniforms -<li>const initializers calling built-in functions +<li>GL_ARB_draw_buffers +<li>GL_ARB_texture_rectangle +<li>GL_ARB_fragment_coord_conventions +<li>GL_EXT_texture_array </ul> - <a name="unsup"> <h2>Unsupported Features</h2> +<p>XXX update this section</p> + <p> The following features of the shading language are not yet fully supported in Mesa: @@ -130,39 +128,6 @@ These issues will be addressed/resolved in the future. <h2>Programming Hints</h2> <ul> -<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible. - This improves the efficiency of function inlining. -</li> -<br> -<li>To reduce register usage, declare variables within smaller scopes. - For example, the following code: -<pre> - void main() - { - vec4 a1, a2, b1, b2; - gl_Position = expression using a1, a2. - gl_Color = expression using b1, b2; - } -</pre> - Can be rewritten as follows to use half as many registers: -<pre> - void main() - { - { - vec4 a1, a2; - gl_Position = expression using a1, a2. - } - { - vec4 b1, b2; - gl_Color = expression using b1, b2; - } - } -</pre> - Alternately, rather than using several float variables, use - a vec4 instead. Use swizzling and writemasks to access the - components of the vec4 as floats. -</li> -<br> <li>Use the built-in library functions whenever possible. For example, instead of writing this: <pre> @@ -172,8 +137,6 @@ These issues will be addressed/resolved in the future. <pre> float x = inversesqrt(y); </pre> -<li> - Use ++i when possible as it's more efficient than i++ </li> </ul> @@ -182,13 +145,8 @@ These issues will be addressed/resolved in the future. <h2>Stand-alone GLSL Compiler</h2> <p> -A unique stand-alone GLSL compiler driver has been added to Mesa. -<p> - -<p> -The stand-alone compiler (like a conventional command-line compiler) -is a tool that accepts Shading Language programs and emits low-level -GPU programs. +The stand-alone GLSL compiler program can be used to compile GLSL shaders +into low-level GPU code. </p> <p> @@ -201,59 +159,25 @@ This tool is useful for: </ul> <p> -After building Mesa, the glslcompiler can be built by manually running: +After building Mesa, the compiler can be found at src/glsl/glsl_compiler </p> -<pre> - make realclean - make linux - cd src/mesa/drivers/glslcompiler - make -</pre> - <p> Here's an example of using the compiler to compile a vertex shader and emit GL_ARB_vertex_program-style instructions: </p> <pre> - bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt -</pre> -<p> -results in: -</p> -<pre> -# Fragment Program/Shader - 0: RCP TEMP[4].x, UNIFORM[2].xxxx; - 1: RCP TEMP[4].y, UNIFORM[2].yyyy; - 2: MUL TEMP[3].xy, VARYING[0], TEMP[4]; - 3: MOV TEMP[1], TEMP[3]; - 4: MUL TEMP[0].w, TEMP[1].yyyy, CONST[4].xxxx; - 5: FRC TEMP[1].z, TEMP[0].wwww; - 6: SGT.C TEMP[0].w, TEMP[1].zzzz, CONST[4].xxxx; - 7: IF (NE.wwww); # (if false, goto 9); - 8: ADD TEMP[1].x, TEMP[1].xxxx, CONST[4].xxxx; - 9: ENDIF; - 10: FRC TEMP[1].xy, TEMP[1]; - 11: SGT TEMP[2].xy, UNIFORM[3], TEMP[1]; - 12: MUL TEMP[1].z, TEMP[2].xxxx, TEMP[2].yyyy; - 13: LRP TEMP[0], TEMP[1].zzzz, UNIFORM[0], UNIFORM[1]; - 14: MUL TEMP[0].xyz, TEMP[0], VARYING[1].xxxx; - 15: MOV OUTPUT[0].xyz, TEMP[0]; - 16: MOV OUTPUT[0].w, CONST[4].yyyy; - 17: END + src/glsl/glslcompiler --dump-ast myshader.vert </pre> -<p> -Note that some shading language constructs (such as uniform and varying -variables) aren't expressible in ARB or NV-style programs. -Therefore, the resulting output is not always legal by definition of -those program languages. -</p> -<p> -Also note that this compiler driver is still under development. -Over time, the correctness of the GPU programs, with respect to the ARB -and NV languagues, should improve. -</p> +Options include +<ul> +<li><b>--dump-ast</b> - dump GPU code +<li><b>--dump-hir</b> - dump high-level IR code +<li><b>--dump-lir</b> - dump low-level IR code +<li><b>--link</b> - ??? +</ul> + @@ -262,38 +186,12 @@ and NV languagues, should improve. <p> The source code for Mesa's shading language compiler is in the -<code>src/mesa/shader/slang/</code> directory. +<code>src/glsl/</code> directory. </p> <p> -The compiler follows a fairly standard design and basically works as follows: +XXX provide some info about the compiler.... </p> -<ul> -<li>The input string is tokenized (see grammar.c) and parsed -(see slang_compiler_*.c) to produce an Abstract Syntax Tree (AST). -The nodes in this tree are slang_operation structures -(see slang_compile_operation.h). -The nodes are decorated with symbol table, scoping and datatype information. -<li>The AST is converted into an Intermediate representation (IR) tree -(see the slang_codegen.c file). -The IR nodes represent basic GPU instructions, like add, dot product, -move, etc. -The IR tree is mostly a binary tree, but a few nodes have three or four -children. -In principle, the IR tree could be executed by doing an in-order traversal. -<li>The IR tree is traversed in-order to emit code (see slang_emit.c). -This is also when registers are allocated to store variables and temps. -<li>In the future, a pattern-matching code generator-generator may be -used for code generation. -Programs such as L-BURG (Bottom-Up Rewrite Generator) and Twig look for -patterns in IR trees, compute weights for subtrees and use the weights -to select the best instructions to represent the sub-tree. -<li>The emitted GPU instructions (see prog_instruction.h) are stored in a -gl_program object (see mtypes.h). -<li>When a fragment shader and vertex shader are linked (see slang_link.c) -the varying vars are matched up, uniforms are merged, and vertex -attributes are resolved (rewriting instructions as needed). -</ul> <p> The final vertex and fragment programs may be interpreted in software @@ -351,20 +249,20 @@ Extra NOP instructions will also be inserted. <h2>Compiler Validation</h2> <p> -A <a href="http://glean.sf.net" target="_parent">Glean</a> test has -been create to exercise the GLSL compiler. -</p> -<p> -The <em>glsl1</em> test runs over 170 sub-tests to check that the language -features and built-in functions work properly. -This test should be run frequently while working on the compiler to catch +Developers working on the GLSL compiler should test frequently to avoid regressions. </p> + <p> -The test coverage is reasonably broad and complete but additional tests -should be added. +The <a href="http://people.freedesktop.org/~nh/piglit/">Piglit</a> project +has many GLSL tests and the +<a href="http://glean.sf.net" target="_parent">Glean</a> glsl1 test +tests GLSL features. </p> +<p> +The Mesa demos repository also has some good GLSL tests. +</p> </BODY> </HTML> diff --git a/docs/subset-A.html b/docs/subset-A.html index dac66a61ba..d576bb6744 100644 --- a/docs/subset-A.html +++ b/docs/subset-A.html @@ -16,8 +16,7 @@ </h3> </center> </h2> -<p> Copyright © 2002-2003 by <a - href="http://www.tungstengraphics.com/">Tungsten Graphics, Inc.</a>, +<p> Copyright © 2002-2003 by Tungsten Graphics, Inc., Cedar Park, Texas. All Rights Reserved. <br> <br> Permission is granted to make and distribute verbatim copies of this |