U.S. patent application number 09/247194 was filed with the patent office on 2001-11-15 for converting non-contiguous memory into contiguous memory for a graphics processor.
Invention is credited to SETHI, PRASHANT.
Application Number | 20010042184 09/247194 |
Document ID | / |
Family ID | 22933974 |
Filed Date | 2001-11-15 |
United States Patent
Application |
20010042184 |
Kind Code |
A1 |
SETHI, PRASHANT |
November 15, 2001 |
CONVERTING NON-CONTIGUOUS MEMORY INTO CONTIGUOUS MEMORY FOR A
GRAPHICS PROCESSOR
Abstract
A method and apparatus for managing memory used by a device
driver in an operating system. The method comprises: (i)
configuring a chipset to set up a mapping table for memory address
translation, (ii) allocating a device memory in response to a
request by the device driver, and (iii) mapping non-contiguous
system memory to contiguous device memory using the mapping
table.
Inventors: |
SETHI, PRASHANT; (FOLSOM,
CA) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN
12400 WILSHIRE BOULEVARD
SEVENTH FLOOR
LOS ANGELES
CA
90025
|
Family ID: |
22933974 |
Appl. No.: |
09/247194 |
Filed: |
February 9, 1999 |
Current U.S.
Class: |
711/206 ;
345/568; 711/135; 711/170 |
Current CPC
Class: |
G06F 12/0804 20130101;
G09G 2360/125 20130101; G09G 5/39 20130101; G09G 2360/12 20130101;
G06F 12/0253 20130101 |
Class at
Publication: |
711/206 ;
711/170; 711/135; 345/568 |
International
Class: |
G06F 012/10 |
Claims
What is claimed is:
1. A method for managing memory used by a device driver in an
operating system, the method comprising: configuring a chipset to
set up a mapping table for memory address translation; allocating
device memory in response to a request by the device driver; and
mapping non-contiguous system memory to contiguous device memory
using the mapping table.
2. The method of claim 1 wherein the configuring of the chipset
comprises: programming the mapping table; and reloading the mapping
table.
3. The method of claim 1 wherein the allocating of the device
memory comprises: determining if memory pages are available to
satisfy the request; allocating a memory page from the device
memory to the device driver; freeing a memory page committed to the
device memory; and returning memory from the device memory to the
operating system.
4. The method of claim 1 wherein the mapping of the noncontiguous
system memory comprises: initializing management parameters;
validating control request from the device driver; reserving memory
pages in the device memory; and committing system memory to the
reserved memory pages.
5. The method of claim 4 further comprising: uncommitting committed
system memory when committed system memory is not used; and freeing
reserved memory pages when the reserved memory pages are not
used.
6. The method of claim 4 wherein the initializing of the management
parameters comprises: limiting a graphic port aperture to a
predefined aperture size; allocating memory for the mapping table;
and enabling the mapping table.
7. The method of claim 4 wherein the reserving of memory pages
comprises: locating a free block in the device memory in a free
block list and a page list; mapping the free block to the system
memory using the mapping table; and updating the free block list
and the page list.
8. The method of claim 4 wherein the committing of the system
memory comprises: determining if the reserved memory pages are
sufficient; allocating system memory to correspond to the reserved
memory pages; and updating an allocation list.
9. The method of claim 5 wherein the uncommitting of the committed
system memory comprises: obtaining an entry to the mapping table
corresponding to the committed system memory; disabling the entry;
and updating a free page list.
10. The method of claim 5 wherein the freeing of the reserved
memory pages comprises: merging the reserved memory pages with
existing free block items; and removing an reserved entry.
11. A computer program product comprising: a computer usable medium
having computer program code embodied therein for managing memory
used by a device driver in an operating system, the computer
program product having: (a) computer readable program code for
configuring a chipset to set up a mapping table for memory address
translation; (b) computer readable program code for allocating
device memory in response to a request by the device driver; and
(c) computer readable program code for mapping non-contiguous
system memory to contiguous device memory using the mapping
table.
12. The computer program product of claim 11 wherein (a) comprises:
(a1) computer readable program code for programming the mapping
table; and (a2) computer readable program code for reloading the
mapping table.
13. The computer program product of claim 11 wherein (b) comprises:
(b1) computer readable program code for determining if memory pages
are available to satisfy the request; (b2) computer readable
program code for allocating a memory page from the device memory to
the device driver; (b3) computer readable program code for freeing
a memory page committed to the device memory; and (b4) computer
readable program code for returning memory from the device memory
to the operating system.
14. The computer program product of claim 11 wherein (c) comprises:
(c1) computer readable program code for initializing management
parameters; (c2) computer readable program code for validating
control request from the device driver; (c3) computer readable
program code for reserving memory pages in the device memory; and
(c4) computer readable program code for committing system memory to
the reserved memory pages.
15. The computer program product of claim 14 further comprising:
(c5) computer readable program code for uncommitting committed
system memory when committed system memory is not used; and (c6)
computer readable program code for freeing reserved memory pages
when the reserved memory pages are not used.
16. The computer program product of claim 14 wherein (c1)
comprises: (c11) computer readable program code for limiting a
graphic port aperture to a predefined aperture size; (c12) computer
readable program code for allocating memory for the mapping table;
and (c13) computer readable program code for enabling the mapping
table.
17. The computer program product of claim 14 wherein (c3)
comprises: (c31) computer readable program code for locating a free
block in the device memory in a free block list and a page list;
(c32) computer readable program code for mapping the free block to
the system memory using the mapping table; and (c33) computer
readable program code for updating the free block list and the page
list.
18. The computer program product of claim 14 wherein (c4)
comprises: (c41) computer readable program code for determining if
the reserved memory pages are sufficient; (c42) computer readable
program code for allocating system memory to correspond to the
reserved memory pages; and (c43) computer readable program code for
updating an allocation list.
19. The computer program product of claim 15 wherein (c5)
comprises: (c51) computer readable program code for obtaining an
entry to the mapping table corresponding to the committed system
memory; (c52) computer readable program code for disabling the
entry; and (c53) computer readable program code for updating a free
page list.
20. The computer program product of claim 15 wherein (c6)
comprises: (c61) computer readable program code for merging the
reserved memory pages with existing free block items; and (c62)
computer readable program code for removing an reserved entry.
21. A system comprising: a chipset having a mapping table for
memory address translation; and a memory manager for managing
memory used by a device driver in an operating system, the memory
manager comprising: a chipset specific functions module to
configure the chipset to set up the mapping table, an internal
services module to allocate device memory in response to a request
by the device driver, and an exported services module to map
non-contiguous system memory to contiguous device memory using the
mapping table.
22. The system of claim 21 wherein the chipset specific functions
module comprises: a program chipset function to program the mapping
table; and a flush and enable function to reload the mapping
table.
23. The system of claim 21 wherein the internal services module
comprises: a test function to determine if memory pages are
available to satisfy the request; an allocate function to allocate
a memory page from the device memory to the device driver; a memory
free function to free a memory page committed to the device memory;
and a garbage collector to return memory from the device memory to
the operating system.
24. The system of claim 21 wherein the exported services module
comprises: an initializing function to initialize management
parameters; a control function to validate control request from the
device driver; a reservation function to reserve memory pages in
the device memory; and a commit function to commit system memory to
the reserved memory pages;
25. The system of claim 24 further comprising: an uncommit function
to uncommit committed system memory when committed system memory is
not used; and a free function to free reserved memory pages when
the reserved memory pages are not used.
Description
BACKGROUND
[0001] 1. Field of the Invention
[0002] This invention relates to graphics processors. In
particular, the invention relates to memory manager for a graphics
processor.
[0003] 2. Description of Related Art
[0004] Advances in graphics design have provided many enhanced
graphic performance in a general purpose computing environment. In
a general purpose computing environment, an operating system (OS)
provides a useful and efficient platform for the users and
applications programs. One particularly important function in an OS
is the management of hardware resources, especially the use of
memory. Due to the complexity of memory architecture and usage in a
high performance processor environment, memory management has
become a central objective in modern OS design. However, a
general-purpose OS cannot provide direct memory management for
graphics applications programs because of the specialized nature of
the graphics processor.
[0005] A modern graphics processor typically has the ability to
access the system memory for graphic usage in addition to its local
memory. Therefore, the problem of managing memories for a graphics
processor in a general purpose computing environment has become
difficult. For example, most graphic applications are memory
intensive. To enhance graphic performance, graphic memory is
preferably organized in a contiguous fashion. Scattered memory
blocks require additional operations resulting in degraded
performance. Therefore, an important feature of a memory management
scheme is to convert the physically non-contiguous pages of
physical system memory into contiguous memory for use by the
graphics processor. In addition, other operations involving memory
allocation, de-allocation, and configuration of interfacing chipset
are necessary to provide a systematic and convenient facility to
the device drivers for use by the applications programs.
[0006] Therefore, there is a need in the technology to provide a
simple and efficient method to manage memory for a graphics
processor.
SUMMARY
[0007] In one embodiment, the present invention relates to a method
for managing memory used by a device driver in an operating system.
The method comprises: (i) configuring a chipset to set up a mapping
table for memory address translation, (ii) allocating a device
memory in response to a request by the device driver, and (iii)
mapping non-contiguous system memory to contiguous device memory
using the mapping table.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The features and advantages of the present invention will
become apparent from the following detailed description of the
present invention in which:
[0009] FIG. 1 is a diagram illustrating a computer system in which
one embodiment of the invention can be practiced.
[0010] FIG. 2 is a diagram illustrating the architecture of the
memory manager according to one embodiment of the invention.
[0011] FIG. 3A is a pseudo code implementation of the Program
Chipset GART_Base function according to one embodiment of the
invention.
[0012] FIG. 3B is a pseudo code implementation of the
GART_Flush_And_Enable function according to one embodiment of the
invention.
[0013] FIG. 3C is a pseudo code implementation of the
AGP_Memory_Allocate_Test function according to one embodiment of
the invention.
[0014] FIG. 3D is a pseudo code implementation of the
AGP_Memory_Allocate function according to one embodiment of the
invention.
[0015] FIG. 3E is a pseudo code implementation of the
AGP_Memory_Free function according to one embodiment of the
invention.
[0016] FIG. 3F is a pseudo code implementation of the
AGP_Garbage_Collect function according to one embodiment of the
invention.
[0017] FIG. 3G is a pseudo code implementation of the
Flush_CPU_Cache function according to one embodiment of the
invention.
[0018] FIG. 3H is a pseudo code implementation of the
AGP_Memory_Manager_Initialize function according to one embodiment
of the invention.
[0019] FIG. 3I is a pseudo code implementation of the
AGP_IOctl_Service function according to one embodiment of the
invention.
[0020] FIG. 3J is a pseudo code implementation of the GART_Reserve
function according to one embodiment of the invention.
[0021] FIG. 3K is a pseudo code implementation of the GART_Commit
function according to one embodiment of the invention.
[0022] FIG. 3L is a pseudo code implementation of the GART_Uncommit
function according to one embodiment of the invention.
[0023] FIG. 3M is a pseudo code implementation of the GART_Free
function according to one embodiment of the invention.
[0024] FIG. 3N is a pseudo code implementation of the
GART_Mem_Attribute function according to one embodiment of the
invention.
DESCRIPTION
[0025] The present invention is a method and apparatus for managing
memory in a graphic environment. A memory manager is interfaced to
the operating system and the graphics hardware to perform memory
management tasks including configuration of a chipset, and
allocation and de-alllocation of memory in response to a memory
request by a device driver. The memory manager maps non-contiguous
system memory to contiguous device memory by using a mapping table
in the chipset. The technique provides an efficient scheme to
manage memory.
[0026] In the following description, for purposes of explanation,
numerous details are set forth in order to provide a thorough
understanding of the present invention. However, it will be
apparent to one skilled in the art that these specific details are
not required in order to practice the present invention. In other
instances, well known electrical structures and circuits are shown
in block diagram form in order not to obscure the present
invention. In the following description, the term "module" refers
to a functional block that performs a specified task. A module can
be implemented by hardware or software.
[0027] FIG. 1 is a diagram illustrating a computer system 100 in
which one embodiment of the invention can be practiced. The
computer system 100 includes N processors 105.sub.1 through
105.sub.N, a host bus 110, a host bridge chipset 120, a system
memory 130, a graphics processor 140, a digital video disk (DVD)
device 122, a video device 142, a decoder 124, a display monitor
144, a television (TV) 148, an encoder 146, a graphics local memory
150, a primary PCI bus #0 155, a PCI bus #1 145, an accelerated
graphics port (AGP) 141, K PCI slots 160.sub.1 to 160.sub.K, a
network interface 162, a media interface 164, a PCI-to-ISA bridge
170, mass storage devices 172, Input/Output (I/O) ports 174, an ISA
bus 180, and ISA slots 185.sub.1 to 185.sub.M.
[0028] Each of the processors 105.sub.1 to 105.sub.N represents a
central processing unit of any type of architecture, such as
complex instruction set computers (CISC), reduced instruction set
computers (RISC), very long instruction word (VLIW), or hybrid
architecture. The invention could be implemented in a
multi-processor or single processor computer system.
[0029] The host bridge chipset 120 includes a number of interface
circuits to allow the host processors 105.sub.1 to 105.sub.N access
to the system memory 130, the graphics processor 140, and the
primary PCI bus #0 155. The system memory 130 represents one or
more mechanisms for storing information. For example, the system
memory 130 may include non-volatile or volatile memories. Examples
of these memories include flash memory, read only memory (ROM), or
random access memory (RAM). The system memory 130 includes an
operating system (OS) 131, a memory manager 132, a bit-packed font
clipping module 134, an AGP memory block 135, and other programs
and data 138. Of course, the system memory 130 preferably contains
additional software (not shown), which is not necessary to
understanding the invention.
[0030] When implemented in software, the elements of the memory
manager 132 and the bit-packed font clipping module 134 are
essentially the code segments to manage memory and to enhance the
hardware clipping ability of the graphics processor, respectively.
The program or code segments can be stored in a processor readable
medium. The "processor readable medium" may include any medium that
can store or transfer information. Examples of the processor
readable medium include an electronic circuit, a semiconductor
memory device, a read-only memory (ROM), a flash memory, an
erasable ROM (EROM), a floppy diskette, a compact disk (CD) ROM, an
optical disk, a hard disk, a transmission medium, a fiber optic
medium, a radio frequency (RF) link, etc. The PCI slots 160.sub.1
to 160.sub.K provide interfaces to PCI devices. Examples of PCI
devices include the network interface 162 and the media interface
164. The network interface 162 connects to communication channel
such as the Internet. The Internet provides access to on-line
service providers, Web browsers, and other network channels. The
media interface 164 provides access to audio and video devices.
[0031] The graphics processor 140 is a high performance graphics
controller that perform graphics functions such as 3-D rendering
operations, progressive meshes, painting, drawing, etc. The
graphics processor 140 is coupled to the host bridge 120 via the
AGP 141 and the PCI bus #1 145. In one embodiment, the AGP 141 is
developed by Intel Corporation of Santa Clara, Calif. The graphics
processor 140 has access to its own graphics local memory 150. The
graphic local memory 150 may contain graphics programs and data for
displaying. The DVD device 122 represents any digital video device
or instrument. The video device 142 provides video input such as
DVD, camera, or video cassette recorder (VCR) to the graphics
processor 140. The decoder 124 decodes the video signals from the
video device 142 to the graphics processor 140. The display monitor
144 displays the graphics as generated by the graphics processor
140. The encoder 146 receives the graphics data from the graphics
controller 140 and encodes into an analog signal to be compatible
for TV display on the TV set 148.
[0032] The PCI-to-ISA bridge provides access to the ISA bus 180,
mass storage devices 172, and I/O ports 174. The mass storage
devices 172 include CD ROM, floppy diskettes, and hard drives. The
ISA bus 180 has a number of ISA slots 1851 to 185M to interface to
ISA devices. Examples of ISA devices include data entry devices
(e.g., keyboard, mouse), printers, etc.
[0033] FIG. 2 is a diagram illustrating the memory manager 200
according to one embodiment of the present invention. The memory
manager 200 interfaces to the chipset 120 and the device driver
280.
[0034] The host bridge chipset 120 has a graphics address
re-mapping table (GART) 202. The GART 202 gives AGP devices a
contiguous view of the AGP memory. The AGP aperture addresses are
mapped into the system memory in 4 KB pages via the GART 202. The
GART 202 has a graphics translation lookaside buffer (GTLB) 204.
The GTLB 204 is a cache for the translation table entries located
in the GART 202. The GTLB 204 is disabled and flushed whenever the
GART is updated.
[0035] The device driver 280 includes a display driver 282 and a
miniport driver 284. The display driver 282 includes program code
to interface to display devices. The miniport driver 284 includes
program code for interfacing to the miniport.
[0036] The memory manager 200 includes three modules: a chipset
specific functions module 210, an internal services module 220, and
an export services module 240. The memory manager 200 can be stored
on a computer readable medium such as CDROM, floppy diskettes, hard
disk, optical disks, etc. The computer readable medium stores
program code to perform the functions in the chipset specific
functions module 210, the internal services module 220, and the
export services module 240 as described below.
[0037] The chipset specific functions module 210 provides functions
to configure and program the chipset. The chipset specific
functions module 210 includes two functions: a
Program_Chipset_GART_Base 212 and a GART_flush_and_enable 214. The
Program_Chipset_GART_Base 212 programs the chipset GART table
address. The GART_flush_and_enable 214 reloads the chipset GART
table.
[0038] The internal services module 220 provides internal functions
to the memory manager 200. These internal functions are not
accessible from the device driver 280 and are mainly used
internally by the memory manager 200 to implement external or other
internal functions. The internal services module 220 includes at
least five functions: an AGP_Memory_Allocate_Test 222, an
AGP_Memory_Allocate 224, an AGP_Memory_Free 226, an
AGP_Garbage_Collect 228, and a Flush_CPU_Cache 232. The
AGP_Memory_Allocate_Test 222 validates that enough free pages are
available to satisfy an AGP memory commit request of a given size.
If enough pages are not available, an attempt is made to grow the
pool of available pages and satisfy the request. The
AGP_Memory_Allocate 224 allocates a single page from the AGP memory
pool. Usually, the AGP_Memory_Allocate_Test 222 is called before
the AGP_Memory_Allocate 224 is called. The AGP_Memory_Free 226
frees a single page which has been committed to the AGP memory. The
AGP_Garbage_Collect 228 returns memory from the AGP pool to the
operating system if possible. The Flush_CPU_Cache 232 flushes the
processor cache on all processors in a multi-processor safe
environment.
[0039] The export services module 240 provides the interface to the
device driver 280. The device driver 280 can call functions in this
module by supplying the appropriate device object. The export
services module 240 includes an AGP_Memory_Manager_Initialize 242,
an AGP_Ioctl_Service 244, a GART_Reserve 246, a GART_Commit 248, a
GART_Uncommit 252, a GART_Free 254, and a GART_Mem_Attribute 256.
The AGP_Memory_Manager_Initialize 242 initializes the memory
manager. Usually, the graphics adapter detection code has been
detected and the chipset has been enumerated before this function
is called. The AGP_Ioctl_Service 244 provides an input/output
control level interface to the memory manager services. The
GART_Reserve 246 reserves a specified number of pages of the device
memory. The GART_Commit 248 allocates system memory and commits it
to the previously reserved device memory. The GART_Uncommit 252
frees the system memory and uncommits device memory. The GART_Free
254 frees the number of pages of device memory reserved with the
GART_Reserve 246. The GART_Mem_Attribute 256 returns the attributes
of a specified block of memory.
[0040] FIG. 3A is a pseudo code implementation of the
Program_Chipset_GART_Base 212 function according to one embodiment
of the invention. The parameters of the Program_Chipset_GART_Base
212 include a HwDeviceExtension parameter. The HwDeviceExtension
parameter specifies the device extension used by the device driver.
The Program_Chipset_GART_Base 212 has no return value.
[0041] The Program_Chipset_GART_Base 212 performs the following
operations: programming the PAC configuration register (PACCFG) to
leave the PCI Agent to Aperture Access enabled and to disable the
aperture global access, disabling the GTLB, enabling the AGP
aperture, and enabling the GTLB.
[0042] FIG. 3B is a pseudo code implementation of the
GART_Flush_And_Enable function according to one embodiment of the
invention. The parameters of the GART_Flush_And_Enable 214 include
a HwDeviceExtension parameter. The HwDeviceExtension parameter
specifies the device extension used by the device driver. The
GART_Flush_And_Enable 214 has no return value.
[0043] The GART_Flush_And_Enable 214 performs the following
operations: programming the PAC configuration register (PACCFG) to
leave the PCI Agent to Aperture Access enabled and to disable the
aperture global access, disabling the GTLB, enabling the AGP
aperture, and enabling the GTLB.
[0044] FIG. 3C is a pseudo code implementation of the
AGP_Memory_Allocate_Test 222 function according to one embodiment
of the invention. The parameters of the AGP_Memory_Allocate_Test
222 include a HwDeviceExtension parameter and a numPages parameter.
The HwDeviceExtension parameter specifies the device extension used
by the device driver. The numPages parameter specifies the number
of pages requested to be available for commit. The
AGP_Memory_Allocate_Test 222 returns TRUE for success. The
AGP_Memory_Allocate_Test 222 is normally called before the
AGP_Memory_Allocate 224 is called. The AGP_Memory_Allocate_Test 222
is one service that can grow the memory pool available for AGP
allocation.
[0045] The AGP_Memory_Allocate_Test 222 performs the following
operations: searching for a free memory block entry, mapping the
address if a free entry is found, and garbage collecting if there
is no more free entry from the operating system.
[0046] FIG. 3D is a pseudo code implementation of the
AGP_Memory_Allocate 224 function according to one embodiment of the
invention. The parameters of the AGP_Memory_Allocate 224 include a
HwDeviceExtension parameter. The HwDeviceExtension parameter
specifies the device extension used by the device driver. The
AGP_Memory_Allocate 224 returns the physical address for the
allocated page. The AGP_Memory_Allocate_Test 222 is normally called
before the AGP_Memory_Allocate 224 is called.
[0047] The AGP_Memory_Allocate 224 performs the following
operations: searching for a free page, updating the memory counter
and page counter, obtaining the physical address of the allocated
page, marking the selected page as allocated, and updating the
number of pages available.
[0048] FIG. 3E is a pseudo code implementation of the
AGP_Memory_Free 226 function according to one embodiment of the
invention. The parameters of the AGP_Memory_Free 226 include a
HwDeviceExtension parameter and a AGPAddress parameter. The
HwDeviceExtension parameter specifies the device extension used by
the device driver. The AGPAddress parameter specifies the physical
address of the page to be freed. The AGP_Memory_Free 226 has no
return value. The AGP_Memory_Free 226 frees a page that has been
previously allocated by the AGP_Memory_Allocate 224. The
AGP_Memory_Free 226 may also shrink the size of the AGP memory pool
by returning memory to the operating system.
[0049] The AGP_Memory_Free 226 performs the following operations:
updating memory counter and page counter, marking a freed page as
free, updating the number of available pages, and garbage
collecting and returning memory to the operating system if
possible.
[0050] FIG. 3F is a pseudo code implementation of the
AGP_Garbage_Collect 228 function according to one embodiment of the
invention. The parameters of the AGP_Garbage_Collect 228 include a
HwDeviceExtension parameter. The HwDeviceExtension parameter
specifies the device extension used by the device driver. The
AGP_Garbage_Collect 228 has no return value. The
AGP_Garbage_Collect 228 shrinks the size of the AGP memory pool by
returning memory to the operating system. A minimum pool of the AGP
memory is always maintained.
[0051] The AGP_Garbage_Collect 228 performs the following
operations: updating memory counter, freeing a memory, flushing the
cache, and initializing the linear addresses and the number of
available pages.
[0052] FIG. 3G is a pseudo code implementation of the
Flush_CPU_Cache 232 function according to one embodiment of the
invention. The Flush_CPU_Cache 232 has no parameters and no return
value. The Flush_CPU_Cache 232 flushes the cache on all processors
using a thread that has affinity for all processors.
[0053] The Flush_CPU_Cache 232 performs the following operations:
obtaining the current thread, scheduling events, and activating a
flush control mechanism.
[0054] FIG. 3H is a pseudo code implementation of the
AGP_Memory_Manager_Initialize 242 function according to one
embodiment of the invention. The parameters of the
AGP_Memory_Manager_Initialize 242 include a HwDeviceExtension
parameter. The HwDeviceExtension parameter specifies the device
extension used by the device driver. The
AGP_Memory_Manager_Initialize 242 returns TRUE for success. The
AGP_Memory_Manager_Initialize 242 initializes the memory manager
and is called at the time of initialization of the graphics
adapter.
[0055] The AGP_Memory_Manager_Initialize 242 performs the following
operations: limiting the AGP aperture to a predefined size,
programming the MTTRs for AGP aperture as write combining, marking
the entire aperture to be available for allocation, allocating
memory for the GART, zeroing out the GART, programming the GART
address, enabling the GART, initializing data structures of the
memory manager, claiming minimum memory as a default size, and
flushing the processor cache.
[0056] FIG. 3I is a pseudo code implementation of the
AGP_IOctl_Service 244 function according to one embodiment of the
invention. The parameters of the AGP_IOctl_Service 244 include a
HwDeviceExtension parameter and a RequestPacket parameter. The
HwDeviceExtension parameter specifies the device extension used by
the device driver. The RequestPacket parameter specifies the IOCTL
request packet as received by the miniport. The AGP_IOctl_Service
244 returns the status as returned by the video miniport IOCTL
service routine. The AGP_IOctl_Service 244 is called by the video
miniport in response to an AGP memory manager request made by the
device driver upon receiving one of the AGP IOCTL messages. The
miniport driver normally returns the status value received from the
AGP_IOctl_Service 244 in the request packet status block.
[0057] The AGP_IOctl_Service 244 performs the following operations:
validating the IOCTL request packet, and calling appropriate
functions (e.g., GART_Reserve 246, GART_Free 254, GART_Commit 248,
GART_Uncommit 252, GART_Mem_Attribute 256) according to the
IOControlCode.
[0058] FIG. 3J is a pseudo code implementation of the GART_Reserve
246 function according to one embodiment of the invention. The
parameters of the GART_Reserve 246 include a HwDeviceExtension
parameter, a numpages parameter, an alignMask parameter, and a
flags parameter. The HwDeviceExtension parameter specifies the
device extension used by the device driver. The numpages parameter
specifies the number of pages. The alignMask parameter specifies an
alignment mask for the acceptable starting pages for the GART
device address. The alignMask parameter value can be used to
specify the address in multiples of 4K, 8K, 16K, 32K, 64K, or 128K.
The flags parameter specifies whether the pages are to be mapped as
uncache memory or write combining memory. The GART_Reserve 246
returns NULL if the operation failed or a valid linear address if
the operation succeeded. The GART_Reserve 246 does not allocate
system memory. Therefore, the device and linear addresses cannot be
used until the system memory is committed using the GART_Commit
248.
[0059] The GART_Reserve 246 performs the following operations:
searching the free block list for free addresses, mapping the free
block as write combining or uncached depending on the flags
parameter, inserting a new AGP memory item and adjusting the free
block entry of the mapping is successful, and returning the linear
address.
[0060] FIG. 3K is a pseudo code implementation of the GART_Commit
248 function according to one embodiment of the invention. The
parameters of the GART_Commit 248 include a HwDeviceExtension
parameter, a GARTLin parameter, a pageoffset parameter, a numPages
parameter, and a flags parameter. The HwDeviceExtension parameter
specifies the device extension used by the device driver. The
GARTLin specifies the result of a GART_Reserve 246 call. The
pageoffset parameter specifies the offset in pages from the start
of the reserved region. The numPages parameter specifies the number
of pages. The flags parameter specifies whether the system memory
committed to the device address is zero-initialized. The
GART_Commit 248 returns a Boolean value indicating whether the
service was successful. The offset added to the number of pages is
less than or equal to the number of pages specified when the memory
was reserved. It is acceptable to commit the already committed
memory.
[0061] The GART_Reserve 246 performs the following operations:
validating the parameters, determining if there are enough pages,
backing up address with pages, updating the number of allocated
pages, flushing the processor cache, and flushing and enabling
GART.
[0062] FIG. 3L is a pseudo code implementation of the GART_Uncommit
252 function according to one embodiment of the invention. The
parameters of the GART_Uncommit 252 include a HwDeviceExtension
parameter, a GARTLin parameter, a pageoffset parameter, and a
numPages parameter. The HwDeviceExtension parameter specifies the
device extension used by the device driver. The GARTLin specifies
the result of a GART_Reserve 246 call. The pageoffset parameter
specifies the offset in pages from the start of the reserved
region. The numPages parameter specifies the number of pages. The
GART_Uncommit 252 does not return a value. The offset added to the
number of pages is less than or equal to the number of pages
specified when the memory was reserved. It is acceptable to
uncommit memory that was never committed.
[0063] The GART_Uncommit 252 performs the following operations:
searching for allocated AGP addresses, validating parameters,
limiting the number of uncommitted pages to the number of reserved
pages, uncommitting pages from addresses, flushing the processor
cache, and flushing and enabling GART.
[0064] FIG. 3M is a pseudo code implementation of the GART_Free 254
function according to one embodiment of the invention. The
parameters of the GART_Free 254 include a HwDeviceExtension
parameter and a GARTLin parameter. The HwDeviceExtension parameter
specifies the device extension used by the device driver. The
GARTLin specifies the result of a GART_Reserve 246 call. The
GART_Free 254 does not return a value. The GART_Free 254 also frees
any system memory that was committed in addition to freeing the
committed device memory.
[0065] The GART_Free 254 performs the following operations:
validating parameters, obtaining the AGP physical address,
uncommitting all committed memories, unmapping the address space,
restoring memory back to the free pool, collapsing the freed items
with existing free block items if feasible, and removing the AGP
entry.
[0066] FIG. 3N is a pseudo code implementation of the
GART_Mem_Attribute 256 function according to one embodiment of the
invention. The parameters of the GART_Mem_Attribute 256 include a
HwDeviceExtension parameter, a GARTLin parameter, and a pFlags
parameter. The HwDeviceExtension parameter specifies the device
extension used by the device driver. The GARTLin specifies the
result of a GART_Reserve 246 call. The pFlags parameter points to
where the function stores the allocation flags. The pFlags
parameter may be NULL. The GART_Mem_Attribute 256 returns the
device address associated with the specified linear address. The
GART_Mem_Attribute 256 is not used if the device memory is write
combining.
[0067] The GART_Mem_Attribute 256 performs the following
operations: validating parameters and obtaining the device
address.
[0068] Therefore, the present invention is a technique to manage
memory efficiently for the device driver. The non-contiguous system
memory is remapped to contiguous device memory. The translation
table in the chipset provides the mapping.
[0069] While this invention has been described with reference to
illustrative embodiments, this description is not intended to be
construed in a limiting sense. Various modifications of the
illustrative embodiments, as well as other embodiments of the
invention, which are apparent to persons skilled in the art to
which the invention pertains are deemed to lie within the spirit
and scope of the invention.
* * * * *