[Mesa-dev] [PATCH 04/13] i965/draw: Delay when we get the bo for vertex buffers

Kenneth Graunke kenneth at whitecape.org
Fri May 20 06:24:22 UTC 2016


On Thursday, May 19, 2016 4:48:08 PM PDT Iago Toral wrote:
> On Thu, 2016-05-19 at 00:21 -0700, Jason Ekstrand wrote:
> > The previous code got the BO the first time we encountered it.  However,
> > this can potentially lead to problems if the BO is used for multiple 
arrays
> > with the same buffer object because the range we declare as busy may not 
be
> > quite right.  By delaying the call to intel_bufferobj_buffer, we can 
ensure
> > that we have the full range for the given buffer.
> > 
> > Cc: "10.2" <mesa-stable at lists.freedesktop.org>
> > ---
> >  src/mesa/drivers/dri/i965/brw_draw_upload.c | 71 +++++++++++++++++++
+---------
> >  1 file changed, 49 insertions(+), 22 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/
drivers/dri/i965/brw_draw_upload.c
> > index 3ec37f8..0a7725d 100644
> > --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > @@ -453,6 +453,11 @@ brw_prepare_vertices(struct brw_context *brw)
> >     if (brw->vb.nr_buffers)
> >        return;
> >  
> > +   /* The range of data in a given buffer represented as [min, max) */
> > +   struct intel_buffer_object *enabled_buffer[VERT_ATTRIB_MAX];
> > +   uint32_t buffer_range_start[VERT_ATTRIB_MAX];
> > +   uint32_t buffer_range_end[VERT_ATTRIB_MAX];
> > +
> >     for (i = j = 0; i < brw->vb.nr_enabled; i++) {
> >        struct brw_vertex_element *input = brw->vb.enabled[i];
> >        const struct gl_client_array *glarray = input->glarray;
> > @@ -460,12 +465,31 @@ brw_prepare_vertices(struct brw_context *brw)
> >        if (_mesa_is_bufferobj(glarray->BufferObj)) {
> >  	 struct intel_buffer_object *intel_buffer =
> >  	    intel_buffer_object(glarray->BufferObj);
> > -	 unsigned k;
> > +
> > +         const uint32_t offset = (uintptr_t)glarray->Ptr;
> 
> Should we use uint64_t instead or do we know that these offsets need to
> be within a 32-bit address?

The driver is full of these kinds of assumptions today.  Because it's
an offset into a buffer object, the only way it could exceed a uint32_t
is if the buffer was > 4GB in size.

Given that the aperture is only 4GB (or 2GB on earlier parts), I don't
think you can even use such a buffer with the GPU.

We might have to fix it someday, but I think it's fine for now.

--Ken
-------------- 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: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160519/609676b1/attachment.sig>


More information about the mesa-dev mailing list