<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#c33">Comment # 33</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:siglesias@igalia.com" title="Samuel Iglesias <siglesias@igalia.com>"> Samuel Iglesias</a> <pre>(In reply to Kristian Høgsberg from <a href="show_bug.cgi?id=89597#c32">comment #32</a>) > (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(). 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!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>