-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith Packard wrote: | On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote: | |> 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. | | It really only depends on the CPU and bus architecture; the GPU | architecture is not relevant here. The cost is getting data from the CPU | into the GPU cache coherence domain, currently that involves actually | writing the data from the CPU over some kind of bus to physical memory. | |> 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. :) | | You'd be wrong then -- the cost of the malloc/write/copy/free is cheaper | than the cost of map/write/unmap.
Using glMapBuffer does not necessarily mean that the driver is doing map/write/unmap. In fact, based on measurements I took back in 2006, fglrx doesn't (or didn't at the time, anyway). See section 4.3 of http://web.cecs.pdx.edu/~idr/publications/ddc2006-opengl_immediate_mode.pdf It means that the driver *CAN DO THAT IF IT WANTS TO.* Some drivers are some platforms are clearly doing that, and they're running really fast. ~ Using glBufferSubData *FORCES* the driver to do the copy and *FORCES* the app to do extra buffer management. Apps are using and will increasingly use the glMapBuffer path. With the information currently at hand, doing the alloc/copy/upload/free in the driver might be the win. Great. It's way too soon to box ourselves into that route. If we're going to be stuck with an unchangeable interface for another 5 years, it had better be flexible enough to support more than one way to do things under the sheets. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMhrlX1gOwKyEAw8RArwCAJ9fHW/TXdwpiXro6LIjk6twgaT36ACfVywo iwIy4DMhiybnmOo1Myk4Hps= =j+Uc -----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
