fig1 illustrates a high - level functional block diagram of a computer system having a unified memory architecture ( uma ) according to the present invention . shown are central processing unit ( cpu ) 100 coupled to integrated controller 102 . integrated controller 102 , in turn , is coupled to synchronous dynamic random access memory ( sdram ) 104 . cpu 100 is preferably an x86 compatible cpu . however , the present invention will work equally well with any standard cpu capable of issuing memory access requests as described below . integrated controller 102 contains system logic 106 , graphics / video controller ( hereafter referred to as &# 34 ; graphics controller &# 34 ;) 108 , arbitration logic 110 , and memory controller 112 . system logic 106 contains the logic necessary to control the basic operation of the computer system , such as bus logic . graphics controller 108 controls the generation of graphics data on a display screen ( not shown ). graphics controller 108 may receive video data from a real - time video source separate from the computer system or display graphics data received from cpu 100 . arbitration logic 110 receives memory requests from the cpu 100 , system logic 106 , and graphics controller 108 . then , arbitration logic 110 arbitrates among and grants the highest priority request . once a device &# 39 ; s access request is granted , that device is connected directly to memory controller 112 and uses it 112 to access memory . it is important to note that arbitration logic 110 arbitrates among all devices in the computer system capable of issuing memory access requests . as discussed above , these devices include the cpu 100 and graphics controller 108 . in addition , devices such as peripheral cards , dma controllers , separate video controllers , and multimedia adapters can send memory access requests to arbitration logic 110 via system logic 106 . sdram 104 includes digital interface 114 and has two banks of dram : bank a 116 and bank b 118 . to access dram banks 116 and 118 , commands are sent to digital interface 114 . digital interface 114 translates the commands into regular dram bus cycles and then accesses dram banks 116 , 118 . fig2 shows a functional block diagram of the operative components of graphics controller 108 . shown are three fifos , or buffers : crt fifo 210 , vid fifo1 211 , and vid fifo2 212 . in addition , graphics controller 108 contains bitblt engine 215 . crt fifo 210 holds graphics data being read out of memory for display on the display screen . cft fifo 210 must have a high priority because the screen will be corrupted if it 210 runs empty . vid fifo1 211 reads data from memory . vid fifo2 212 can read data from or write data to memory . thus , vid fifo2 212 is used for video capture . when video data is coming in from an external source like a tuner or rca jack from a vcr or similar device , the data will come into vid fifo2 212 and be written to display memory . note that the fifos 210 - 212 usually read or write large blocks of contiguous data due to the nature of graphics / video processing . bitblt engine 215 is a logical construct used to accelerate the block transfer of data on the computer screen . fig3 is a chart showing the relative priority of memory requests from crt fifo 210 , vid fifo1 211 , vid fifo2 212 , cpu 100 , and bitblt engine 215 . the memory requests are grouped , in descending order of priority , as class a 310 , class b 312 , class c 314 , and class d 316 requests . class a 310 requests are the highest priority requests and include the crt fifo 210 , vid fifo1 211 , and vid fifo 212 low water mark ( lwm ) requests . a lwm request , or signal , is a critical request and indicates that the fifo 210 - 212 is about to run out of data . note that vid fifo2 212 can either read or write data . therefore , vid fifo2 212 &# 39 ; s lwm can indicate that either the fifo 212 is starting to get empty or the fifo 212 is starting to get full . class b 312 requests include the cpu 100 requests . in addition , any bus mastering peripheral would have a class b 312 request when interfacing with memory 104 . bitblt engine 215 is the only class c 314 request . class d 316 requests are the lowest priority requests and include the crt fifo 210 , vid fifo1 211 , and vid fifo 212 high water mark ( hwm ) requests . a hwm request indicates that the fifo 210 - 212 can accept more data . once again , note that vid fifo2 212 can either read or write data . therefore , vid fifo2 212 &# 39 ; s hwm can indicate that either the fifo 212 can accept more data or can write more data . the above - described request signals are arbitrated by arbitration circuitry 110 . the function of arbitration circuitry 110 can be explained by considering its behavior with respect to crt fifo 210 . note that crt fifo 210 is selected only as an example . when crt fifo 210 is totally full of data from memory 104 , both its hwm and lwm requests are inactive . as data passes out of the fifo 210 and to the display , the hwm request will eventually go active . as stated above , the hwm request indicates that some data has been taken out of the fifo 210 and the fifo 210 can accept more data . however , it is not critical that crt fifo 210 get data right away . since only crt fifo 210 &# 39 ; s hwm request is active , the class a 310 , b 312 , and c 314 devices would get memory access ahead of crt fifo 210 if they were to go active . as crt fifo 210 continues to empty , it eventually gets to the point where it trips the lwm request . once crt fifo 210 &# 39 ; s lwm request goes active , it becomes the highest priority request and will be granted immediately . when the request is granted , the crt fifo 210 begins to read data from memory . eventually , the crt fifo 210 becomes filled to the point where its lwm request goes inactive . at this point , it is desirable to allow the crt fifo 210 to fill to its hwm because memory 104 is optimized to quickly provide large amounts of consecutive data . therefore , a preferred embodiment of the arbitration circuitry elevates the priority of crt fifo 210 &# 39 ; s hwm request to a level between the class b 312 and class c 314 requests . this elevation occurs at the time that crt fifo 210 &# 39 ; s lwm goes active . the process of elevating the priority of the class d 316 request above a class c 314 request is called &# 34 ; chaining .&# 34 ; in this manner , the crt fifo 210 can continue to fill to its hwm , unless a class a 310 device issues a lwm request or a class b 312 device issues a memory access request . note that the high and low water marks for a fifo can be chosen to reflect the needs of the computer system . in addition , the high and low water marks for each fifo can be set individually . thus , the present invention does not require fixed points for the high and low water marks . fig4 is a timing chart illustrating a class d 316 request being elevated above a class c 314 request . fig4 shows the crtfifo -- lwm a , vidfifol -- lwm b , vidfifo2 -- lwm c , class -- b d , class -- c e , crtfifo -- hwm f , vidfifo1 -- hwm g , vidfifo2 -- hwm h , and granted g signals . each signal , except for granted g corresponds to a request signal shown in fig3 . granted g shows which device has been granted memory access . note that the signals in fig4 and 5 are active when low . in addition , note that cycles 4t4 and 5t4 are repeated in the ` a ` and ` b ` segments of fig4 and 5 , respectively . at time 4t1 , the vidfifo2 -- lwm c , crtfifo -- hwm f , and class -- c e signals are active . at time 4t2 , granted g indicates that vid fifo2 212 has been granted memory access . in addition , vidfifo2 -- lwm c goes inactive at time 4t2 , thereby indicating that the fifo 212 has been filled past its lwm . at times 4t3 to 4t4 , vidfifo2 -- hwm h continues its memory access , despite the active class -- c e request . at time 4t5 , vidfifo2 -- hwm h goes inactive , indicating that it is full past its hwm . then , at time 4t6 , the class -- c e request is granted and then goes inactive . finally , at time 4t7 , the crtfifo -- hwm f request is granted . the arbitration behavior between times 4t2 and 4t5 is called a &# 34 ; chained operation &# 34 ; because the grant to vidfifo2 -- hwm h is &# 34 ; chained &# 34 ; to the grant to vidfifo2 -- lwm c . fig5 is a timing chart illustrating a chained operation being broken by a class -- b d request . fig5 shows the crtfifo -- lwm a , vidfifo1 -- lwm b , vidfifo2 -- lwm c , class -- b d , class -- c e , crtfifo -- hwm f , vidfifo1 -- hwm g , vidfifo2 -- hwm h , and granted g signals . the signals correspond to the signals in fig4 . at time 5t1 , the crtfifo -- lwm a and class -- c e request signals are active along with all fifo -- hwm signals . at time 5t2 , the crtfifo -- lwm a request is granted . as a result , the crtfifo -- lwm a signal goes inactive at time 5t2 because crt fifo 210 filled past its lwm . at time 5t3 , the crtfifo -- hwm f is granted memory access despite the active class -- c e request signal . thus , 5t3 marks the beginning of the chained operation . at time 5t3 , the class -- b d request signal goes active . since a class -- b d request has a higher priority than an elevated , or chained , class -- d 316 request , the class -- b d request is granted at time 5t4 . this grant breaks the chain and returns crtfifo -- hwm f to the class d 316 priority . at time 5t5 the class -- c e request is granted . finally , at 5t6 , the crtfifo -- hwm f request is granted .