Ian Romanick <i...@freedesktop.org> writes: > From: Ian Romanick <ian.d.roman...@intel.com> > > The checks to determine when the data can be uploaded in an interleaved > fashion can be tricked by certain data layouts. For example, > > float data[...]; > > glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 16, &data[0]); > glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 16, &data[4]); > glDrawArrays(GL_POINTS, 0, 1); > > will hit the interleaved path with an incorrect size (16 bytes instead > of 32 bytes). As a result, the data for attribute 1 never gets > uploaded. The single element draw case is the only sensible case I can > think of for non-interleaved-that-looks-like-interleaved data, but there > may be others as well. > > I don't see an easy way to fix the checks, so I have chosen to just rip > out the optimization. This may cause performance issues on applications > that use large arrays of data that are not in VBOs.
Check that count * strideb actually contains the data you're hoping to read from the later attributes? Seems pretty doable. As is, this hurts cairo-gl performance by 1.9034% +/- 0.441538% (n=33/34, 3 throttling outliers removed)
pgpEb4SBtrQyC.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
