[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 #31 from Jason Ekstrand <jason at jlekstrand.net> ---
(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.

-- 
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/20150423/9d6318f8/attachment.html>