fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-20 11:40:10 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

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

Browse source 
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22120>
This commit is contained in:
Faith Ekstrand 2023-03-25 16:21:11 -05:00 • committed by Marge Bot
parent cf1da3ef40
commit 789992b7c9
6 changed files with 4 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/isl/ccs.rst
View file

@ -63,7 +63,7 @@ format, each 2x2 subspan coming out of a shader will land entirely within one
cache-line pair. cache-line pair.
What is the correspondence between bits and cache-line pairs? The best model I 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 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 format. The CCS tiling formats operate on a 1 or 2-bit granularity rather than
the byte granularity of most tiling formats. the byte granularity of most tiling formats.

2
docs/isl/index.rst
View file

@ -3,7 +3,7 @@ Intel Surface Layout (ISL)
The Intel Surface Layout library (**ISL**) is a subproject in Mesa for doing The Intel Surface Layout library (**ISL**) is a subproject in Mesa for doing
surface layout calculations for Intel graphics drivers. It was originally 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. Chery.
.. toctree:: .. toctree::

3
src/intel/compiler/brw_nir_analyze_boolean_resolves.c
View file

@ -19,9 +19,6 @@
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * 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 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE. * IN THE SOFTWARE.
*
* Authors:
* Jason Ekstrand <jason@jlekstrand.net>
*/ */
#include "brw_nir.h" #include "brw_nir.h"

4
src/intel/compiler/brw_nir_opt_peephole_ffma.c
View file

@ -19,10 +19,6 @@
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * 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 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE. * IN THE SOFTWARE.
*
* Authors:
* Jason Ekstrand (jason@jlekstrand.net)
*
*/ */
#include "brw_nir.h" #include "brw_nir.h"

2
src/intel/vulkan/genX_pipeline.c
View file

@ -1196,7 +1196,7 @@ emit_3dstate_vs(struct anv_graphics_pipeline *pipeline)
* but the Haswell docs for the "VS Reference Count Full Force Miss * 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 * Enable" field of the "Thread Mode" register refer to a HSW bug in
* which the VUE handle reference count would overflow resulting 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 * this bug cropped back up on SKL GT4 when we suddenly had more
* threads in play than any previous gfx9 hardware. * threads in play than any previous gfx9 hardware.
* *

2
src/intel/vulkan_hasvk/genX_cmd_buffer.c
View file

@ -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 * 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 * 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 * fact that we're using a GPU state register as our temporary and that
* something with reading/writing it is causing problems. * something with reading/writing it is causing problems.
* *