mirror of
https://gitee.com/openharmony/third_party_mesa3d
synced 2025-02-21 10:41:48 +00:00
docs: remove leading spaces
There's no good reason to have leading space in these pre-formatted blocks. It looks strange, so let's get rid of it. Reviewed-by: Eric Engestrom <eric@engestrom.ch> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3443>
This commit is contained in:
Erik Faye-Lund
parent
c871862744
commit
9954120b38
@ -41,11 +41,11 @@ as if you're defining a large, static table of information.
|
||||
<li>Opening braces go on the same line as the if/for/while statement.
|
||||
For example:
|
||||
<pre>
|
||||
if (condition) {
|
||||
foo;
|
||||
} else {
|
||||
bar;
|
||||
}
|
||||
if (condition) {
|
||||
foo;
|
||||
} else {
|
||||
bar;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<li>Put a space before/after operators. For example, <code>a = b + c;</code>
|
||||
@ -53,7 +53,7 @@ and not <code>a=b+c;</code>
|
||||
|
||||
<li>This GNU indent command generally does the right thing for formatting:
|
||||
<pre>
|
||||
indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
|
||||
indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
|
||||
</pre>
|
||||
|
||||
<li>
|
||||
@ -63,47 +63,47 @@ follow <a href="http://www.doxygen.nl">Doxygen</a> conventions.
|
||||
</p>
|
||||
Single-line comments:
|
||||
<pre>
|
||||
/* null-out pointer to prevent dangling reference below */
|
||||
bufferObj = NULL;
|
||||
/* null-out pointer to prevent dangling reference below */
|
||||
bufferObj = NULL;
|
||||
</pre>
|
||||
Or,
|
||||
<pre>
|
||||
bufferObj = NULL; /* prevent dangling reference below */
|
||||
bufferObj = NULL; /* prevent dangling reference below */
|
||||
</pre>
|
||||
Multi-line comment:
|
||||
<pre>
|
||||
/* If this is a new buffer object id, or one which was generated but
|
||||
* never used before, allocate a buffer object now.
|
||||
*/
|
||||
/* If this is a new buffer object id, or one which was generated but
|
||||
* never used before, allocate a buffer object now.
|
||||
*/
|
||||
</pre>
|
||||
We try to quote the OpenGL specification where prudent:
|
||||
<pre>
|
||||
/* Page 38 of the PDF of the OpenGL ES 3.0 spec says:
|
||||
*
|
||||
* "An INVALID_OPERATION error is generated for any of the following
|
||||
* conditions:
|
||||
*
|
||||
* * <length> is zero."
|
||||
*
|
||||
* Additionally, page 94 of the PDF of the OpenGL 4.5 core spec
|
||||
* (30.10.2014) also says this, so it's no longer allowed for desktop GL,
|
||||
* either.
|
||||
*/
|
||||
/* Page 38 of the PDF of the OpenGL ES 3.0 spec says:
|
||||
*
|
||||
* "An INVALID_OPERATION error is generated for any of the following
|
||||
* conditions:
|
||||
*
|
||||
* * <length> is zero."
|
||||
*
|
||||
* Additionally, page 94 of the PDF of the OpenGL 4.5 core spec
|
||||
* (30.10.2014) also says this, so it's no longer allowed for desktop GL,
|
||||
* either.
|
||||
*/
|
||||
</pre>
|
||||
Function comment example:
|
||||
<pre>
|
||||
/**
|
||||
* Create and initialize a new buffer object. Called via the
|
||||
* ctx->Driver.CreateObject() driver callback function.
|
||||
* \param name integer name of the object
|
||||
* \param type one of GL_FOO, GL_BAR, etc.
|
||||
* \return pointer to new object or NULL if error
|
||||
*/
|
||||
struct gl_object *
|
||||
_mesa_create_object(GLuint name, GLenum type)
|
||||
{
|
||||
/* function body */
|
||||
}
|
||||
/**
|
||||
* Create and initialize a new buffer object. Called via the
|
||||
* ctx->Driver.CreateObject() driver callback function.
|
||||
* \param name integer name of the object
|
||||
* \param type one of GL_FOO, GL_BAR, etc.
|
||||
* \return pointer to new object or NULL if error
|
||||
*/
|
||||
struct gl_object *
|
||||
_mesa_create_object(GLuint name, GLenum type)
|
||||
{
|
||||
/* function body */
|
||||
}
|
||||
</pre>
|
||||
|
||||
<li>Put the function return type and qualifiers on one line and the function
|
||||
@ -113,11 +113,11 @@ the opening brace goes on the next line by itself (see above.)
|
||||
|
||||
<li>Function names follow various conventions depending on the type of function:
|
||||
<pre>
|
||||
glFooBar() - a public GL entry point (in glapi_dispatch.c)
|
||||
_mesa_FooBar() - the internal immediate mode function
|
||||
save_FooBar() - retained mode (display list) function in dlist.c
|
||||
foo_bar() - a static (private) function
|
||||
_mesa_foo_bar() - an internal non-static Mesa function
|
||||
glFooBar() - a public GL entry point (in glapi_dispatch.c)
|
||||
_mesa_FooBar() - the internal immediate mode function
|
||||
save_FooBar() - retained mode (display list) function in dlist.c
|
||||
foo_bar() - a static (private) function
|
||||
_mesa_foo_bar() - an internal non-static Mesa function
|
||||
</pre>
|
||||
|
||||
<li>Constants, macros and enum names are <code>ALL_UPPERCASE</code>, with _
|
||||
|
||||
@ -56,7 +56,7 @@ It's the fastest software rasterizer for Mesa.
|
||||
For Linux, on a recent Debian based distribution do:
|
||||
</p>
|
||||
<pre>
|
||||
aptitude install llvm-dev
|
||||
aptitude install llvm-dev
|
||||
</pre>
|
||||
<p>
|
||||
If you want development snapshot builds of LLVM for Debian and derived
|
||||
@ -68,7 +68,7 @@ It's the fastest software rasterizer for Mesa.
|
||||
For a RPM-based distribution do:
|
||||
</p>
|
||||
<pre>
|
||||
yum install llvm-devel
|
||||
yum install llvm-devel
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -120,15 +120,15 @@ It's the fastest software rasterizer for Mesa.
|
||||
To build everything on Linux invoke scons as:
|
||||
|
||||
<pre>
|
||||
scons build=debug libgl-xlib
|
||||
scons build=debug libgl-xlib
|
||||
</pre>
|
||||
|
||||
Alternatively, you can build it with meson with:
|
||||
<pre>
|
||||
mkdir build
|
||||
cd build
|
||||
meson -D glx=gallium-xlib -D gallium-drivers=swrast
|
||||
ninja
|
||||
mkdir build
|
||||
cd build
|
||||
meson -D glx=gallium-xlib -D gallium-drivers=swrast
|
||||
ninja
|
||||
</pre>
|
||||
|
||||
but the rest of these instructions assume that scons is used.
|
||||
@ -136,7 +136,7 @@ but the rest of these instructions assume that scons is used.
|
||||
For Windows the procedure is similar except the target:
|
||||
|
||||
<pre>
|
||||
scons platform=windows build=debug libgl-gdi
|
||||
scons platform=windows build=debug libgl-gdi
|
||||
</pre>
|
||||
|
||||
|
||||
@ -148,11 +148,11 @@ For Windows the procedure is similar except the target:
|
||||
<code>libGL.so</code> into</p>
|
||||
|
||||
<pre>
|
||||
build/foo/gallium/targets/libgl-xlib/libGL.so
|
||||
build/foo/gallium/targets/libgl-xlib/libGL.so
|
||||
</pre>
|
||||
or
|
||||
<pre>
|
||||
lib/gallium/libGL.so
|
||||
lib/gallium/libGL.so
|
||||
</pre>
|
||||
|
||||
<p>To use it set the <code>LD_LIBRARY_PATH</code> environment variable
|
||||
@ -206,7 +206,7 @@ any OpenGL drivers):
|
||||
To profile llvmpipe you should build as
|
||||
</p>
|
||||
<pre>
|
||||
scons build=profile <same-as-before>
|
||||
scons build=profile <same-as-before>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -221,8 +221,8 @@ On Linux, it is possible to have symbol resolution of JIT code with <a href="htt
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
perf record -g /my/application
|
||||
perf report
|
||||
perf record -g /my/application
|
||||
perf report
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -255,7 +255,7 @@ Some of these tests can output results and benchmarks to a tab-separated file
|
||||
for later analysis, e.g.:
|
||||
</p>
|
||||
<pre>
|
||||
build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
|
||||
build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
|
||||
</pre>
|
||||
|
||||
|
||||
|
||||
@ -68,15 +68,15 @@ The easiest way to install everything you need is with <a
|
||||
href="https://chocolatey.org/">chocolatey</a>.
|
||||
</p>
|
||||
<pre>
|
||||
choco install python3 winflexbison pkgconfiglite
|
||||
choco install python3 winflexbison pkgconfiglite
|
||||
</pre>
|
||||
<p>You can even use chocolatey to install mingw and ninja (ninja can be used with MSVC as well)</p>
|
||||
<pre>
|
||||
choco install ninja mingw
|
||||
choco install ninja mingw
|
||||
</pre>
|
||||
<p>Then install meson using pip</p>
|
||||
<pre>
|
||||
py -3 -m pip install meson mako
|
||||
py -3 -m pip install meson mako
|
||||
</pre>
|
||||
|
||||
You may need to add the python3 scripts directory to your path for meson.
|
||||
@ -283,7 +283,7 @@ which points to the root of an alternative installation (the prefix). For
|
||||
example:
|
||||
</p>
|
||||
<pre>
|
||||
meson builddir -Dcmake_module_path=/home/user/mycmake/prefix
|
||||
meson builddir -Dcmake_module_path=/home/user/mycmake/prefix
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -296,14 +296,14 @@ find llvm-config:
|
||||
|
||||
custom-llvm.ini
|
||||
<pre>
|
||||
[binaries]
|
||||
llvm-config = '/usr/local/bin/llvm/llvm-config'
|
||||
[binaries]
|
||||
llvm-config = '/usr/local/bin/llvm/llvm-config'
|
||||
</pre>
|
||||
|
||||
Then configure meson:
|
||||
|
||||
<pre>
|
||||
meson builddir/ --native-file custom-llvm.ini
|
||||
meson builddir/ --native-file custom-llvm.ini
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -325,17 +325,17 @@ should be used. It uses the same format as the native file above:
|
||||
|
||||
<p>cross-llvm.ini</p>
|
||||
<pre>
|
||||
[binaries]
|
||||
...
|
||||
llvm-config = '/usr/lib/llvm-config-32'
|
||||
cmake = '/usr/bin/cmake-for-my-arch'
|
||||
[binaries]
|
||||
...
|
||||
llvm-config = '/usr/lib/llvm-config-32'
|
||||
cmake = '/usr/bin/cmake-for-my-arch'
|
||||
</pre>
|
||||
|
||||
<p>Obviously, only cmake or llvm-config is required.</p>
|
||||
|
||||
<p>Then configure meson:</p>
|
||||
<pre>
|
||||
meson builddir/ --cross-file cross-llvm.ini
|
||||
meson builddir/ --cross-file cross-llvm.ini
|
||||
</pre>
|
||||
|
||||
See the <a href="#cross-compilation">Cross Compilation</a> section for more information.
|
||||
|
||||
@ -46,10 +46,10 @@ while the latter have a non-zero one.
|
||||
For example:
|
||||
</p>
|
||||
<pre>
|
||||
Mesa 10.1.0 - 10.1 branch, feature
|
||||
Mesa 10.1.4 - 10.1 branch, bugfix
|
||||
Mesa 12.0.0 - 12.0 branch, feature
|
||||
Mesa 12.0.2 - 12.0 branch, bugfix
|
||||
Mesa 10.1.0 - 10.1 branch, feature
|
||||
Mesa 10.1.4 - 10.1 branch, bugfix
|
||||
Mesa 12.0.0 - 12.0 branch, feature
|
||||
Mesa 12.0.2 - 12.0 branch, bugfix
|
||||
</pre>
|
||||
|
||||
|
||||
@ -183,27 +183,27 @@ This should be noted in the <a href="#prerelease">pre-announce</a> email.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git show b10859ec41d09c57663a258f43fe57c12332698e
|
||||
git show b10859ec41d09c57663a258f43fe57c12332698e
|
||||
|
||||
commit b10859ec41d09c57663a258f43fe57c12332698e
|
||||
Author: Jonas Pfeil <pfeiljonas@gmx.de>
|
||||
Date: Wed Mar 1 18:11:10 2017 +0100
|
||||
commit b10859ec41d09c57663a258f43fe57c12332698e
|
||||
Author: Jonas Pfeil <pfeiljonas@gmx.de>
|
||||
Date: Wed Mar 1 18:11:10 2017 +0100
|
||||
|
||||
ralloc: Make sure ralloc() allocations match malloc()'s alignment.
|
||||
ralloc: Make sure ralloc() allocations match malloc()'s alignment.
|
||||
|
||||
The header of ralloc needs to be aligned, because the compiler assumes
|
||||
...
|
||||
The header of ralloc needs to be aligned, because the compiler assumes
|
||||
...
|
||||
|
||||
(cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
|
||||
(cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
|
||||
|
||||
Squashed with commit:
|
||||
Squashed with commit:
|
||||
|
||||
ralloc: don't leave out the alignment factor
|
||||
ralloc: don't leave out the alignment factor
|
||||
|
||||
Experimentation shows that without alignment factor gcc and clang choose
|
||||
...
|
||||
Experimentation shows that without alignment factor gcc and clang choose
|
||||
...
|
||||
|
||||
(cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
|
||||
(cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
|
||||
</pre>
|
||||
|
||||
<h2>Regression/functionality testing</h2>
|
||||
@ -236,8 +236,8 @@ A live branch, which contains the currently merge/rejected patches is available
|
||||
in the main repository under <code>staging/X.Y</code>. For example:
|
||||
</p>
|
||||
<pre>
|
||||
staging/18.1 - WIP branch for the 18.1 series
|
||||
staging/18.2 - WIP branch for the 18.2 series
|
||||
staging/18.1 - WIP branch for the 18.1 series
|
||||
staging/18.2 - WIP branch for the 18.2 series
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -271,15 +271,15 @@ Check if the version number is going to remain as, alternatively
|
||||
To setup the branchpoint:
|
||||
</p>
|
||||
<pre>
|
||||
git checkout master # make sure we're in master first
|
||||
git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
|
||||
git checkout -b X.Y
|
||||
git checkout master
|
||||
$EDITOR VERSION # bump the version number
|
||||
git commit -as
|
||||
cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
|
||||
git commit -as
|
||||
git push origin X.Y-branchpoint X.Y
|
||||
git checkout master # make sure we're in master first
|
||||
git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
|
||||
git checkout -b X.Y
|
||||
git checkout master
|
||||
$EDITOR VERSION # bump the version number
|
||||
git commit -as
|
||||
cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
|
||||
git commit -as
|
||||
git push origin X.Y-branchpoint X.Y
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -482,38 +482,38 @@ So we do a quick 'touch test'
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
__glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
|
||||
__es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
|
||||
__es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
|
||||
test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
|
||||
export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
|
||||
export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
|
||||
export LIBGL_DEBUG=verbose
|
||||
eval $__glxinfo_cmd
|
||||
eval $__glxgears_cmd
|
||||
eval $__es2info_cmd
|
||||
eval $__es2gears_cmd
|
||||
export LIBGL_ALWAYS_SOFTWARE=true
|
||||
eval $__glxinfo_cmd
|
||||
eval $__glxgears_cmd
|
||||
eval $__es2info_cmd
|
||||
eval $__es2gears_cmd
|
||||
export LIBGL_ALWAYS_SOFTWARE=true
|
||||
export GALLIUM_DRIVER=softpipe
|
||||
eval $__glxinfo_cmd
|
||||
eval $__glxgears_cmd
|
||||
eval $__es2info_cmd
|
||||
eval $__es2gears_cmd
|
||||
# Smoke test DOTA2
|
||||
unset LD_LIBRARY_PATH
|
||||
test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
|
||||
unset LIBGL_DRIVERS_PATH
|
||||
unset LIBGL_DEBUG
|
||||
unset LIBGL_ALWAYS_SOFTWARE
|
||||
unset GALLIUM_DRIVER
|
||||
export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
|
||||
steam steam://rungameid/570 -vconsole -vulkan
|
||||
unset VK_ICD_FILENAMES
|
||||
__glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
|
||||
__es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
|
||||
__es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
|
||||
test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
|
||||
export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
|
||||
export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
|
||||
export LIBGL_DEBUG=verbose
|
||||
eval $__glxinfo_cmd
|
||||
eval $__glxgears_cmd
|
||||
eval $__es2info_cmd
|
||||
eval $__es2gears_cmd
|
||||
export LIBGL_ALWAYS_SOFTWARE=true
|
||||
eval $__glxinfo_cmd
|
||||
eval $__glxgears_cmd
|
||||
eval $__es2info_cmd
|
||||
eval $__es2gears_cmd
|
||||
export LIBGL_ALWAYS_SOFTWARE=true
|
||||
export GALLIUM_DRIVER=softpipe
|
||||
eval $__glxinfo_cmd
|
||||
eval $__glxgears_cmd
|
||||
eval $__es2info_cmd
|
||||
eval $__es2gears_cmd
|
||||
# Smoke test DOTA2
|
||||
unset LD_LIBRARY_PATH
|
||||
test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
|
||||
unset LIBGL_DRIVERS_PATH
|
||||
unset LIBGL_DEBUG
|
||||
unset LIBGL_ALWAYS_SOFTWARE
|
||||
unset GALLIUM_DRIVER
|
||||
export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
|
||||
steam steam://rungameid/570 -vconsole -vulkan
|
||||
unset VK_ICD_FILENAMES
|
||||
</pre>
|
||||
|
||||
<h3>Create release notes for the new release</h3>
|
||||
@ -538,7 +538,7 @@ Commit these changes and push the branch.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git push origin HEAD
|
||||
git push origin HEAD
|
||||
</pre>
|
||||
|
||||
|
||||
@ -549,9 +549,9 @@ Start the release process.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# For the dist/distcheck, you may want to specify which LLVM to use:
|
||||
# export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
|
||||
../relative/path/to/release.sh . # append --dist if you've already done distcheck above
|
||||
# For the dist/distcheck, you may want to specify which LLVM to use:
|
||||
# export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
|
||||
../relative/path/to/release.sh . # append --dist if you've already done distcheck above
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -572,8 +572,8 @@ Something like the following steps will do the trick:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git cherry-pick -x X.Y~1
|
||||
git cherry-pick -x X.Y
|
||||
git cherry-pick -x X.Y~1
|
||||
git cherry-pick -x X.Y
|
||||
</pre>
|
||||
|
||||
<p>Then run the <code>./bin/post_verison.py X.Y.Z</code>, where X.Y.Z is the
|
||||
@ -582,8 +582,8 @@ docs/index.html. Remove docs/release-calendar.html. Then commit and push:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
|
||||
git push origin master X.Y
|
||||
git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
|
||||
git push origin master X.Y
|
||||
</pre>
|
||||
|
||||
|
||||
|
||||
@ -102,7 +102,7 @@ using git on Windows</a> you'll want to enable automatic CR/LF conversion in
|
||||
your local copy of the repository:
|
||||
</p>
|
||||
<pre>
|
||||
git config --global core.autocrlf true
|
||||
git config --global core.autocrlf true
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -141,8 +141,8 @@ If you try to do a pull by just saying<code> git pull </code>
|
||||
and git complains that you have not specified a
|
||||
branch, try:
|
||||
<pre>
|
||||
git config branch.master.remote origin
|
||||
git config branch.master.merge master
|
||||
git config branch.master.remote origin
|
||||
git config branch.master.merge master
|
||||
</pre>
|
||||
<p>
|
||||
Otherwise, you have to say<code> git pull origin master </code>
|
||||
@ -161,7 +161,7 @@ unnecessary and distracting branch in master.
|
||||
<p>
|
||||
If it has been awhile since you've done the initial clone, try
|
||||
<pre>
|
||||
git pull
|
||||
git pull
|
||||
</pre>
|
||||
<p>
|
||||
to get the latest files before you start working.
|
||||
@ -169,8 +169,8 @@ to get the latest files before you start working.
|
||||
<p>
|
||||
Make your changes and use
|
||||
<pre>
|
||||
git add <files to commit>
|
||||
git commit
|
||||
git add <files to commit>
|
||||
git commit
|
||||
</pre>
|
||||
<p>
|
||||
to get your changes ready to push back into the fd.o repository.
|
||||
@ -185,8 +185,8 @@ where you did your last pull and merging it to a point after the other changes.
|
||||
<p>
|
||||
To avoid this,
|
||||
<pre>
|
||||
git pull --rebase
|
||||
git push
|
||||
git pull --rebase
|
||||
git push
|
||||
</pre>
|
||||
<p>
|
||||
If you are familiar with CVS or similar system, this is similar to doing a
|
||||
@ -207,8 +207,8 @@ those before doing the push.
|
||||
<p>
|
||||
If you want the rebase action to be the default action, then
|
||||
<pre>
|
||||
git config branch.master.rebase true
|
||||
git config --global branch.autosetuprebase=always
|
||||
git config branch.master.rebase true
|
||||
git config --global branch.autosetuprebase=always
|
||||
</pre>
|
||||
<p>
|
||||
See <a href="https://www.eecs.harvard.edu/~cduan/technical/git/">Understanding Git Conceptually</a> for a fairly clear explanation about all of this.
|
||||
|
||||
@ -162,11 +162,11 @@ These issues will be addressed/resolved in the future.
|
||||
<li>Use the built-in library functions whenever possible.
|
||||
For example, instead of writing this:
|
||||
<pre>
|
||||
float x = 1.0 / sqrt(y);
|
||||
float x = 1.0 / sqrt(y);
|
||||
</pre>
|
||||
Write this:
|
||||
<pre>
|
||||
float x = inversesqrt(y);
|
||||
float x = inversesqrt(y);
|
||||
</pre>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
@ -56,27 +56,27 @@ log uses 4 spaces of indentation (4 + 75 < 80).
|
||||
<li>The first line should be a short, concise summary of the change prefixed
|
||||
with a module name. Examples:
|
||||
<pre>
|
||||
mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG
|
||||
mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG
|
||||
|
||||
gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY
|
||||
gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY
|
||||
|
||||
i965: Fix missing type in local variable declaration.
|
||||
i965: Fix missing type in local variable declaration.
|
||||
</pre>
|
||||
<li>Subsequent patch comments should describe the change in more detail,
|
||||
if needed. For example:
|
||||
<pre>
|
||||
i965: Remove end-of-thread SEND alignment code.
|
||||
i965: Remove end-of-thread SEND alignment code.
|
||||
|
||||
This was present in Eric's initial implementation of the compaction code
|
||||
for Sandybridge (commit 077d01b6). There is no documentation saying this
|
||||
is necessary, and removing it causes no regressions in piglit on any
|
||||
platform.
|
||||
This was present in Eric's initial implementation of the compaction code
|
||||
for Sandybridge (commit 077d01b6). There is no documentation saying this
|
||||
is necessary, and removing it causes no regressions in piglit on any
|
||||
platform.
|
||||
</pre>
|
||||
<li>A "Signed-off-by:" line is not required, but not discouraged either.
|
||||
<li>If a patch addresses an issue in gitlab, use the Closes: tag
|
||||
For example:
|
||||
<pre>
|
||||
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
|
||||
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
|
||||
</pre>
|
||||
<p>Prefer the full url to just <code>Closes: #1</code>, since the url makes it
|
||||
easier to get to the bug page from <code>git log</code></p>
|
||||
@ -85,7 +85,7 @@ easier to get to the bug page from <code>git log</code></p>
|
||||
<li>If a patch addresses a issue introduced with earlier commit, that should be
|
||||
noted in the patch comment. For example:
|
||||
<pre>
|
||||
Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
|
||||
Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
|
||||
</pre>
|
||||
<li>You can produce those fixes lines by running
|
||||
<pre>git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"</pre>
|
||||
@ -93,29 +93,29 @@ once and then using <pre>git fixes <sha1></pre>
|
||||
<li>If there have been several revisions to a patch during the review
|
||||
process, they should be noted such as in this example:
|
||||
<pre>
|
||||
st/mesa: add ARB_texture_stencil8 support (v4)
|
||||
st/mesa: add ARB_texture_stencil8 support (v4)
|
||||
|
||||
if we support stencil texturing, enable texture_stencil8
|
||||
there is no requirement to support native S8 for this,
|
||||
the texture can be converted to x24s8 fine.
|
||||
if we support stencil texturing, enable texture_stencil8
|
||||
there is no requirement to support native S8 for this,
|
||||
the texture can be converted to x24s8 fine.
|
||||
|
||||
v2: fold fixes from Marek in:
|
||||
a) put S8 last in the list
|
||||
b) fix renderable to always test for d/s renderable
|
||||
fixup the texture case to use a stencil only format
|
||||
for picking the format for the texture view.
|
||||
v3: hit fallback for getteximage
|
||||
v4: put s8 back in front, it shouldn't get picked now (Ilia)
|
||||
v2: fold fixes from Marek in:
|
||||
a) put S8 last in the list
|
||||
b) fix renderable to always test for d/s renderable
|
||||
fixup the texture case to use a stencil only format
|
||||
for picking the format for the texture view.
|
||||
v3: hit fallback for getteximage
|
||||
v4: put s8 back in front, it shouldn't get picked now (Ilia)
|
||||
</pre>
|
||||
<li>If someone tested your patch, document it with a line like this:
|
||||
<pre>
|
||||
Tested-by: Joe Hacker <jhacker@foo.com>
|
||||
Tested-by: Joe Hacker <jhacker@foo.com>
|
||||
</pre>
|
||||
<li>If the patch was reviewed (usually the case) or acked by someone,
|
||||
that should be documented with:
|
||||
<pre>
|
||||
Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
Acked-by: Joe Hacker <jhacker@foo.com>
|
||||
Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
Acked-by: Joe Hacker <jhacker@foo.com>
|
||||
</pre>
|
||||
<li>If sending later revision of a patch, add all the tags - ack, r-b,
|
||||
Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the
|
||||
@ -225,11 +225,11 @@ When you've reviewed a patch, please be unambiguous about your review.
|
||||
That is, state either
|
||||
</p>
|
||||
<pre>
|
||||
Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
</pre>
|
||||
or
|
||||
<pre>
|
||||
Acked-by: Joe Hacker <jhacker@foo.com>
|
||||
Acked-by: Joe Hacker <jhacker@foo.com>
|
||||
</pre>
|
||||
<p>
|
||||
Rather than saying just "LGTM" or "Seems OK".
|
||||
@ -239,7 +239,7 @@ Rather than saying just "LGTM" or "Seems OK".
|
||||
If small changes are suggested, it's OK to say something like:
|
||||
</p>
|
||||
<pre>
|
||||
With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
</pre>
|
||||
<p>
|
||||
which tells the patch author that the patch can be committed, as long
|
||||
@ -256,7 +256,7 @@ When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR,
|
||||
enclose the tag in backticks:
|
||||
</p>
|
||||
<pre>
|
||||
`Reviewed-by: Joe Hacker <jhacker@example.com>`</pre>
|
||||
`Reviewed-by: Joe Hacker <jhacker@example.com>`</pre>
|
||||
<p>
|
||||
This is the markdown format for literal, and will prevent gitlab from hiding
|
||||
the < and > symbols.
|
||||
@ -405,23 +405,23 @@ within the commit summary.
|
||||
<li><code>git rebase -i ...</code> is your friend. Don't be afraid to use it.
|
||||
<li>Apply a fixup to commit FOO.
|
||||
<pre>
|
||||
git add ...
|
||||
git commit --fixup=FOO
|
||||
git rebase -i --autosquash ...
|
||||
git add ...
|
||||
git commit --fixup=FOO
|
||||
git rebase -i --autosquash ...
|
||||
</pre>
|
||||
<li>Test for build breakage between patches e.g last 8 commits.
|
||||
<pre>
|
||||
git rebase -i --exec="ninja -C build/" HEAD~8
|
||||
git rebase -i --exec="ninja -C build/" HEAD~8
|
||||
</pre>
|
||||
<li>Sets the default mailing address for your repo.
|
||||
<pre>
|
||||
git config --local sendemail.to mesa-dev@lists.freedesktop.org
|
||||
git config --local sendemail.to mesa-dev@lists.freedesktop.org
|
||||
</pre>
|
||||
<li> Add version to subject line of patch series in this case for the last 8
|
||||
commits before sending.
|
||||
<pre>
|
||||
git send-email --subject-prefix="PATCH v4" HEAD~8
|
||||
git send-email -v4 @~8 # shorter version, inherited from git format-patch
|
||||
git send-email --subject-prefix="PATCH v4" HEAD~8
|
||||
git send-email -v4 @~8 # shorter version, inherited from git format-patch
|
||||
</pre>
|
||||
</ul>
|
||||
|
||||
|
||||
@ -111,18 +111,18 @@ On the host, all you're doing is running VMware
|
||||
<li>Xserver version at least 1.7
|
||||
<li>Ubuntu: For ubuntu you need to install a number of build dependencies.
|
||||
<pre>
|
||||
sudo apt-get install git-core
|
||||
sudo apt-get install ninja-build meson libpthread-stubs0-dev
|
||||
sudo apt-get install xserver-xorg-dev x11proto-xinerama-dev libx11-xcb-dev
|
||||
sudo apt-get install libxcb-glx0-dev libxrender-dev
|
||||
sudo apt-get build-dep libgl1-mesa-dri libxcb-glx0-dev
|
||||
sudo apt-get install git-core
|
||||
sudo apt-get install ninja-build meson libpthread-stubs0-dev
|
||||
sudo apt-get install xserver-xorg-dev x11proto-xinerama-dev libx11-xcb-dev
|
||||
sudo apt-get install libxcb-glx0-dev libxrender-dev
|
||||
sudo apt-get build-dep libgl1-mesa-dri libxcb-glx0-dev
|
||||
</pre>
|
||||
<li>Fedora: For Fedora you also need to install a number of build dependencies.
|
||||
<pre>
|
||||
sudo yum install mesa-libGL-devel xorg-x11-server-devel xorg-x11-util-macros
|
||||
sudo yum install libXrender-devel.i686
|
||||
sudo yum install ninja-build meson gcc expat-devel kernel-devel git-core
|
||||
sudo yum install makedepend flex bison
|
||||
sudo yum install mesa-libGL-devel xorg-x11-server-devel xorg-x11-util-macros
|
||||
sudo yum install libXrender-devel.i686
|
||||
sudo yum install ninja-build meson gcc expat-devel kernel-devel git-core
|
||||
sudo yum install makedepend flex bison
|
||||
</pre>
|
||||
</ul>
|
||||
|
||||
@ -137,27 +137,27 @@ Meson should tell you what's missing.
|
||||
|
||||
Begin by saving your current directory location:
|
||||
<pre>
|
||||
export TOP=$PWD
|
||||
export TOP=$PWD
|
||||
</pre>
|
||||
|
||||
<ul>
|
||||
<li>Mesa/Gallium master branch. This code is used to build libGL, and the direct rendering svga driver for libGL, vmwgfx_dri.so, and the X acceleration library libxatracker.so.x.x.x.
|
||||
<pre>
|
||||
git clone https://gitlab.freedesktop.org/mesa/mesa.git
|
||||
git clone https://gitlab.freedesktop.org/mesa/mesa.git
|
||||
</pre>
|
||||
<li>VMware Linux guest kernel module. Note that this repo contains the complete DRM and TTM code. The vmware-specific driver is really only the files prefixed with vmwgfx.
|
||||
<pre>
|
||||
git clone git://anongit.freedesktop.org/git/mesa/vmwgfx
|
||||
git clone git://anongit.freedesktop.org/git/mesa/vmwgfx
|
||||
</pre>
|
||||
<li>libdrm, a user-space library that interfaces with drm.
|
||||
Most distros ship with this but it's safest to install a newer version.
|
||||
To get the latest code from git:
|
||||
<pre>
|
||||
git clone https://gitlab.freedesktop.org/mesa/drm.git
|
||||
git clone https://gitlab.freedesktop.org/mesa/drm.git
|
||||
</pre>
|
||||
<li>xf86-video-vmware. The chainloading driver, vmware_drv.so, the legacy driver vmwlegacy_drv.so, and the vmwgfx driver vmwgfx_drv.so.
|
||||
<pre>
|
||||
git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-vmware
|
||||
git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-vmware
|
||||
</pre>
|
||||
</ul>
|
||||
|
||||
@ -172,29 +172,29 @@ the LIBDIR environment variable accordingly.
|
||||
</p>
|
||||
For 32-bit Ubuntu systems:
|
||||
<pre>
|
||||
export LIBDIR=/usr/lib/i386-linux-gnu
|
||||
export LIBDIR=/usr/lib/i386-linux-gnu
|
||||
</pre>
|
||||
For 64-bit Ubuntu systems:
|
||||
<pre>
|
||||
export LIBDIR=/usr/lib/x86_64-linux-gnu
|
||||
export LIBDIR=/usr/lib/x86_64-linux-gnu
|
||||
</pre>
|
||||
For 32-bit Fedora systems:
|
||||
<pre>
|
||||
export LIBDIR=/usr/lib
|
||||
export LIBDIR=/usr/lib
|
||||
</pre>
|
||||
For 64-bit Fedora systems:
|
||||
<pre>
|
||||
export LIBDIR=/usr/lib64
|
||||
export LIBDIR=/usr/lib64
|
||||
</pre>
|
||||
|
||||
</li>
|
||||
|
||||
<li>Build libdrm:
|
||||
<pre>
|
||||
cd $TOP/drm
|
||||
meson builddir --prefix=/usr --libdir=${LIBDIR}
|
||||
ninja -C builddir
|
||||
sudo ninja -C builddir install
|
||||
cd $TOP/drm
|
||||
meson builddir --prefix=/usr --libdir=${LIBDIR}
|
||||
ninja -C builddir
|
||||
sudo ninja -C builddir install
|
||||
</pre>
|
||||
<li>
|
||||
<p>Build Mesa and the vmwgfx_dri.so driver, the vmwgfx_drv.so xorg driver, the X acceleration library libxatracker.
|
||||
@ -206,10 +206,10 @@ copy and video acceleration:
|
||||
|
||||
The following configure options doesn't build the EGL system.
|
||||
<pre>
|
||||
cd $TOP/mesa
|
||||
meson builddir --prefix=/usr --libdir=${LIBDIR} -Dgallium-drivers=svga -Ddri-drivers=swrast -Dgallium-xa=true -Ddri3=false
|
||||
ninja -C builddir
|
||||
sudo ninja -C builddir install
|
||||
cd $TOP/mesa
|
||||
meson builddir --prefix=/usr --libdir=${LIBDIR} -Dgallium-drivers=svga -Ddri-drivers=swrast -Dgallium-xa=true -Ddri3=false
|
||||
ninja -C builddir
|
||||
sudo ninja -C builddir install
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -221,34 +221,34 @@ if they're not installed in your system. You should be told what's missing.
|
||||
building and replacing the current Xorg driver.
|
||||
First check if your system is 32- or 64-bit.
|
||||
<pre>
|
||||
cd $TOP/xf86-video-vmware
|
||||
./autogen.sh --prefix=/usr --libdir=${LIBDIR}
|
||||
make
|
||||
sudo make install
|
||||
cd $TOP/xf86-video-vmware
|
||||
./autogen.sh --prefix=/usr --libdir=${LIBDIR}
|
||||
make
|
||||
sudo make install
|
||||
</pre>
|
||||
|
||||
<li>vmwgfx kernel module. First make sure that any old version of this kernel module is removed from the system by issuing
|
||||
<pre>
|
||||
sudo rm /lib/modules/`uname -r`/kernel/drivers/gpu/drm/vmwgfx.ko*
|
||||
sudo rm /lib/modules/`uname -r`/kernel/drivers/gpu/drm/vmwgfx.ko*
|
||||
</pre>
|
||||
Build and install:
|
||||
<pre>
|
||||
cd $TOP/vmwgfx
|
||||
make
|
||||
sudo make install
|
||||
sudo depmod -a
|
||||
cd $TOP/vmwgfx
|
||||
make
|
||||
sudo make install
|
||||
sudo depmod -a
|
||||
</pre>
|
||||
If you're using a Ubuntu OS:
|
||||
<pre>
|
||||
sudo update-initramfs -u
|
||||
sudo update-initramfs -u
|
||||
</pre>
|
||||
If you're using a Fedora OS:
|
||||
<pre>
|
||||
sudo dracut --force
|
||||
sudo dracut --force
|
||||
</pre>
|
||||
Add 'vmwgfx' to the /etc/modules file:
|
||||
<pre>
|
||||
echo vmwgfx | sudo tee -a /etc/modules
|
||||
echo vmwgfx | sudo tee -a /etc/modules
|
||||
</pre>
|
||||
|
||||
Note: some distros put DRM kernel drivers in different directories.
|
||||
@ -259,7 +259,7 @@ For example, sometimes vmwgfx.ko might be found in
|
||||
After installing vmwgfx.ko you might want to run the following command to
|
||||
check that the new kernel module is in the expected place:
|
||||
<pre>
|
||||
find /lib/modules -name vmwgfx.ko -exec ls -l '{}' \;
|
||||
find /lib/modules -name vmwgfx.ko -exec ls -l '{}' \;
|
||||
</pre>
|
||||
If you see the kernel module listed in more than one place, you may need to
|
||||
move things around.
|
||||
@ -271,10 +271,10 @@ reinstall the vmwgfx.ko module again.
|
||||
|
||||
Now try to load the kernel module by issuing
|
||||
<pre>
|
||||
sudo modprobe vmwgfx</pre>
|
||||
sudo modprobe vmwgfx</pre>
|
||||
Then type
|
||||
<pre>
|
||||
dmesg</pre>
|
||||
dmesg</pre>
|
||||
to watch the debug output. It should contain a number of lines prefixed with "[vmwgfx]".
|
||||
|
||||
<p>
|
||||
@ -301,7 +301,7 @@ OpenGL version string: 2.1 Mesa 8.0
|
||||
<p>
|
||||
If you don't see this, try setting this environment variable:
|
||||
<pre>
|
||||
export LIBGL_DEBUG=verbose</pre>
|
||||
export LIBGL_DEBUG=verbose</pre>
|
||||
<p>
|
||||
then rerun glxinfo and examine the output for error messages.
|
||||
</p>
|
||||
|
||||
@ -64,12 +64,12 @@ The format of accepted values is: <code>visual-class depth</code>
|
||||
Here are some examples:
|
||||
</p>
|
||||
<pre>
|
||||
using csh:
|
||||
using csh:
|
||||
% setenv MESA_RGB_VISUAL "TrueColor 8" // 8-bit TrueColor
|
||||
% setenv MESA_CI_VISUAL "PseudoColor 12" // 12-bit PseudoColor
|
||||
% setenv MESA_RGB_VISUAL "PseudoColor 8" // 8-bit PseudoColor
|
||||
|
||||
using bash:
|
||||
using bash:
|
||||
$ export MESA_RGB_VISUAL="TrueColor 8"
|
||||
$ export MESA_CI_VISUAL="PseudoColor 12"
|
||||
$ export MESA_RGB_VISUAL="PseudoColor 8"
|
||||
@ -146,8 +146,8 @@ The defaults are all 1.0, effectively disabling gamma correction.
|
||||
Examples:
|
||||
</p>
|
||||
<pre>
|
||||
% export MESA_GAMMA="2.3 2.2 2.4" // separate R,G,B values
|
||||
% export MESA_GAMMA="2.0" // same gamma for R,G,B
|
||||
% export MESA_GAMMA="2.3 2.2 2.4" // separate R,G,B values
|
||||
% export MESA_GAMMA="2.0" // same gamma for R,G,B
|
||||
</pre>
|
||||
<p>
|
||||
The <code>demos/gamma.c</code> program in mesa/demos repository may help
|
||||
@ -183,7 +183,7 @@ determine if your X server has overlay support you can test for the
|
||||
SERVER_OVERLAY_VISUALS property:
|
||||
</p>
|
||||
<pre>
|
||||
xprop -root | grep SERVER_OVERLAY_VISUALS
|
||||
xprop -root | grep SERVER_OVERLAY_VISUALS
|
||||
</pre>
|
||||
|
||||
|
||||
@ -207,8 +207,8 @@ The following Mesa-specific extensions are implemented in the Xlib driver.
|
||||
This extension adds the GLX function:
|
||||
</p>
|
||||
<pre>
|
||||
GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
|
||||
Pixmap pixmap, Colormap cmap )
|
||||
GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
|
||||
Pixmap pixmap, Colormap cmap )
|
||||
</pre>
|
||||
<p>
|
||||
It is an alternative to the standard glXCreateGLXPixmap() function.
|
||||
@ -243,10 +243,10 @@ deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
|
||||
just before an X window is destroyed. For example:
|
||||
</p>
|
||||
<pre>
|
||||
#ifdef GLX_MESA_release_buffers
|
||||
glXReleaseBuffersMESA( dpy, window );
|
||||
#endif
|
||||
XDestroyWindow( dpy, window );
|
||||
#ifdef GLX_MESA_release_buffers
|
||||
glXReleaseBuffersMESA( dpy, window );
|
||||
#endif
|
||||
XDestroyWindow( dpy, window );
|
||||
</pre>
|
||||
<p>
|
||||
<a href="specs/MESA_release_buffers.spec">GLX_MESA_release_buffers specification</a>
|
||||
@ -270,11 +270,11 @@ This extension was added in Mesa 2.6
|
||||
|
||||
<h2>Summary of X-related environment variables</h2>
|
||||
<pre>
|
||||
MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
|
||||
MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
|
||||
MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
|
||||
MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
|
||||
MESA_GAMMA - gamma correction coefficients (X only)
|
||||
MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
|
||||
MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
|
||||
MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
|
||||
MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
|
||||
MESA_GAMMA - gamma correction coefficients (X only)
|
||||
</pre>
|
||||
|
||||
</div>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user