fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-05 05:18:08 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

intel/brw: Update comments for indirect MOV splitting

Browse source 
brw_broadcast and generate_mov_indirect both had similar comments, both
with typos ("insead").  One still referred to IVB bugs, while the other
dropped that during the compiler split.  The one that dropped the
comment mentioned "both of these" issues, while citing only one issue;
there was in fact a third issue (no-Q/UQ) that wasn't mentioned in
either comment.  One also had some bad grammar in the comments.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28458>
This commit is contained in:
Kenneth Graunke 2024-03-27 15:56:13 -07:00 • committed by Marge Bot
parent 7a24f29fbb
commit 1d9e2b761a
2 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
src/intel/compiler/brw_eu_emit.c
View file

@ -2052,15 +2052,17 @@ brw_broadcast(struct brw_codegen *p,
!devinfo->has_64bit_int)) {
/* From the Cherryview PRM Vol 7. "Register Region Restrictions":
*
* "When source or destination datatype is 64b or operation is
* "When source or destination datatype is 64b or operation is
* integer DWord multiply, indirect addressing must not be
* used."
*
* To work around both of this issue, we do two integer MOVs
* insead of one 64-bit MOV. Because no double value should ever
* cross a register boundary, it's safe to use the immediate
* offset in the indirect here to handle adding 4 bytes to the
* offset and avoid the extra ADD to the register file.
* We may also not support Q/UQ types.
*
* To work around both of these, we do two integer MOVs instead
* of one 64-bit MOV. Because no double value should ever cross
* a register boundary, it's safe to use the immediate offset in
* the indirect here to handle adding 4 bytes to the offset and
* avoid the extra ADD to the register file.
*/
brw_MOV(p, subscript(dst, BRW_REGISTER_TYPE_D, 0),
retype(brw_vec1_indirect(addr.subnr, offset),

20
src/intel/compiler/brw_fs_generator.cpp
View file

@ -380,20 +380,18 @@ fs_generator::generate_mov_indirect(fs_inst *inst,
if (type_sz(reg.type) > 4 &&
(intel_device_info_is_9lp(devinfo) || !devinfo->has_64bit_int)) {
/* IVB has an issue (which we found empirically) where it reads two
* address register components per channel for indirectly addressed
* 64-bit sources.
/* From the Cherryview PRM Vol 7. "Register Region Restrictions":
*
* From the Cherryview PRM Vol 7. "Register Region Restrictions":
*
* "When source or destination datatype is 64b or operation is
* "When source or destination datatype is 64b or operation is
* integer DWord multiply, indirect addressing must not be used."
*
* To work around both of these, we do two integer MOVs insead of one
* 64-bit MOV. Because no double value should ever cross a register
* boundary, it's safe to use the immediate offset in the indirect
* here to handle adding 4 bytes to the offset and avoid the extra
* ADD to the register file.
* We may also not support Q/UQ types.
*
* To work around both of these, we do two integer MOVs instead
* of one 64-bit MOV. Because no double value should ever cross
* a register boundary, it's safe to use the immediate offset in
* the indirect here to handle adding 4 bytes to the offset and
* avoid the extra ADD to the register file.
*/
brw_MOV(p, subscript(dst, BRW_REGISTER_TYPE_D, 0),
retype(brw_VxH_indirect(0, 0), BRW_REGISTER_TYPE_D));