Re: [Mesa3d-dev] Memory management - an AGP manager
Roland Scheidegger wrote: Keith Whitwell wrote: Right now, I'm primarily concerned with unified memory chipsets, like i915 and via. This memory manager would be suitable for managing the AGP memory on non-unified chipsets, but a different implementation would be needed for the on-card video ram, based more on dma and copying than map/unmapping as will be seen below. I'm not sure I quite understand that, do you propose completely separate managers for handling agp and video ram? You're right, I had been thinking as if the two managers could be made disjoint. I guess there will need to be either a mechanism for multiple backends behind the common API, or else the future Video RAM manager I refer to will actually be an extension of the AGP manager I propose which includes handling of Video RAM as well. In any case, I feel that there are benefits in tackling the AGP only case first, basically getting something up and running in a simplified environment to validate aspects of the design before tackling the full problem. Keith --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Memory management - an AGP manager
Keith Whitwell wrote: 1) I think this is the first solution for memory management that I can imagine implementing. Also it's one which gives reasonable performance when data is being evicted from the GART. This sounds a little trite reading it back. This a function of two things, firstly that I've thought more about this implementation than any other but also crucially that I've been able to find straightforward answers to most of the problems that have come up about the behaviour of the manager. It seems to me that this could be implemented in a small to mid sized project and beyond the extensions to the AGP module for map/unmapping doesn't have too many scary implementation black holes. It also seems like the drivers wouldn't change too drastically as a result of adopting this memory manager. I've not mentioned replacement algorithms at all as I feel that the design doesn't place any constraints on the choice of replacement algorithm, pretty much anything can be implemented inside of ValidateBuffer() and the rest of the design would be unaffected. Keith --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Memory management - an AGP manager
Keith Whitwell wrote: Right now, I'm primarily concerned with unified memory chipsets, like i915 and via. This memory manager would be suitable for managing the AGP memory on non-unified chipsets, but a different implementation would be needed for the on-card video ram, based more on dma and copying than map/unmapping as will be seen below. I'm not sure I quite understand that, do you propose completely separate managers for handling agp and video ram? I think this introduces some problems for things which can be both in agp or video ram. Some cards for instance may be able to render to agp memory, though the performance hit may be so big that you really want to use video memory unless you simply don't have enough video mem. A very common case which can use both video memory and agp memory are textures, for performance reasons you usually want to place them in video memory, but putting some textures into agp memory is a lot faster than texture thrashing. I guess you could handle that at the driver level (since it has always access to all ram) but performance may potentially suffer quite a bit if multiple apps are running at the same time which stomp over each others buffer (which could be better avoided with a coordinated scheme by allocating some buffers in agp memory instead of video ram). Roland --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
