fig2 illustrates an event reporting mechanism in a programmable graphics processing pipeline 200 , according to an embodiment of the present invention . the programmable graphics processing pipeline 200 shown in fig2 has been simplified for purposes of illustrating the event reporting mechanism according to an embodiment of the present invention . the programmable graphics pipeline 200 , as shown , includes execution pipelines 202 , 204 and a crossbar 206 . the execution pipeline 202 has multiple stages and includes a first stage 208 , a second stage 210 , a third stage 212 that includes an event detector 214 and a local counter 216 , a fourth stage 218 and a fifth stage 220 . the execution pipeline 204 has multiple stages and includes a first stage 222 , a second stage 224 , a third stage 226 that includes an event detectors 228 and a local counter 230 , a fourth stage 232 and a fifth stage 234 . the crossbar 206 includes an accumulation counter 236 . the local counters 216 , 230 are configured as m - bit counters ( e . g ., 32 - bit counter ) and the accumulation counter 236 is configured as an n - bit high precision counter ( e . g ., 64 - bit counter ). as an instruction is executed in the execution pipelines 202 , 204 , a reportable event may occur in one or both of them . when the reportable event does occur , the event is detected by an event detector ( e . g ., the event detector 214 or 228 ) and the local counter associated with that event detector is incremented . for example , when a reportable event occurs in stage 212 of the execution pipeline 202 , the event detector 214 detects the event and increments the local counter 216 . similarly , when a reportable event occurs in stage 226 of the execution pipeline 204 , the event detector 228 detects the event and increments the local counter 230 . in the embodiments of the present invention illustrated in fig2 , two execution pipelines of a programmable graphics processing pipeline are shown and five pipeline stages are shown for each of the execution pipelines . the present invention is , however , generally applicable to a programmable graphics processing pipeline with any number of execution pipelines , even one , and any number of pipeline stages per execution pipeline . also , the present invention may be practiced with any processing unit that has one or more execution pipelines configured for graphics processing . one example of a reported event is the “ z pass pixel count .” as previously described , the z pass pixel count represents the number of z pixels that pass the z test , which may occur for pixels that are eventually rendered and thus reach the crossbar after the end of the pipeline , as well as pixels that are not rendered because they are obstructed by other pixels , causing the obstructed pixels to be discarded in the z - cull unit . placing an event detector and an event counter in a pipeline stage that performs the z test and prior to the z - cull unit allows all pixels that pass the z - pass test , including the culled pixels , to be counted prior to being discarded in the z - cull unit . another example of a reported event is pixel shader invocations . since graphics processing units ( gpus ) typically include a plurality of pixel shaders , reporting a count of all pixel shader invocations across the gpu involves detecting and reporting events from each pixel shader in the gpu . placing an event detector and an event counter in each pixel shader allows the invocations of the pixels shaders to be counted . transmitting the invocation count for each pixel shader through its respective execution pipeline to the crossbar allows the total count to be summed at an accumulation counter and reported . at any time during graphics processing , the api may request reporting of an event count for an event type . the process of reporting the event count involves the steps of triggering each local counter that corresponds to the requested event type to communicate its count value to the crossbar 206 , receiving the count values at the crossbar 206 , and processing them to generate a reportable result . the crossbar 206 generates the reportable result using the accumulation counter 236 , which adds the count values received at the crossbar 206 to a free - running count value for the event type stored in the accumulation counter 236 . the local counters for the requested event type are triggered to communicate their count values to the accumulation counter 236 by a report token that is passed through the execution pipeline . when a report token reaches a pipeline stage that includes a local counter corresponding to the report token , the pipeline stage reads the value of the count from the local counter , encodes this value into a count token for injection into the execution pipeline , and resets the local counter . just before the count token is injected into the execution pipeline , a pipeline bubble is created tin the execution pipeline ahead of the report token and the count token is injected into the pipeline bubble . once injected into the execution pipeline , the count token propagates to the crossbar 206 through the execution pipeline . for example , when the pipeline stage 212 receives a report token that corresponds to the event type for the local counter 216 , the pipeline stage 212 encodes the value of the local counter 216 into a count token , creates a pipeline bubble ahead of the report token in the pipeline stage 212 , inserts the count token into the pipeline bubble , resets the local counter 216 , and allows the count token to propagate from pipeline stage 212 through pipeline stages 218 and 220 and finally to the crossbar 206 . when the count token arrives at the crossbar 206 , the count token is decoded to extract the encoded count value , and the decoded count value is added to the free - running accumulated count in the accumulation counter 236 . similarly , when the pipeline stage 226 receives a report token that corresponds to the event type for the local counter 236 , the pipeline stage 226 encodes the value of the local counter 236 into a count token , creates a pipeline bubble ahead of the report token in the pipeline stage 226 , inserts the count token into the pipeline bubble , resets the local counter 236 , and allows the count token to propagate from pipeline stage 226 through pipeline stages 232 and 234 and finally to the crossbar 206 . when the count token arrives at the crossbar 206 , the count token is decoded to extract the encoded count value , and the decoded count value is added to the free - running accumulated count in the accumulation counter 236 . the methods for creating a pipeline bubble and injecting a count token into the pipeline bubble are well known to those skilled in the art , and thus , for simplicity , a detailed description of such methods is not provided herein . in the above examples , each count token is inserted in a pipeline bubble ahead of its corresponding report token . in this manner , it is ensured that all count tokens will arrive at the crossbar 206 prior to their corresponding report token , even if there is more than one event detector within the same execution pipeline . once all report tokens have been received for a requested report , the crossbar 206 stores the value of the accumulation counter 236 in a memory location specified by the api in the report token . the local counters are configured to be lower precision ( e . g ., 32 - bit ) than the accumulation counter ( e . g ., 64 - bit ). this saves on hardware cost , but is also presents a possibility that the local counter may overflow before a report is requested from that local counter . overflow of the local counters is avoided by injecting a count token in the execution pipeline when a counter saturates ( i . e . reaches it maximum value ), without the presence of a report token to trigger the injecting of the count token . when a local counter within a pipeline stage saturates , the pipeline stage creates a pipeline bubble , injects a count token into the pipeline bubble , and resets the local counter , as previously described . the count token than propagates through the execution pipeline and reaches the accumulation counter in the crossbar 206 . with this configuration , the designer can balance the cost of implementing local counters of various precisions against the small performances penalties associated with injecting count tokens into the pipeline when the local counters saturate . the report token described above has three components that enable the event reporting mechanism to perform as described . a first component is a plurality of bits that indicates the function of the token ( e . g ., a report token ) as distinguished from other tokens that propagate through the pipeline , such as execution tokens . a second component is a plurality of bits that indicate the event type whose report is requested . a third component is a destination address to which the accumulated count is written . this destination address is specified by the api when it requests a report . when the report token reaches a pipeline stage with an event counter ( e . g ., pipeline stage 212 or 226 ), the pipeline stage determines whether the event type encoded in the report token corresponds to the type of event counted by the event counter . if the encoded event type matches the counter event type , the pipeline stage creates a pipeline bubble , injects a count token into the pipeline bubble , and resets the local counter , as previously described . the event reporting mechanism according to embodiments of the present invention also supports reporting a plurality of event types . for example , the event detector 214 may be configured to report an event of a first type and the event detector 228 may be configured to report an event of a second type . when a report token that corresponds to the first type is transmitted down the execution pipelines 202 , 204 , the count value of the local counter 216 will be encoded , injected into the execution pipeline 202 , and reset , but the count value of the local counter 230 will be unaffected by such a report token . by contrast , when a report token that corresponds to the second type is transmitted down the execution pipelines 202 , 204 , the count value of the local counter 230 will be encoded , injected into the execution pipeline 204 , and reset , but the count value of the local counter 216 will be unaffected by such a report token . fig3 illustrates a computing device 300 in which embodiments of the present invention can be practiced . the computing device 300 includes a graphics subsystem 302 , a central processing unit ( cpu ) 304 , a system controller 306 ( also known as a northbridge ™), a main memory 310 , and an i / o controller 308 ( also known as a southbridge ™). the graphics subsystem 302 includes a gpu 312 and a gpu memory 314 . the gpu memory 314 includes a frame buffer 322 , which stores graphics data generated by the gpu 312 . the gpu 312 includes a gpu front end 316 , which fetches instructions , an instructions dispatch unit ( idx ) 318 , which schedules instructions from the front end 316 for execution , the programmable graphics pipeline 200 , which executes instructions scheduled by the idx 318 , and a raster operations unit , which receives the results of the instructions executed in the programmable graphics processing pipeline 200 and updates the graphics data in the frame buffer 322 accordingly . fig4 illustrates a flowchart of a method 400 for counting events in a pipeline stage ( e . g ., pipeline stage 212 or 226 ) and transmitting count values from a pipeline stage to a crossbar . as shown , the method 400 begins at step 402 where the pipeline stage loops through steps 402 and 404 until a report token is received from the execution pipeline or an event is detected within the pipeline stage . in step 402 , the pipeline stage determines whether the current token is a report token . if the current token is not a report token , the method continues to step 404 where the pipeline stage determines whether the event detector detected an event . if the event detector does not detect an event , the method loops back to step 402 , where a next token is evaluated . returning to step 404 , if the event detector determines that an event is detected , the local counter associated with that event detector is incremented ( step 406 ). in step 408 , the pipeline stage determines whether the local counter has saturated . if the local counter has not saturated , it is able to count additional events , so the method loops back to step 402 , where a new token is evaluated . on the other hand , if the pipeline stage determines that the local counter has saturated , the local counter is unable to count additional events , so its value is transmitted to the corresponding accumulation counter in steps 410 , 412 and 414 by injecting a count token into the execution pipeline . in step 410 , the pipeline stage creates a count token that includes an encoded form of the saturated count value . in step 412 , the pipeline stage inserts a pipeline bubble into the execution pipeline as previously described . in step 414 , the count token created in step 410 is inserted into the pipeline bubble created in step 412 , allowing the count token to propagate to the crossbar 206 . after inserting the count token into the pipeline bubble , the pipeline stage resets the local counter in step 416 and loops back to step 402 , where a next token is evaluated . returning to step 402 , if the current token is a report token , steps 410 , 412 , 414 and 416 are carried out as previously described . when carrying out step 412 , the pipeline stage ensures that the pipeline bubble is inserted ahead of the report token . fig5 illustrates a flowchart of a method 500 for processing report tokens and count tokens with the accumulation counter 236 . as shown , the method 500 begins at step 502 , where the crossbar 206 initializes the accumulation counter 236 in preparation for receiving count tokens in subsequent steps . next , the method continues by looping through steps 504 , 506 and 510 until a count token or a report token is received from an execution pipeline . in step 504 , a current token is received from the execution pipeline . in step 506 , the crossbar 206 determines whether the current token is a count token . if it is , the accumulation counter 236 is increases its count value by the count value of the count token ( step 508 ), and the method loops back to step 504 , where a next token is received for evaluation . if the current token is not a count token , the crossbar 206 determines whether the current token is a report token ( step 510 ). if the current token is not a report token , the method loops back to step 540 , where a next token is received for evaluation . if the crossbar 206 determines that the current token is a report token , the crossbar 206 determines whether all report tokens for the current report have been received ( step 512 ). if all report tokens for the current report have been received , it is determined that the accumulation of local counter values in the accumulated counter 236 is now complete , and the crossbar 206 decodes from the report token the memory address where the accumulated counter value is to be stored . in step 516 , the accumulated counter value is stored at the decoded memory address , and the method loops back to step 504 , where another token is received for evaluation . returning back to step 512 , if all report tokens for the current report have not been received , the method loops back to step 504 , where another token is received for evaluation . while the foregoing is directed to embodiments of the present invention , other and further embodiments of the invention may be devised without departing from the basic scope thereof . the scope of the present invention is determined by the claims that follow .