On Wed, May 14, 2008 at 05:22:06PM -0700, Keith Packard wrote: | On Wed, 2008-05-14 at 16:34 -0700, Allen Akin wrote: | > 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.
I think the confusion arises because the mechanism is used for several purposes, some of which are likely to be dominated by cache effects on some implementations, and others that aren't. I'm thinking about the differences between piecemeal updating of the elements of a vertex array, versus grabbing an image from a video capture card or a direct read() from a file into a texture buffer. The API is intended to allow apps and drivers to make intelligent choices between cases like those. Check out BufferData() and MapBuffer() in section 2.9 of the OpenGL 2.1 spec for a discussion which specifically mentions cache effects. | > 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. ... Interfaces of that style are present in OpenGL, and predate the mapping interfaces. I know they were regarded as too slow for some apps, so the mapping interfaces were added. The early extensions were driven by vendors who didn't support UMA, so that couldn't have been the only model they were concerned about. Beyond that I'm not sure. | > 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. The first reference I can find to an object-mapping API in OpenGL is from 2001. I'm sure the vendors had implementations internally before then, but that's when things were mature enough to start standardizing. Since the functionality is present in OpenGL 2.0 (vintage 2006?), apparently someone thought it was still useful enough to carry over from OpenGL 1.X. Again, sorry I don't know the entire history on this one. Allen ------------------------------------------------------------------------- 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
