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

[Kenneth Graunke]

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).

> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141122/2013f4d9/attachment-0001.sig>