fig3 shows a high - level block diagram of a system in accordance with the present invention . the figure shows that the memory array 24 has an number of independently operable partitions 26 a , 26 b , 26 c 26 d , each with a bus 28 a - 28 d and a bus 27 a - 27 d having a width w that is preferably a smaller transfer size than the single prior art bus 15 in fig1 . in one embodiment , there are four independent partitions p 0 - p 3 26 a , 26 b , 26 c 26 d each with a bus one quarter the size of the non - partitioned bus , i . e ., each with a 64 bit bus . each of the memory system clients 12 - 20 is connected as before to the memory controller 30 which presents a non - partitioned view of the memory to the clients . the memory controller 30 includes a number of queues 32 , 34 , 36 , 38 , 40 , 42 , 44 , 46 that connect to the memory array of each partition and control logic ( not shown in fig2 ) that determines the one or more partitions to which a request should be routed and the one or more partitions from which a response ( read data ) to a request should be obtained to maintain the appearance of a non - partitioned memory for the clients . additionally , the control logic in the memory controller arbitrates among the various clients according to a priority assigned to each of the clients . partitioning of the memory is shown in fig4 and involves mapping a linear array of bytes to the partitions in an interleaved fashion . in particular , ranges of byte addresses in the linear array are mapped to the various partitions 26 a - 26 d . preferably , the mapping is such that the lower address bits are mapped to a particular partition so that the memory load is approximately evenly balanced over the partitions . in one embodiment , each partition is mapped to an 8 byte range of memory locations . in a different embodiment , each partition is mapped to a 16 byte range of memory locations but any size mapping can be used without departing from the spirit and scope of the invention . a memory access request can start on any partition and end on any partition as long as it does not wrap around and touch the starting partition . if the transfer size of a request is so large that it would violate this rule , then the request , itself , is broken up to multiple requests each satisfying the rule . if the bus size of a partition is smaller than the range of locations mapped to that partition then multiple accesses are made of the partition until the range of locations in the linear map for that partition is satisfied . for example , if a partition is mapped to a range of locations spanning 16 bytes , but the data bus for the partition is only 8 bytes , then two accesses are made of the partition . in operation there are two cases to consider . in the first case , a client makes a request that maps to exactly one partition in size and alignment . this case involves only one partition and some clients are dedicated to only one partition to simplify accesses for that client . in the second case , a client makes a request that spans two or more partitions . this requires that the request be split up and routed to two or more partitions for servicing of the request . the request can start at any partition . in the subcase of a write request , the write data are split and the write data and write request are routed to the various partitions . once the write is retired in the arrays for the affected partitions , the write is completed . in the subcase of a read request , the read request is routed to the proper partitions and as the read request is completed by each of the affected partitions the read data is collected and returned to the client . the partition data bus width and client data bus width may be different . a client with a wider data bus than that of the partition may consume several clocks of partition transfer time . alternatively , a client with a data bus width that is smaller than that of a partition can request a burst having a size that requires only one clock cycle of the partition to access the data from that partition but requires many clock cycles to multiplex the partition &# 39 ; s data onto the smaller client data bus . the read circuitry for the narrow client is configured to use several clocks to multiplex the data from the partition onto the narrow client bus . this ensures that unused data is not fetched , and isolates the low bandwidth client from the high bandwidth memory system . fig5 a shows a block diagram for the address , command and write data path for the memory system of the present invention . for convenience , four memory partitions 26 a , 26 b , 26 c , 26 d are shown , but any number of partitions is contemplated for the present invention . each partition has an arbiter , 56 a , 56 b , 56 c , 56 d , having an output that supplies requests to the partitions and a number of inputs , each of which connects to a client queue 62 - 66 , 70 - 74 , 78 - 82 , 86 - 90 . each arbiter 56 a - 56 d prioritizes the servicing of requests at its inputs according to a priority policy and each client queue 62 - 66 , 70 - 74 , 78 - 82 , 86 - 90 that is connected to an arbiter input receives a memory partition request derived from the one or more memory clients 100 , 102 , 104 , such as the various graphics engines mentioned above . while the figure shows three clients , any number of memory clients is possible as long as the necessary hardware is provided for each client . priority policies for the arbiters 56 a - 56 d include a least - recently used policy , a fixed priority policy or a round - robin policy or a static or dynamic set of policies depending on the type and nature of the client requests in the client queues . requests for time critical processes such as display updates or other isochronous processes are given higher priority over requests that have less strict timing requirements . any number of clients can request memory operations of the partitions ; three clients are shown for convenience . for each client , there is a router 110 , 112 , 114 that determines , based on an address and reference size contained in the client &# 39 ; s request , the one or more partitions 26 a - 26 d , that are needed to service the request . if , in the example shown , each partition 26 a - 26 d , has an effective address map width of w * 8 bits ( w bytes ) then the router 110 - 114 decodes a portion of the address in the request to determine which of the w - byte partitions should service the request . in addition to the decoding function of the router , the router , in some versions of the invention , also performs address mapping or address translation functions if they are required for a particular application . the router can also perform the function of breaking up a request that is so large is violates the no - wrap around rule . the router then issues requests to the client queues each of which meets the no - wrap rule . memory clients 100 - 104 can place a partition request into one of the client queues 62 - 66 , 70 - 74 , 78 - 82 , 86 - 90 independently of any other client placing a partition request into a different queue . this prevents memory clients from blocking or interfering with each other at least insofar as memory operations are involved . this means that no partition waits on another partition before servicing a memory request . this arrangement improves memory system throughput for memory reads and writes that require fewer than an integer number of all of the partitions . for example , if there are four partitions , then requests requiring 1 , 2 , or 3 or 5 , 6 , or 7 partitions receive improved service . requests that require an integer number of all four partitions incur no loss in performance in the partitioned memory system . fig5 b shows one implementation of logic present in the router of fig5 a . the router passes through the request and its address and transfer size information and derives the starting partition information by means of a starting partition logic block 116 . the starting partition and size are used by the router to determine which partition client queue to load with a request . fig5 c shows another implementation of logic present in the router of fig5 a . in this case , the router passes through the request and its address and transfer size information and derives not only the starting partition information but also a sequence count by means of sequence counter 118 . sequence counter 118 is incremented for each new request as long as there is a not busy condition according to gate 119 . the starting partition and size are used by the router to determine which partition client queue to load with a request . fig6 a shows a block diagram for the read data path in accordance with one version of the present invention . in this case , the partition data bus width is the same as the client &# 39 ; s data bus width . read requests that touch only a single partition and burst read requests that span a number of partitions must be serviced by those partitions and the read data must be presented in the order requested by the client back to the client . to handle this case and to prevent deadlocks , the hardware of fig6 a is required for each client . for a particular client , each partition in fig6 a has a read queue 120 a - 120 d that captures the read data from the partition array 26 a - 26 d . this read queue 120 a - 120 d is controlled by a queue controller 122 , 124 , 126 , 128 that is connected to the read queue 120 a - 120 d , the partition 26 a - 26 d , and to a control block 130 . each of the read queue controllers 122 - 128 receives a data_valid signal from the partition 26 a - 26 d and provides a queue control signal , q_empty , to the control block 130 . each of the read queues 120 a - 120 d connects to the input of a multiplexer 132 whose output provides the read data to the client to which this circuitry is dedicated . another queue , called a side queue 134 , receives information regarding the starting partition for the read request , sub request id , and the burst size , if any , for the read request . sub - requestors 153 , 155 , 157 , in fig7 require sub request ids because such sub clients share a single request path . in fig6 a , control block 130 is connected to the multiplexer 132 to selectively couple one of the inputs to the output of the multiplexer as the data becomes available at the output of the read queue 120 a - 120 d , respectively connected to each multiplexer input . the control block also provides signals to the queue controllers for use in controlling the queues and provides the data valid signals , data_valid_req 0 a , data_valid_req 0 b , data_valid_req 0 c , for each of the clients . the hardware according to the block diagram of fig6 a , operates to collect the various parts of read data that are supplied by the partitions 26 a - 26 d in response to a read request . the partition loads the read data into read queues corresponding to the client that issued the read by using the data_valid signal as a load signal for the client read queue . for example , if the read request starts at partition 1 , 26 b as determined by the data in the side queue 134 that is received by the control block 130 , then when the queue controller 122 - 128 for a partition 26 a - 26 d discovers that data is ready in the read queue for that partition by means of the q_empty signal becoming false , the control block 130 sets the multiplexer 132 to output the read queue for partition 1 , 26 b to the particular client . next , the queue controller for partition 2 , 26 c is checked to see if the data is ready from partition 2 . if so , then the multiplexer 132 is set to output the read queue for partition 2 to the client . this sequence continues until the full amount of data requested by the client is sent to the client . if the data bus size of a partition is smaller than the range of locations mapped to that partition then multiple read data of the partition may be returned until the range of locations in the linear map for that partition is satisfied . in some cases a memory client can accept data in an out - of - order fashion . this means that instead of accepting data , lowest byte first for example , the client can accept data in a number of other pre - specified orders . in these cases , the queue controllers 122 - 128 operate to cause the queues 120 a - d to output data in a non - first - in - first - out order in order to provide read data in the particular order in which the clients is accepting the data . this increases throughput of the memory system because a client that can receive data out - of - order can accept data as soon as it is available from a partition . the embodiment of fig6 h does not use a side queue , but instead provides each client with a sequence number counter or equivalent mechanism , which increments for each reference that is issued by the client . the sequence count is conveyed to all servicing partitions along with start partition , transfer size and sub request id if there are multiple clients sharing the same router as shown in fig7 . the sequence count is passed through the partition and loaded into the read queues 120 a - d with the read data when that partition &# 39 ; s read return data returns from memory . the outputs of read queues 120 a - d transfer this information to controller 130 . controller 130 examines the partition read queue outputs and selects read data tagged with the next sequence number only after exhausting read data tagged with the current sequence count . fig6 b shows a block diagram for the read data path in accordance with one version of the present invention with partition - size interface hardware , which is needed when the data bus width of a client is different than that of the partition . the data bus width of a partition may be smaller than that of a client , such that the partition must be cycled more than once to obtain enough data to match the bus width of the client . in this case the control logic operates to cause a burst of data ( several data words ) to be produced from the partition . interface hardware blocks 140 , 142 , 144 , 146 for holding the burst data are additionally included in the multiplexer circuitry 133 . the multiplexer circuitry selects one of the interface blocks to provide some or all of the burst data . fig6 c shows an implementation of the interface hardware included in the multiplexer circuitry of fig6 b . this circuitry adapts a w wide partition to a client bus having a width of 2w . a register 150 and multiplexer 152 capture and hold a portion of the burst data and the remaining portion of the burst data is provided by the associated read queue . in other embodiments , both w - wide paths are provided by registers . fig6 d shows another implementation of the interface hardware included in the multiplexer circuitry of fig6 b . in this implementation , the partition bus is w bytes wide and the client bus is ½ w wide . a multiplexer 152 adapts the wider bus to the smaller bus . fig6 e shows another block diagram for the read data path in accordance with another version of the present invention with partition - size interface hardware . in this case , the client bus width is larger than the partition address map size . in this example , there are two interfacing blocks included within the multiplexer circuitry 133 . the first interface block 141 is connected to receive data from read queues 120 a and 120 b and the second interface block 143 is connected to receive data from read queues 120 c and 120 d . fig6 f shows an implementation of the interface hardware included in block 143 p of the multiplexer circuitry of fig6 e . the interface hardware simply passes through the two w - byte sized busses to provide a bus that is 2w , because the outputs of a pair of read queues are available to the multiplexer circuitry . fig6 g shows another implementation of the interface hardware included in the multiplexer circuitry of fig6 e . the interface block shown adapts a partition bus having a width w and address map width 2w to a client bus that has a width 4w . a pair of registers , 154 a , 154 b , and a pair of multiplexers , 156 a , 156 b , are used to capture multiple data items from the pair of read queues to which each of the interface block , 141 , 143 is connected . fig7 shows an alternative embodiment of the command and write data path . in this embodiment , an arbiter 151 is added to prioritize a number of sub - requestors 153 , 155 , 157 that share a command and write data path in order to reduce the hardware that would otherwise be needed for each requester . each sub - requestor has a sub - request id . the data_valid signals of fig6 a and 6b and the sub - request id indicate which of sub - requestors 153 , 155 , 157 should collect the read data . fig8 shows another alternative embodiment of the command and write path in which the arbitration for access to a partition is in two parts , arbiter - 0 a 56 a - 56 d , and secondary arbiter - 0 b 160 - 166 , and there is a preferential path for a high priority requester 106 , which , in the figure , is req 3 . low priority requesters arbitrate to gain access to the partitions using first the arbiter - 0 a and then secondary arbiter - 0 b circuitry but the high priority request via client queues 60 , 68 , 76 , 84 arbitrates to gain access using only the arbiter - 0 b circuitry 160 - 166 . it is also advantageous to introduce a refresh requestor 170 as shown and memory device initialization requests into the arbiter - 0 b 160 - 166 blocks . the above describes the cases in which a ( i ) processing request is sent to a client , ( ii ) the client performs the requested processing and makes memory requests and ( iii ) the memory system routes the memory requests to the proper client queues . however , if a memory client is itself partitioned into an number of processing stages , an alternative is ( i ) to determine the one or more processing stages required for a processing request , ( ii ) route the processing requests to the proper stage for processing and then ( iii ) send the request directly to the appropriate client queue which is connected to a specific partition . a single memory client that is not partitioned into stages may also be restricted to only access data in a single partition and connect directly only to that partition . fig9 shows this alternative embodiment of the command and write path in which there is no router for client 3 106 because the client directs its requests via client queue 84 only to a particular partition , partition 3 , 26 d . for these partitioned clients , such as a raster - operation pipeline , this simplifies and speeds up the access to the memory subsystem . in addition , the read path is simplified because the read data is directly returned to the requester from the dedicated partition . the multiplexer and control circuitry of fig5 is not required for a requester that is dedicated to a particular partition . one or more of the above - described embodiments can be combined according to the embodiments that are needed for the types and number of memory clients and all such combinations are within the spirit and scope of the present invention . fig1 shows a plot illustrating the improved fetching efficiency of the present invention . for the same small triangle size , between approximately 10 and 100 pixels there is a marked improvement in the efficiency . although the present invention has been described in considerable detail with reference to certain preferred versions thereof , other versions are possible . therefore , the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein .