freedreno: defer flush_queue allocation

[mesa.git] / docs / devinfo.html

diff --git a/docs/devinfo.html b/docs/devinfo.html
index f5113b0bd72a4785d61201b50df93232be245506..489d263f2952f95610347bcde3933e8431b3f94b 100644 (file)
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -244,7 +244,7 @@ to update the tests themselves.
 
 <p>
 Whenever possible and applicable, test the patch with
-<a href="http://people.freedesktop.org/~nh/piglit/">Piglit</a> to
+<a href="http://piglit.freedesktop.org">Piglit</a> to
 check for regressions.
 </p>
 
@@ -266,6 +266,37 @@ re-sending the whole series). Using --in-reply-to makes
 it harder for reviewers to accidentally review old patches.
 </p>
 
+<p>
+When submitting follow-up patches you should also login to
+<a href="https://patchwork.freedesktop.org">patchwork</a> and change the
+state of your old patches to Superseded.
+</p>
+
+<h3>Reviewing Patches</h3>
+
+<p>
+When you've reviewed a patch on the mailing list, please be unambiguous
+about your review.  That is, state either
+<pre>
+    Reviewed-by: Joe Hacker &lt;jhacker@foo.com&gt;
+</pre>
+or
+<pre>
+    Acked-by: Joe Hacker &lt;jhacker@foo.com&gt;
+</pre>
+Rather than saying just "LGTM" or "Seems OK".
+</p>
+
+<p>
+If small changes are suggested, it's OK to say something like:
+<pre>
+   With the above fixes, Reviewed-by: Joe Hacker &lt;jhacker@foo.com&gt;
+</pre>
+which tells the patch author that the patch can be committed, as long
+as the issues are resolved first.
+</p>
+
+
 <h3>Marking a commit as a candidate for a stable branch</h3>
 
 <p>
@@ -539,7 +570,7 @@ Edit docs/relnotes/X.Y.Z.html to add the sha256sums printed as part of "make
 tarballs" in the previous step. Commit this change.
 </p>
 
-<h3>Push all commits and the tag creates above</h3>
+<h3>Push all commits and the tag created above</h3>
 
 <p>
 This is the first step that cannot easily be undone. The release is going
@@ -566,7 +597,7 @@ signatures to the freedesktop.org server:
        mv ~/MesaLib-X.Y.Z* .
 </pre>
 
-<h3>Back on mesa master, andd the new release notes into the tree</h3>
+<h3>Back on mesa master, add the new release notes into the tree</h3>
 
 <p>
 Something like the following steps will do the trick:
@@ -653,9 +684,11 @@ To add a new GL extension to Mesa you have to do at least the following.
 </li>
 <li>
    Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
+   if the extension requires driver capabilities not already exposed by
+   another extension.
 </li>
 <li>
-   Update the <code>extensions.c</code> file.
+   Add a new entry to the src/mesa/main/extensions_table.h file.
 </li>
 <li>
    From this point, the best way to proceed is to find another extension,
@@ -666,12 +699,18 @@ To add a new GL extension to Mesa you have to do at least the following.
    If the new extension adds new GL state, the functions in get.c, enable.c
    and attrib.c will most likely require new code.
 </li>
+<li>
+   To determine if the new extension is active in the current context,
+   use the auto-generated _mesa_has_##name_str() function defined in
+   src/mesa/main/extensions.h.
+</li>
 <li>
    The dispatch tests check_table.cpp and dispatch_sanity.cpp
    should be updated with details about the new extensions functions. These
    tests are run using 'make check'
 </li>
 </ul>
+</p>