From 789992b7c91806dd8b3670f850ef7a892da59871 Mon Sep 17 00:00:00 2001 From: Faith Ekstrand Date: Sat, 25 Mar 2023 16:21:11 -0500 Subject: [PATCH] intel: Drop some author comments and update Faith's name Part-of: --- docs/isl/ccs.rst | 2 +- docs/isl/index.rst | 2 +- src/intel/compiler/brw_nir_analyze_boolean_resolves.c | 3 --- src/intel/compiler/brw_nir_opt_peephole_ffma.c | 4 ---- src/intel/vulkan/genX_pipeline.c | 2 +- src/intel/vulkan_hasvk/genX_cmd_buffer.c | 2 +- 6 files changed, 4 insertions(+), 11 deletions(-) diff --git a/docs/isl/ccs.rst b/docs/isl/ccs.rst index fe94f85cf4c..1cd678c2ec1 100644 --- 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 f2f619f9926..231bde2f314 100644 --- 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 8e40a9f53cb..fd3b253369f 100644 --- 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 */ #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 2a39a22c5dc..6969a7edae8 100644 --- 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 cad70608405..6223f0d98bf 100644 --- 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 ac0118390ba..3eb1d1ccd64 100644 --- 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. *