[Bug 89597] Implement SSBOs in GLSL front-end and i965

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89597

--- Comment #33 from Samuel Iglesias <siglesias at igalia.com> ---
(In reply to Kristian Høgsberg from comment #32)
> (In reply to Jason Ekstrand from comment #31)
> > (In reply to Samuel Iglesias from comment #30)
> > > I have been working on the .length() calculation of unsized arrays in SSBOs.
> > > As it was said in comment 2, the size of the allocated buffer by the GPU can
> > > be queried by resinfo message. I have that code working fine with that
> > > approach but recently I discovered an inconsistency:
> > > 
> > > Intel driver is allocating internally buffers of multiples of 4k (see buffer
> > > object returned by intel_bufferobj_buffer() in brw_upload_ubo_surfaces()),
> > > so if the user wants a buffer of size 32 bytes, it would allocate a buffer
> > > of 4096 bytes. Then, the emitted resinfo message returns 4096.
> > 
> > Yes, it does.  There are a couple of reasons for this.  First, is that
> > kernel bo's (I think) work in terms of whole pages.  Second, drm has an
> > internal buffer cache for recycling buffers.  If you ask it for a new buffer
> > and there is already a free one available of the correct size, you get that
> > one instead of a new one.  We do this to save on some of the up-front costs
> > of creating and mapping buffers.  However, in order for this to work, we
> > have to greatly reduce the number of different possible sizes.  I think
> > there's also a power-of-two size restriction in there somewhere to
> > accomplish this.
> > 
> > > However if the application executes glGetBufferParameteriv(GL_BUFFER_SIZE)
> > > it will return 32 bytes and I suppose this is the buffer size value that
> > > should be used for unsized array's length calculations.
> > 
> > Yes, we want to use what the client thinks is the size for those
> > calculations.  Otherwise, the client will get very confused.
> > 
> > > How can I fix this inconsistency?
> > 
> > I'm not particularly familiar with the resinfo message.  However, there is
> > another message that we use to implement the textureSize function.  This one
> > reads the width/height out of the SURFACE_STATE object and hands that back. 
> > Given that an SSBO has to have a surface state associated with it since it
> > goes in the binding table, you could probably use this message to pull the
> > length out.
> > 
> > > Should I modify intel_bufferobj_buffer() to return a buffer object of the
> > > same size it was asked for and not round it up to multiples of 4k? Is there
> > > a good reason for that behavior?
> > 
> > Explained above.
> 
> The allocations in mesa and gem buffer objects in the kernel are all just sw
> abstractions. They're rounded up and aligned for various reasons, but once
> the hardware starts executing a batchbuffer it's all a big linear address
> space. The only size the hardware sees is what we put in the SURFAFCE_STATE
> object. This is filled in in gen4/gen7/gen8_emit_buffer_surface_state(). The
> problem is in brw_upload_ubo_surfaces() where we use the size from the
> drm_intel_bo instead of the API provided size from binding->BufferObject in
> the calls to brw_create_constant_surface() and your new
> brw_create_buffer_surface().

Thanks both for your comments!

Khristian, I used the size from binding->BufferObject when calling
brw_create_buffer_surface() and everything is working fine now. I am going to
do the same for the brw_create_constant_surface() call.

Thanks again!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150424/f8fd6bd2/attachment.html>