[Mesa-dev] [PATCH 2/2] i965/draw state: Allow state upload to proceed when inputs are not set

[Ben Widawsky]

On Sat, Nov 22, 2014 at 11:50:29PM -0800, Kenneth Graunke wrote:
> On Saturday, November 22, 2014 11:26:39 PM Jordan Justen wrote:
> > On 2014-11-22 17:33:54, Kenneth Graunke wrote:
> > > On Saturday, November 22, 2014 12:02:31 PM Jordan Justen wrote:
> > > > For drawing the OpenGL API should validate this before we try to upload the
> > > > state.
> > > > 
> > > > For compute, these might not be set.
> > > > 
> > > > Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_draw_upload.c | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > index 5a12439..28136e2 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > @@ -433,6 +433,10 @@ brw_prepare_vertices(struct brw_context *brw)
> > > >        struct brw_vertex_element *input = &brw->vb.inputs[i];
> > > >  
> > > >        vs_inputs &= ~BITFIELD64_BIT(i);
> > > > +
> > > > +      if (!input->glarray)
> > > > +         continue;
> > > > +
> > > >        brw->vb.enabled[brw->vb.nr_enabled++] = input;
> > > >     }
> > > 
> > > Seems like you don't want to be calling this code at all when doing compute.
> > > 
> > > The draw upload code is already complicated and difficult to understand;
> > > although this is a small addition, the "Inputs can be NULL?!?!?" question
> > > readers might have could add to the confusion.  Which is fine, if compute
> > > needs to hit this code...but if it doesn't need it, skipping it altogether
> > > would be clearer and simpler.
> > > 
> > > Does compute actually want 3DSTATE_VERTEX_BUFFERS/ELEMENTS?  Does it use
> > > 3DPRIMITIVE?
> > 
> > No. But, as I understanded your previous feedback, you didn't want to
> > have separate state tracking for compute.
> 
> Not necessarily.
> 
> Jordan, could you send out a list of the command packets and state needed
> to do meaningful compute work?  I think that would help me understand
> what's required.  INTEL_DEBUG=bat would show what you're currently emitting.
> 
> My assumption so far (which I'd like to confirm with the above list) is that
> there's actually very little overlap between normal 3D drawing and general
> compute work.  I also know that compute shaders are kicked off via separate
> glDispatchCompute and glDispatchComputeIndirect functions.  I don't really
> understand why we're even hitting the draw_prims driver hook.  If there's
> really little overlap, then creating a totally separate driver hook might
> make more sense.
> 
> Another idea I've had is that we could use a separate hardware context
> (brw->hw_ctx_3d and brw->hw_ctx_compute), so both the 3D and compute pipes
> could operate without interfering with one another - we wouldn't need to
> consider state dirtied by one or the other.
> 
> Again, I think seeing a list of commands would help us figure out the
> best solution (hopefully both efficient and simple).
> 

I think using a separate context is not only an excellent idea, but I suspect
we'll eventually find that it's a requirement for some reason or another. My
assumption echoes yours WRT to very little overlap, and I think your comments
mimic some of my questions as well, so I see no need for Jordan to respond to my
mail.

The only modification to your request that I would ask is that Jordan send a
list of where there is perceived overlap as opposed to sending the full list of
state (let him do the work :P).

> > Therefore, when we we upload dirty state before running compute
> > operations, it is possible (and apparently likely) that the
> > brw_vertices state atom will call this code.
> > 
> > When I removed the separate compute state tracking pipeline, I found I
> > only needed these two changes to be able to still use the current
> > state upload with compute.
> > 
> > -Jordan
> 
> That's surprisingly small!
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


-- 
Ben Widawsky, Intel Open Source Technology Center