[Mesa-dev] [PATCH v2 19/30] i965/fs: add shuffle_64bit_data_for_32bit_write helper
Samuel Iglesias Gonsálvez
siglesias at igalia.com
Fri May 13 05:34:07 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 13/05/16 05:05, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez <siglesias at igalia.com> writes:
>
>> From: Iago Toral Quiroga <itoral at igalia.com>
>>
>> This does the inverse operation of
>> shuffle_32bit_load_result_to_64bit_data and we will use it when
>> we need to write 64-bit data in the layout expected by untyped
>> write messages.
>>
>> v2 (curro): - Use subscript() instead of stride() - Assert on the
>> input types rather than silently retyping. - Use offset() instead
>> of horiz_offset(), drop the multiplier definition. - Drop the
>> temporary vgrf and force_writemask_all. - Make component_i
>> const. --- src/mesa/drivers/dri/i965/brw_fs.cpp | 40
>> ++++++++++++++++++++++++++++++++++++
>> src/mesa/drivers/dri/i965/brw_fs.h | 5 +++++ 2 files changed,
>> 45 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp index ebc5128..3c58ccb
>> 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -280,6 +280,46 @@
>> fs_visitor::shuffle_32bit_load_result_to_64bit_data(const
>> fs_builder &bld, }
>>
>> /** + * This helper does the inverse operation of + *
>> SHUFFLE_32BIT_LOAD_RESULT_TO_64BIT_DATA. + * + * We need to do
>> this when we are going to use untyped write messsages that + *
>> operate with 32-bit components in order to arrange our 64-bit
>> data to be + * in the expected layout. + */ +void
>> +fs_visitor::shuffle_64bit_data_for_32bit_write(const fs_builder
>> &bld, + const
>> fs_reg dst, + const
>> fs_reg src, +
>> uint32_t components) +{ + assert(type_sz(src.type) == 8); +
>> assert(type_sz(dst.type) == 4); + + /* A temporary that we will
>> use to shuffle the 64-bit data of each + * component in the
>> vector into valid 32-bit data that we can write. + * We can't
>> write directly to dst because dst can be (and would usually be) +
>> * the same as src and in that case the first MOV in the loop
>> below would + * overwrite the data read in the second MOV. +
>> */ + fs_reg tmp = retype(bld.vgrf(src.type), dst.type); +
>
> This is just 'bld.vgrf(dst.type, 2)' as I suggested off-list, other
> than that:
>
> Reviewed-by: Francisco Jerez <currojerez at riseup.net>
>
I'll do the change, thanks.
Sam
>> + for (unsigned i = 0; i < components; i++) { + const
>> fs_reg component_i = offset(src, bld, i); + + bld.MOV(tmp,
>> subscript(component_i, dst.type, 0)); + bld.MOV(offset(tmp,
>> bld, 1), subscript(component_i, dst.type, 1)); + + /*
>> Because we are shuffling our 64-bit data to a 32-bit layout, we +
>> * need these MOVs to be 32-bit (instead of doing this as a
>> single + * DF MOV), otherwise we would not be respecting
>> the channel enables. + */ + bld.MOV(offset(dst, bld, 2
>> * i), tmp); + bld.MOV(offset(dst, bld, 2 * i + 1),
>> offset(tmp, bld, 1)); + } +} + +/** * A helper for MOV
>> generation for fixing up broken hardware SEND dependency *
>> handling. */ diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
>> b/src/mesa/drivers/dri/i965/brw_fs.h index 1aeacae..4c17ff4
>> 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.h +++
>> b/src/mesa/drivers/dri/i965/brw_fs.h @@ -110,6 +110,11 @@
>> public: const fs_reg src, uint32_t components);
>>
>> + void shuffle_64bit_data_for_32bit_write(const brw::fs_builder
>> &bld, + const fs_reg
>> dst, + const fs_reg
>> src, + uint32_t
>> components); + void do_untyped_vector_read(const brw::fs_builder
>> &bld, const fs_reg surf_index, const fs_reg offset_reg, -- 2.5.0
>>
>> _______________________________________________ mesa-dev mailing
>> list mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXNWdPAAoJEH/0ujLxfcNDAcoP+weYYE1VyNm+82JoOqrcD9vw
Uw9jaCV7GUhA1nosKdwqNpkRAEMbzJFx1VbsGsAdSNhGLyV5R+aInjECGUxHRcYk
/zEjIhTUvHduzv5643b/Chk+a2s2EEDddkBeiOPlaNQsLzmfF/fPt+tIFySoiesG
/Q+wa9ds7W3Vv+YmYlP6R7TxyXBJVN9FJqVGTM46To/s1qdOoY3SnK8rGOV9d/E2
1emOvG6OBCxpAjoH9uRXIwlvtVkcfWU6PNZ2PAiENM57PNZx+CGb7VChPdg3l7UH
LGB0PP9cAqfG3OgDyXYbr5SmrA7eLdvlJcvZLBuwUx8qI2di6VoA5SQvVkoQG0Ix
xw5Q3/Wq78Fi8xSAUgS6U25frihLiWClRxtQMiz0WwKPuGdiGx6XgVlGSEZdso7N
3uWVzQWoZMNqOkM5nRBSWxc6mjzKxOzRkbmJ7fgS4yTrNwpKeIZwUfzodztKqbO2
WTFR3+jKdpai8QfDSk/3KSred0IQDYuUFNTy2mLi7ladxnal1oONzwZbB+fAf/PL
bl3tX93432j7+LknH9Y4qexzytXw1JWbcBxRXlM4QCyAx4gQnO3xcNRZucokW0y8
magEJzmZdchPGwos6tKrqgC7F39YdXbvh9jkCVt6eufyaUcVJJzFAx6SyAKPhwbi
6LhhOxWpbR9JLfgAY31Z
=tnuX
-----END PGP SIGNATURE-----
More information about the mesa-dev
mailing list