[Mesa-dev] Uniform Buffer Object implementation questions

Rogovin, Kevin kevin.rogovin at intel.com
Thu Oct 31 12:55:17 CET 2013


Hi all,

 I was looking at the UBO implementation for Gen7 and following the trail of brw_vs_ubo_surfaces (found in brw_vs_surface_state.c ). The part that made me wonder was the following trail:


  834       /* Because behavior for referencing outside of the binding's size in the
  835        * glBindBufferRange case is undefined, we can just bind the whole buffer
  836        * glBindBufferBase wants and be a correct implementation.
  837        */
  838       brw->vtbl.create_constant_surface(brw, bo, binding->Offset,
  839                                         bo->size - binding->Offset,
  840                                         &surf_offsets[i],
  841                                         shader->Type == GL_FRAGMENT_SHADER);

in  brw_wm_surface_state.c, function brw_upload_ubo_surfaces(). When looking at what Gen7 sets create_constant_surface, it is gen7_create_constant_surface which has this comment

"Create the constant buffer surface. Vertex/fragment shader constants will be read from this buffer with Data Port Read instructions/messages."

I am not yet very familiar with the labels for different parts of the hardware or their functionality. So I am guessing here. Is the Data Port Read able to essentially read anything in the GTT? Are the values cached? Going further, if it can do so, does that not mean that the size of a UBO can be arbitrarily big? On other GL implementations, the size of UBO is usually quite limited so that the contents of a UBO can essentially be mostly, if not fully, cached. The idea was that TBO would be slower but essentially unlimited size and UBO's faster (and formatted) but with much less size.

Any help that can point me in the correct would be much appreciated.

Best Regards
 -Kevin Rogovin


More information about the mesa-dev mailing list