Copying data to VAR..

I’m trying to update vertex data per frame (using VAR and AGP memory),
but I’m not sure if this is faster than a simple memcpy:

 GLfloat*   VAR_vertex_xyz_ptr  =  &VAR_vertex_xyz [0];
 GLfloat*       vertex_xyz_ptr  =  &    vertex_xyz [0];
 GLfloat*   VAR_vertex_st_ptr   =  &VAR_vertex_st  [0];
 GLfloat*       vertex_st_ptr   =  &    vertex_st  [0];

 for (DWORD v = 0; v < vertex_count; v ++) {
      *VAR_vertex_xyz_ptr++  =  *vertex_xyz_ptr++;  // x
      *VAR_vertex_xyz_ptr++  =  *vertex_xyz_ptr++;  // y
      *VAR_vertex_xyz_ptr++  =  *vertex_xyz_ptr++;  // z
      *VAR_vertex_st_ptr++   =  *vertex_st_ptr++;   // s
      *VAR_vertex_st_ptr++   =  *vertex_st_ptr++;   // t

Anyone knows if using MMX or SSE to accelerate the transfer, actually
accelerates something? (using movq, for example), or it doesn’t care
because I’m using the AGP bus?

And how/when should I use glFlushVertexArrayRangeNV ?


  • Royconejo.

ALWAYS use sequential, aligned writes to AGP. It looks like you are alternating between writing to two separate arrays. This will destroy AGP performance.

You must use FlushVertexArrayRangeNV before modifying any element of data in your VAR that is currently “owned” by the GPU. When you call DrawElements on some vertex data, any data that you dereference in that call is now considered to be owned by the GPU until you synchronize. FlushVertexArrayRangeNV is SLOW. Therefore, dynamic geometry apps should always use the fence extension.

  • Matt

Thanks… I’ll use memcpy.

Do you know if using MMX is faster? I mean, calling some function like “mmxcpy” instead of memcpy, gives some speed improvement or not…

  • Royconejo.