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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
