-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith Packard wrote:
| On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
|
|>      glBindBuffer(GL_ARRAY_BUFFER, my_buf);
|>      GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
|>      if (data == NULL) {
|>              /* fail */
|>      }
|>
|>      /* Fill in buffer data */
|>
|>      glUnmapBuffer(GL_ARRAY_BUFFER);
|>
|> Over:
|>
|>      GLfloat *data = malloc(buffer_size);
|>      if (data == NULL) {
|>              /* fail */
|>      }
|>
|>      /* Fill in buffer data */
|>
|>      glBindBuffer(GL_ARRAY_BUFFER, my_buf);
|>      glBufferSubData(GL_ARRAY_BUFFER, 0, buffer_size, data);
|>      free(data);
|
| In terms of system performance, that 'extra copy' is not a problem
| though; the only cost is the traffic to the graphics chip, and these
| both do precisely the same amount of work. The benefit to the latter
| approach is that we get to use cache-aware copy code. The former can't
| do this as easily when updating only a portion of the data.

It depends on the hardware.  In the second approach the driver has no
opportunity to do something "smart" if the copy path isn't the fast
path.  Applications are being tuned more for the hardware where the copy
path isn't the fast path.

|> The second version obviously has extra overhead and takes a performance
|> hit.
|
| My measurements show that doing a cache-aware copy is a net performance
| win over using cache-ignorant word-at-a-time writes.

The obvious overhead I was referring to is the extra malloc / free.
That's why I went on to say "So, now I have to go back and spend time
caching the buffer allocations and doing other things to make it fast."
~ In that context, "I" is idr as an app developer. :)

One problem that we have here is that none of the benchmarks currently
being used hit any of these paths.  OpenArena, Enemy Territory (I assume
this is the older Quake 3 engine game), and gears don't use MapBuffer at
all.  Unfortunately, any apps that would hit these paths are so
fill-rate bound on i965 that they're useless for measuring CPU overhead.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIMdFgX1gOwKyEAw8RAvTBAJ4vEFUkCalQuEadOdh99BFIcz4WAwCfQ8e+
omh7z+g5Ja6AABvs5zrsR4k=
=HXx2
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to