<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597#c32">Comment # 32</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597">bug 89597</a> from <a class="email" href="mailto:krh@bitplanet.net" title="Kristian Høgsberg <krh@bitplanet.net>"> Kristian Høgsberg</a> <pre>(In reply to Jason Ekstrand from <a href="show_bug.cgi?id=89597#c31">comment #31</a>) > (In reply to Samuel Iglesias from <a href="show_bug.cgi?id=89597#c30">comment #30</a>) > > I have been working on the .length() calculation of unsized arrays in SSBOs. > > As it was said in <a href="show_bug.cgi?id=89597#c2">comment 2</a>, 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().</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>