On Wed, 2008-05-14 at 16:34 -0700, Allen Akin wrote: > On Wed, May 14, 2008 at 03:48:47PM -0700, Keith Packard wrote: > | Object mapping is really the least important part of the system; it > | should only be necessary when your GPU is deficient, or your API so > | broken as to require this inefficient mechanism. > > In the OpenGL case, object mapping wasn't originally a part of the API. > It was added because people building hardware and apps for Intel-based > PCs determined that it was worthwhile, and demanded it.
In a UMA environment, it seems so obvious to map objects into the application and just bypass the whole kernel API issue. That, however, ignores caching effects, which appear to dominate performance effects these days. > This wasn't on my watch, so I can't give you the history in detail, but > my recollection is that the primary uses were texture loading for games > and video apps, and incremental changes to vertex arrays for games and > rendering apps. Most of which can be efficiently performed with a pwrite-like system where the application explicitly tells the system which portions of the object to modify. Again, it seems insane when everything is a uniform mass of pages, except for the subtle differences in cache behaviour. > So maybe the hardware has changed sufficiently that the old reasoning > and performance measurements are no longer valid. It would still be > good to know for sure that eliminating low-level support for the > mechanism won't be drastically bad for the classes of apps that use it. I'm not sure we can (or want to) eliminate it entirely, all that I discovered was that it should be avoided as it has negative performance consequences. Not dire, but certainly not positive either. I don't know how old these measurements were, but certainly the gap between CPU and memory speed has been rapidly increasing for years, along with cache sizes, both of which have a fairly dramatic effect on how best to access actual memory. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
