intel: Drop some author comments and update Faith's name

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22120>

diff --git a/docs/isl/ccs.rst b/docs/isl/ccs.rst
index fe94f85..1cd678c 100644 (file)
--- a/docs/isl/ccs.rst
+++ b/docs/isl/ccs.rst
@@ -63,7 +63,7 @@ format, each 2x2 subspan coming out of a shader will land entirely within one
 cache-line pair.
 
 What is the correspondence between bits and cache-line pairs?  The best model I
-(Jason) know of is to consider the CCS as having a 1-bit color format for
+(Faith) know of is to consider the CCS as having a 1-bit color format for
 fast-clears and a 2-bit format for color compression and a special tiling
 format.  The CCS tiling formats operate on a 1 or 2-bit granularity rather than
 the byte granularity of most tiling formats.

diff --git a/docs/isl/index.rst b/docs/isl/index.rst
index f2f619f..231bde2 100644 (file)
--- a/docs/isl/index.rst
+++ b/docs/isl/index.rst
@@ -3,7 +3,7 @@ Intel Surface Layout (ISL)
 
 The Intel Surface Layout library (**ISL**) is a subproject in Mesa for doing
 surface layout calculations for Intel graphics drivers.  It was originally
-written by Chad Versace and is now maintained by Jason Ekstrand and Nanley
+written by Lina Versace and is now maintained by Faith Ekstrand and Nanley
 Chery.
 
 .. toctree::

diff --git a/src/intel/compiler/brw_nir_analyze_boolean_resolves.c b/src/intel/compiler/brw_nir_analyze_boolean_resolves.c
index 8e40a9f..fd3b253 100644 (file)
--- a/src/intel/compiler/brw_nir_analyze_boolean_resolves.c
+++ b/src/intel/compiler/brw_nir_analyze_boolean_resolves.c
@@ -19,9 +19,6 @@
  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
- *
- * Authors:
- *    Jason Ekstrand <jason@jlekstrand.net>
  */
 
 #include "brw_nir.h"

diff --git a/src/intel/compiler/brw_nir_opt_peephole_ffma.c b/src/intel/compiler/brw_nir_opt_peephole_ffma.c
index 2a39a22..6969a7e 100644 (file)
--- a/src/intel/compiler/brw_nir_opt_peephole_ffma.c
+++ b/src/intel/compiler/brw_nir_opt_peephole_ffma.c
@@ -19,10 +19,6 @@
  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
- *
- * Authors:
- *    Jason Ekstrand (jason@jlekstrand.net)
- *
  */
 
 #include "brw_nir.h"

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index cad7060..6223f0d 100644 (file)
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1196,7 +1196,7 @@ emit_3dstate_vs(struct anv_graphics_pipeline *pipeline)
           * but the Haswell docs for the "VS Reference Count Full Force Miss
           * Enable" field of the "Thread Mode" register refer to a HSW bug in
           * which the VUE handle reference count would overflow resulting in
-          * internal reference counting bugs.  My (Jason's) best guess is that
+          * internal reference counting bugs.  My (Faith's) best guess is that
           * this bug cropped back up on SKL GT4 when we suddenly had more
           * threads in play than any previous gfx9 hardware.
           *

diff --git a/src/intel/vulkan_hasvk/genX_cmd_buffer.c b/src/intel/vulkan_hasvk/genX_cmd_buffer.c
index ac01183..3eb1d1c 100644 (file)
--- a/src/intel/vulkan_hasvk/genX_cmd_buffer.c
+++ b/src/intel/vulkan_hasvk/genX_cmd_buffer.c
@@ -813,7 +813,7 @@ genX(copy_fast_clear_dwords)(struct anv_cmd_buffer *cmd_buffer,
     *
     * It is unclear exactly why this hang occurs.  Both MI commands come with
     * warnings about the 3D pipeline but that doesn't seem to fully explain
-    * it.  My (Jason's) best theory is that it has something to do with the
+    * it.  My (Faith's) best theory is that it has something to do with the
     * fact that we're using a GPU state register as our temporary and that
     * something with reading/writing it is causing problems.
     *