On Fri, Mar 06, 2015 at 03:11:27PM +0200, Francisco Jerez wrote:
> "Pohjolainen, Topi" <topi.pohjolai...@intel.com> writes:
>
> > On Fri, Feb 27, 2015 at 05:34:51PM +0200, Francisco Jerez wrote:
> >> This doesn't actually enable untyped surface message sends from GRF
> >> yet, the upcoming atomic counter and image intrinsic lowering code
> >> will.
> >> ---
> >> src/mesa/drivers/dri/i965/brw_vec4.cpp | 7 ++++---
> >> src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 16 +++++++---------
> >> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 5 +++--
> >> 3 files changed, 14 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> index e144449..0004b10 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> @@ -256,6 +256,8 @@ vec4_instruction::is_send_from_grf()
> >> switch (opcode) {
> >> case SHADER_OPCODE_SHADER_TIME_ADD:
> >> case VS_OPCODE_PULL_CONSTANT_LOAD_GEN7:
> >> + case SHADER_OPCODE_UNTYPED_ATOMIC:
> >> + case SHADER_OPCODE_UNTYPED_SURFACE_READ:
> >> return true;
> >> default:
> >> return false;
> >> @@ -270,6 +272,8 @@ vec4_instruction::regs_read(unsigned arg) const
> >>
> >> switch (opcode) {
> >> case SHADER_OPCODE_SHADER_TIME_ADD:
> >> + case SHADER_OPCODE_UNTYPED_ATOMIC:
> >> + case SHADER_OPCODE_UNTYPED_SURFACE_READ:
> >> return arg == 0 ? mlen : 1;
> >
> > Before the logic always falled back to returning one. Now we may return
> > one, two or three I think. I may be mistaken though, I'm just reading
> > vec4_visitor::emit_untyped_atomic() and it can produce message lengths up
> > to three.
> > Does this effect the instruction scheduling logic and if not, can you
> > explain why not?
> >
>
> Before my change that wouldn't ever happen because we were using fake
> MRFs to assemble the message payload and the MRF register index would be
> specified as inst->base_mrf, so the payload wouldn't be an actual source
> of the untyped surface instruction. This change adds an additional
> source for the payload, but a fake MRF is still passed in as explicit
> source temporarily. A future commit will change the vec4 visitor to
> build untyped and typed surface message payloads directly in normal GRFs
> instead of fake MRFs.
I checked the scheduler and confirmed this shouldn't change the current
behavior. If you like, you could add your explanation to the commit message
also. Either way:
Reviewed-by: Topi Pohjolainen <topi.pohjolai...@intel.com>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
