Video presenting network configuration solution space traversal   

This application claims the benefit of Milirud et al., U.S. Provisional Application No. 60/567,053, entitled “VIDEO PRESENTING NETWORK MANAGEMENT,” filed Apr. 30, 2004, which is hereby incorporated herein by reference.

TECHNICAL FIELD

The technical field relates to configuration of video display adapters (e.g., computer video cards).

Computer systems using multiple monitors are becoming widespread. For example, it is now common for a computer to drive both an LCD panel and a projector device. Further, computer users now routinely watch video presentations (e.g., DVDs) using their computer. In such a case, the computer may be driving both a conventional monitor and a television.

In response to demand, video adapter hardware manufacturers now include multiple outputs on video adapters. In this way, a user can more easily use a computer to drive desired devices without having to switch cables for a single output and re-configure the output.

Although such multi-monitor video adapters have a variety of functionality, available configurations are typically limited. Accordingly, there exists a need to improve functionality related to configuring multi-monitor computer systems.

SUMMARY

Configuring a video presenting network having plural outputs can be challenging, due to the sheer number of possible configurations and configuration interdependencies among resources.

A variety of technologies described herein can be used to configure resources of a video presenting network having plural outputs. For example, provisional configuration can be supported. Configuration of inputs can be performed separately from configuration of outputs. Traversal through possible configuration solutions can include backtracking. For example, backtracking can be used when a selected configuration option invalidates another desired configuration option.

Interdependencies between network resources can be considered to restrict provided options to those co-functional with a provisional configuration. Responsibility for considering interdependencies can be delegated to (e.g., performed by) a video driver, such as a video miniport. A client can use a variety of approaches to find a desired configuration. The desired configuration can be treated as a solution to an NP-Complete graph problem.

The foregoing and other features and advantages will become more apparent from the following detailed description of disclosed embodiments, which proceeds with reference to the accompanying drawings.

FIG. 1 is a block diagram showing an exemplary configurable video presenting network.

FIG. 2 is a block diagram showing another exemplary configurable video presenting network.

FIG. 3 is a block diagram showing combinations of configurations for a video presenting network.

FIG. 4 is a flowchart showing a method of configuring a configurable video presenting network, such as that shown in FIG. 1.

FIG. 5 is a table showing exemplary provisional configuration of a video presenting network, such as that shown in FIG. 1.

FIG. 6 is a block diagram showing an exemplary transactional approach to achieving configuration of a video presenting network, such as that shown in FIG. 1.

FIG. 7 is a flowchart showing an exemplary method for performing configuration via a transactional approach.

FIG. 8A is a block diagram showing exemplary source for feedback during a provisional configuration of a video presenting network, such as that shown in FIG. 1.

FIG. 8B is a block diagram showing exemplary source for feedback similar to FIG. 8A, but for plural resources.

FIGS. 9A, 9B, and 9C are block diagrams showing exemplary co-functional options for a plurality of resources during pinning.

FIGS. 10A, 10B, and 10C are block diagrams showing other exemplary co-functional options for a plurality of resources during pinning.

FIG. 11 is a block diagram showing an exemplary transactional approach with feedback to achieve configuration of a video presenting network, such as that shown in FIG. 1.

FIG. 12 is a flowchart showing an exemplary method for performing configuration via a transactional approach with feedback from a server perspective.

FIG. 13 is a flowchart showing an exemplary method for performing configuration via a transactional approach with feedback from a client perspective.

FIG. 14 is a block diagram showing an exemplary architecture in which provisional configuration can be implemented.

FIG. 15 is a flowchart showing an exemplary method of configuring a video presenting network.

FIG. 16 is a flowchart showing an exemplary method of finding a desired configuration by systematic traversal of the solution space to converge on a desired configuration.

FIGS. 17A-B are a flowchart showing a first exemplary detailed method of finding a desired configuration by systematic traversal of the solution space to converge on a desired configuration.

FIGS. 18A-C are a flowchart showing a second exemplary detailed method of finding a desired configuration by systematic traversal of the solution space to converge on a desired configuration.

FIG. 19 is a flowchart showing an exemplary method of determining a topology for a video presenting network.

FIG. 20 is a block diagram showing calls between a client and server to arrive at a configuration for a video presenting network.

FIG. 21 is a block diagram showing integration of an implementation of the technology into a computer system having a plurality of video display devices.

FIG. 22 is a block diagram showing a client-server system that takes priorities into account in determining a desired video configuration.

FIG. 23 is a flowchart showing an exemplary method of determining a desired video configuration in a client-server system such as that in FIG. 22.

FIG. 24 is a flowchart showing an exemplary method of finding a desired configuration by systematic traversal of the solution space where the topology can be changed during execution of the method.

FIG. 25 is a block diagram showing an exemplary multi-monitor/multi-view system.

FIG. 26 is a diagram depicting a general-purpose computing device constituting an exemplary system for implementing the disclosed technology.

DETAILED DESCRIPTION

FIG. 1 shows a configurable video presenting network 100. The technologies described in any of the examples herein can be used to configure the video presenting network 100.

The video presenting network 100 for use with the technologies described herein can have one or more inputs 110A-110N (e.g., a total of Σ inputs, σ); two or more outputs 120A-120N (e.g., a total of T inputs, τ); and one or more digital-video-input-representation-to-video-output-signal converters 130A-130N (e.g., a total of K converters, κ).

The inputs 110A-110N are sometimes called “sources” or “surfaces.” The outputs 120A-120N are sometimes called “targets.” The digital-video-input-representation-to-video-output-signal converters are sometimes called “converters.”

In addition to the inputs, converters, and outputs, the video presenting network can include other resources 140 (e.g., video memory, bandwidth, memory capacity, and the like). The other resources 140 can be used by the inputs, converters, and outputs to achieve video presenting functionality.

The video presenting network 100 can be implemented in hardware such as a video display adapter (e.g., video card). In some cases, some resources may reside outside the adapter.

An exemplary computer system may include one or more video views in digital form (e.g., which are written to by applications of the computer system), which are used by the inputs 110A-110N. The resulting signal coming from the plural outputs 120A-120N can be used to drive plural video display devices.

FIG. 2 shows another configurable video presenting network 200. The technologies described in any of the examples herein can be used to configure the video presenting network 200.

In the example, multiple inputs can be used for a single digital-video-input-representation-to-video-output-signal converter (e.g., the inputs 210B and 210N are used as inputs to the converter 230N). Such a configuration can be useful in overlaying one video signal on top of another by using a video output codec with two inputs, wherein the first input is the primary content and the second input is the overlaid content. In such a situation, the position and size of the overlay can be specified as part of the video present source mode for the video presenting network source representing the overlaid content.

Video presenting networks can take many other forms, having an arbitrary number of inputs, converters, and plural outputs.

In any of the examples herein, a resource can include video presenting network inputs (e.g., sources or surfaces), video presenting network outputs (e.g., targets), converters, video memory, bandwidth, memory capacity, and the like.

The topology of a video presenting network is also sometimes called a resource. For example, configuring a resource can include simply choosing a topology without regard to choosing configuration options for the individual resources involved in the topology.

A video presenting network 100 can have a plurality of video paths. For example, as shown in FIG. 1, a path may be from the input 110A, through the converter 130A, to the output 120A. Another path may be from the input 110A through the converter 130A, to the output 120B, and so forth.

The topology of the video presenting network 100 can be configured so that there are different paths according to the configuration. For example, instead of sending the output of the converter 130N to the video output 120N, it could be routed to a different video output (e.g., 120B) by changing a configuration setting.

In any of the examples described herein, the video inputs (or “sources”) can take any of a variety of forms, such as those providing digital surfaces. In practice, the inputs can be configured to use a variety of source modes. Such modes can include parameters such as width, height, unit format, rasterized graphics filtering technique, primary surface chain length, the like, or some combination thereof.

In any of the examples described herein, the video outputs (or “targets”) can take any of a variety of forms, such as those providing output signals. A descriptor can be associated with the outputs. The descriptor can indicate a format (e.g., DVI, HDMI, HD-15, BNC, S-video, RF, RCA and the like) and HPD awareness. The output can also be associated with a video encoding type. Furthermore, an output can be configured to be in sync with another output.

In practice, the outputs can be configured to use a variety of target modes. Such modes can include parameters such as active region (e.g., width and height), total region (e.g., width and height), active region displacement, pixel encoding format, vertical retrace frequency, horizontal retrace frequency, pixel clock rate, content ordering, color primaries, white point reference, color space transformation matrix, the like, or some combination thereof.

In any of the examples herein, a digital-video-input-representation-to-video-output-signal converter can take the form of a video codec, a digital-to-analog converter, or the like. Some converters are sharable. For example, in a clone (e.g., mirror) mode, a codec may send its signal to two outputs.

Although any number of configurations of the video presenting network 100 are theoretically possible, only a limited number of theoretical configurations are functional configurations. In practice, the resources of the video presenting network 100 are subject to configuration interdependency.

For example, configuring the video input 110A to be of a particular type may consume a large amount of video memory. In such a case, there may not be sufficient remaining memory for another video input (e.g., 110N) to be of the same type. For example, it may only be configurable to a type consuming less memory.

There are a wide variety of other interdependencies. For example, the converters may only accept particular video input types or produce particular video output types. So, a particular input may not be functional in combination with a particular converter, and so forth.

Thus, in practice, an obstacle to implementing a desired configuration is that it may not be functional. Further, it is not easy to determine which combinations are functional out of the myriad of theoretically possible combinations for a video presenting network having a plurality of video inputs, a plurality of converters, and a plurality of video outputs (which can be interconnected in a variety of ways).

FIG. 3 is a block diagram showing combinations of configurable resources for a video presenting network. In the example, the theoretically possible configurations 300 can be assembled by connecting one or more of a configured first resource 302 (e.g., a video presenting network input), with one or more of a configured second resource 304 (e.g., a video presenting network converter), that are connected with one or more of a configured third resource 306 (e.g., a video presenting network output). The resulting set of theoretically possible configurations 310 is shown as a vast collection of possibilities, some of which are functional, and some of which are non-functional, depending on the configuration of the resources therein.

Finding a solution for an optimal configuration in such a vast solution space is a tri-partite graph matching problem, which is an NP-Complete problem. Therefore, using a brute force approach can be problematic when the number of possible configurations for the resources exceeds a reasonable number.

In any of the examples described herein, configuration of resources can take a wide variety of forms, including selecting a topology for a set of resources of the video presenting network or selecting configuration options (e.g., modes) for one or more resources in the network (e.g., whether or not the network is interconnected).

FIG. 4 shows an exemplary configuration method 400 which can be used for any of the video presenting networks described herein to achieve configuration. The method and any of the other methods described herein can be implemented via computer-executable instructions on one or more computer-readable media.

At 410, an indication of a configuration of a first resource of the video presenting network is received. For example, a configuration for a particular video input of the video presenting network can be received.

At 420, separately from the indication of the configuration of the first resource, an indication of a configuration for a second resource of the video presenting network is received. For example, a configuration for a particular video output of the plurality of outputs of the video presenting network can be received.

Then, at 430, the video presenting network is configured according to the indications of configurations.

In practice, additional indications of configuration can be separately received for any resources of the video presenting network (e.g., for two different inputs, two different outputs, two different converters, a converter and an output, and so forth).

Separately received indications can include those received by using two different calls, such as those to a programmatic interface (e.g., device driver interface calls). For example, two different calls to a device driver can be used. Or, two different parameters can be used in the same call. Or, one or more data structures indicating separate values for the resources can be used. Such calls can come from a client such as an operating system.

In such a way, the resources of the video presenting network can be independently configured. Such configuration can also indicate a topology for the video presenting network (e.g., how the resources are interconnected).

Using a provisional configuration approach can facilitate a variety of functionality, including finding a desirable configuration among the myriad of possible functional configurations. FIG. 5 shows a table 500 indicating provisional configuration of a resource of a video presenting network such as that shown in FIG. 1.

In the example, the resource σ1 has been provisionally configured (e.g., configuration parameters for the resource of the video presenting network are stored but the configuration need not be fully functional). Such a provisional configuration can be based on receipt of a partial configuration (e.g., a configuration of a resource out of the video presenting network resources or an indication of a topology for the video presenting network). Configuration for all resources need not be received for a provisional configuration. Because a configuration without the full set of configuration parameters is typically not yet functional, a provisional configuration is sometimes called “semi-functional.” Providing a partial configuration for a resource is sometimes called “pinning” the resource. If desired, the partial configuration can be removed (or overridden). Removing the partial configuration is sometimes called “unpinning.”

A transactional approach to achieving configuration of a video presenting network can be based on the described provisional configuration. FIG. 6 shows an exemplary arrangement 600 for achieving configuration of a video presenting network 630 (e.g., the video presenting network shown in FIG. 1) via a transactional approach.

In the example arrangement 600, a client 610 can send partial configuration information for a video presenting network to a server 620. Upon receiving a commit, the server 620 can then configure the video presenting network 630 according to the indications of partial configuration.

FIG. 7 shows an exemplary method 700 for performing configuration via a transactional approach. At 710, a series of partial configurations for the video presenting network are received (e.g., from a client by a server). The partial configurations can be used to build a provisional functional configuration.

At 720, the provisional functional configuration is committed. The committing can implement the provisional functional configuration in the video presenting network (e.g., the network 630).

A provisional functional configuration can be stored without being implemented. For example, the configuration can be stored without configuring the resources of the video presenting network (e.g., until a commit configuration indication is processed).

Due to interdependencies between the resources of a video presenting network, some theoretically possible configuration options may not be functional in light of a provisionally functional configuration that has already been assembled. For example, given that the resource σ1 has been provisionally configured (e.g., as shown in FIG. 5), the configuration options available for another resource of the video presenting network (e.g., σΣ) may be restricted.

FIG. 8A shows an exemplary set of configuration options 850 for a resource σΣ, out of which only a subset 860 of configuration options are available (e.g., would result in a functional configuration) in light of how another resource σ1 has been provisionally configured. In such an arrangement, the available configuration options are sometimes described as “co-functional” with the other configuration options (e.g., of the provisional functional configuration) or “not invalidating” a provisional configuration.

The set of co-functional configuration options 860 for a resource can be provided as feedback during provisional configuration in a process sometimes called “enumeration.” Such feedback can then be used to make decisions regarding further configuration (e.g., to further build the provisional functional configuration or to backtrack to an earlier provisional functional configuration).

In some cases, it may be desirable to remove a partial configuration from the provisional functional configuration. For example, it may be discovered that the provisional functional configuration does not permit configuration of an as yet un-configured resource in a desired way. Accordingly, any of the configuration methods described herein can include receiving an indication to remove a partial configuration from the provisional functional configuration and remove the partial configuration responsive to receiving the indication (or, simply a new partial configuration, which overrides the old). In this way, a method can backtrack (e.g., unpin a resource) to an earlier provisional functional configuration (e.g., before committing the provisional functional configuration).

In practice, it may be desirable to determine co-functional configuration options for plural resources at once. For example, after a given topology is selected as part of a partial configuration, it may be desirable to enumerate the configuration options for video presenting network sources that are co-functional with the selected topology.

FIG. 8B shows an arrangement in which co-functional configuration options 880A, 880B, and 880C for respective resources (e.g., σ1, σ2, and σ3) are indicated, wherein configuration options for more than one resource at a time are indicated. The co-functional configuration options shown are co-functional with respect to the chosen topology. The options may not be co-functional with respect to each other. For example, choosing one of the co-functional options for a first resource may invalidate (e.g., not be co-functional with) another one of the co-functional options of another resource.

In the example, at least some of the original options (e.g., 870A, 870B, and 870C) are no longer available (e.g., are not co-functional) in light of the chosen topology. A similar arrangement is possible when options are enumerated for other resources (e.g., targets).

Such options can be enumerated by software (e.g., a video driver). In any of the examples described herein, it may be desirable to guarantee that if any of the enumerated options are chosen for one resource, such a choice will be co-functional with at least one (e.g., will not invalidate all) of the options for any of the other resources.

In practice, after having enumerated the configuration options (e.g., for a plurality of resources) co-functional with a topology for a plurality of resources, such configuration options can be included in a partial, provisional configuration. However, pinning (e.g., provisionally choosing) one of the configuration options for a first resource may invalidate (e.g., not be co-functional with) another option for another resource.

FIGS. 9A-C show an example in which choosing a configuration option for one resource invalidates a configuration option for another resource. A topology can be chosen. FIG. 9A shows the co-functional options 920A, 920B, and 920C (e.g., subsets of theoretically possible options 910A, 920B, and 920C, respectively) enumerated after having chosen a topology. Then, FIG. 9B shows that a particular option 921 has been chosen (e.g., pinned) for a first resource. As a result, some of the configuration options for the other resources may no longer be available (e.g., they are invalidated). In the example, an option no longer appears in 920B′. In some cases, other options are invalidated. Or, perhaps none are invalidated.

FIG. 9C shows that a particular option 922 has been chosen (e.g., pinned) for another resource. As a result, some of the configuration options for the remaining resources may no longer be available. In the example, an option no longer appears in 920C″. In some cases, some of the options for the first resource may also be invalided (e.g., resulting in a set 920A′, not shown). However, in practice, after a resource has been pinned (e.g., a configuration option has been chosen for the resource), the pinned configuration option will not be invalidated by choosing another one of the enumerated configuration options.

Due to the phenomenon illustrated in FIGS. 9A-9C, when enumerating for plural resources, it may be necessary to check for invalidated options after pinning a resource. Such can be performed by re-enumeration.

FIGS. 10A-C show another example in which choosing a configuration option for one resource invalidates a configuration option for another resource. A topology can be chosen. FIG. 10A shows the co-functional options 1020A, 1020B, and 1020C (e.g., subsets of theoretically possible options 1010A, 1020B, and 1020C, respectively) enumerated after having chosen a topology. Then, FIG. 10B shows that a particular option 1021 has been chosen (e.g., pinned) for a first resource. As a result, some of the configuration options for the other resources may no longer be available (e.g., they are invalidated). In the example, an option no longer appears in 1020B′. In some cases, other options are invalidated. Or, perhaps none are invalidated.

FIG. 10C shows that a particular option 1022 has been chosen (e.g., pinned) for another resource. As a result, some of the configuration options for the remaining resources may no longer be available. In the example, an option no longer appears in 1020C″. In some cases, some of the options for the first resource may also be invalided (e.g., resulting in a set 1020A′, not shown). However, in practice, after a resource has been pinned (e.g., a configuration option has been chosen for the resource), the pinned configuration option will not be invalidated by choosing another one of the enumerated configuration options. Many other scenarios are possible.

FIG. 11 shows an exemplary arrangement 1100 for achieving configuration of a video presenting network 1130 (e.g., the video presenting network shown in FIG. 1) via a transactional approach with feedback.

In the example arrangement 1100, a client 1110 can send partial configuration information for a video presenting network to a server 1120. The partial configuration information can be for any of the resources of the video presenting network. The partial configuration can indicate a topology of the video presenting network.

After receiving the configuration information (e.g., a partial configuration, such as for a first resource), co-functional configuration options (e.g., for a second resource) can be provided. The co-functional configuration options can be for a different resource than the partial configuration, for a resource in a different path, and the like. The co-functional options can be restricted (e.g., at least one non-co-functional option is removed) based on the configuration information. As described herein, the options can be provided via enumeration, and enumeration can be done for plural resources at a time.

The co-functional configuration options for the other resource(s) can be based on interdependencies between the resources of the video presenting network. The client can select from among the co-functional configuration options and continue to build a provisional functional configuration.

Upon receiving a commit, the server 1120 can then configure the video presenting network 1130 according to the indications of partial configuration.

FIG. 12 shows an exemplary method 1200 for performing configuration with feedback from a server perspective. The method can operate via the arrangement shown in FIG. 11. At 1210, an indication of a partial video network presenting configuration is received. For example, the partial configuration can indicate a configuration for a first resource of the video presenting network.

At 1220, co-functional configuration options are indicated (e.g., as described for FIG. 11A or 11B, above). Alternatively, all configuration options may be indicated with the exception of one or more non-co-functional configuration options, which would be removed from the options indicated before the options are indicated. The method can also include a commit (not shown) by which the configuration is committed to the video presenting network.

FIG. 13 shows an exemplary method 1300 for performing configuration with feedback from a client perspective. The method can operate via the arrangement shown in FIG. 11. At 1310, an indication of a partial video presenting network configuration is sent. For example, the partial configuration can indicate a configuration for a first resource of the video presenting network.

At 1320, a set of co-functional configuration options (e.g., as described for FIG. 11A or 11B, above) are indicated. Again, the method can also include a commit (not shown) by which the configuration is committed to the video presenting network.

Determining co-functional configuration options can be delegated to a video driver. In any of the examples described herein, actions performed by the server can be performed by a video driver (e.g., a video miniport).

FIG. 14 shows an exemplary architecture 1400 in which provisional configuration with feedback can be implemented. The example includes a client 1410 (e.g., an operating system, such as the graphics subsystem, an application, or the like), a driver 1420 (e.g., a device-specific video driver operating in kernel mode) with interdependency logic 1425, and a video adapter 1430, which provides video output to plural display devices 1440A-1440N.

The video driver 1420 can serve as a server in any of the examples described herein. The interdependency logic 1425 can include functions for accepting partial configurations, enumerating co-functional configuration options, and committing a configuration.

In this way, a hardware vendor of a display adapter can develop an appropriate driver 1420 that incorporates the appropriate interdependency logic 1425 to aid in determining a desirable video presenting network configuration.

Implementing interdependency logic in a video driver, as discussed above in Example 18, can simplify determining an appropriate configuration by reducing the scope for a given hardware implementation with a certain set of limitations. If the logic were instead in the operating system, the task can be more complex (e.g., need to be completely generic and support every possible interdependency).

FIG. 15 shows an exemplary method 1500 for configuration of a video presenting network via partial configuration. At 1504, a topology for the video presenting network is chosen. At 1506, configurations options for the sources are enumerated and pinned. At 1508, configuration options for the targets are enumerated and pinned. A commit (not shown) can be used to implement the configuration.

In any of the examples herein, although sources are sometimes shown as pinned before targets, such need not be the case. For example, targets can be pinned before sources.

FIG. 16 shows a flowchart of an exemplary method 1600 of traversing a graph of possible functional multiple video output configuration combinations. Such a method can be used by a client (e.g., the client 1410) interacting with a server (e.g., video driver 1420). The example shows a video miniport, but another video driver (e.g., video driver 1420) can be used.

The example also includes a fixed topology functional video presenting network configuration search, but other examples may include an option of changing the topology during the search. For example, a topology may be desired to be changed after the pinning of a video present source mode on a video presenting network source invalidates at least one other video present source mode for another video presenting network source.

At 1602, a desired video presenting network topology has been selected.

At 1604, given the desired video presenting network topology, a video miniport is queried for a video presenting network configuration (e.g., topology) that supports at least one monitor-supported video signal mode (e.g., all modes) on at least one video presenting network target (e.g., all targets).

At 1606, the sets of available video present source modes on at least one video present source (e.g., all sources) in the obtained video presenting network configuration (e.g., topology) are enumerated.

At 1608, a video present source mode is pinned on at least one video presenting network source (e.g., all sources).

At 1610, it is determined whether there are any more video presenting network sources on which a video present source mode is to be pinned. If there is another video presenting network source to be pinned, the process proceeds to 1612. Otherwise, the process proceeds to 1614.

At 1612, it is determined whether any of the previously enumerated video present source modes has been invalidated. If so, the process returns to 1606. If not, the process returns to 1608. In the example, at least one of the previously enumerated video present source modes can be invalidated based on the selection of another video present source mode, but not all of the video present source modes can be invalidated by such a selection.

At 1614, the sets of available video present target modes on at least one video present target (e.g., all targets) in the obtained video presenting network configuration are enumerated.

At 1616, a video present target mode is pinned on at least one video presenting network target (e.g., all targets).

At 1618, it is determined whether there are any more video presenting network targets on which a video present target mode is to be pinned. If there is another video presenting network target to be pinned, the process proceeds to 1620. Otherwise, the process proceeds to 1622.

At 1620, it is determined whether any of the previously enumerated video present target modes has been invalidated. If so, the process returns to 1614. If not, the process returns to 1616.

At 1622, a resulting functional video presenting network configuration combination is committed.

FIGS. 17A-B show a flowchart of a first exemplary detailed method 1700 of traversing a graph of possible functional multiple video output configuration combinations. Such a method can be used by a client (e.g., the client 1410) interacting with a server (e.g., video driver 1420). The example shows a video miniport, but another video driver (e.g., video driver 1420) can be used.

At 1702, an initial video presenting network topology has been provided.

At 1704, given the initial video presenting network topology, a video miniport is queried for a video presenting network configuration (e.g., topology) that supports at least one monitor-supported video signal mode (e.g., all modes) on at least one video presenting network target (e.g., all targets).

At 1706, a determination is made as to whether the video presenting network topology specified by the query of 1704 is supported. If the specified video presenting network topology is supported, then the process proceeds to 1708. Otherwise, the process proceeds to 1710.

At 1708, a determination is made as to whether the current video presenting network topology is the most desired video presenting network topology. If it is, then the process proceeds to 1712. Otherwise, the process proceeds to 1714.

At 1710, a determination is made as to whether at least one other initial video presenting network topology exists. If so, then the process returns to 1704. Otherwise, the process terminates at 1790 because there is no convergence to a functional configuration combination with the desired search parameters.

At 1712, the sets of available video present source modes on at least one video presenting network source (e.g., all sources) in the obtained video presenting network configuration are enumerated. The process then proceeds to 1722.

At 1714, the video presenting network topology is adjusted to a new valid video presenting network topology by the addition or removal of a video presenting path (e.g., multi-path). The process then proceeds to 1716, where a determination is made as to whether the new valid video presenting network topology is supported. If so, then the process returns to 1708. Otherwise, the process proceeds to 1718.

At 1718, a determination is made as to whether there is at least one other desired video presenting network topology that can be obtained by incremental changes through valid video presenting network topologies. If so, the process proceeds to 1720. Otherwise, the process terminates at 1790.

At 1720, a determination is made as to whether another desired video presenting network topology is obtainable only by the null topology (e.g., the topology cannot be further adjusted). If so, the process returns to 1704. Otherwise, the process returns to 1714.

At 1722, a determination is made as to whether any of the enumerated video present source modes are missing a mode desired for the respective video presenting network source. If so, the process proceeds to 1724. Otherwise, the process proceeds to 1732.

At 1724, a determination is made as to whether any video presenting network sources have a video present source mode pinned. If so, the process proceeds to 1728, where a pinned video present source mode is unpinned, and then back to 1712. Otherwise, the process proceeds to 1730. The video present source mode unpinning at 1728 can be ordered according to video presenting network source importance (e.g., the source modes can be prioritized from most to least important).

At 1730, a determination is made as to whether there is at least one other video present source mode available for a video presenting network source. If so, the process returns to 1732, where a video present source mode is pinned on at least one video presenting network source (e.g., for all sources), and then to 1734. Otherwise, the process terminates at 1790. The video present source mode pinning at 1732 can be ordered according to video presenting network source importance (e.g., the source modes can be prioritized from most to least important).

At 1734, it is determined whether there are any more video presenting network sources on which a video present source mode is to be pinned. If there is another video presenting network source to be pinned, the process proceeds to 1736. Otherwise, the process proceeds to 1738.

At 1736, it is determined whether any of the previously enumerated video present source modes has been invalidated. If so, the process returns to 1712. If not, the process returns to 1732.

At 1738, the sets of available video present target modes on at least one video presenting network target (e.g., all targets) in the obtained video presenting network configuration are enumerated.

At 1742, a determination is made as to whether any of the enumerated video present targets modes are missing a mode desired for the respective video presenting network target. If so, the process proceeds to 1744. Otherwise, the process proceeds to 1752.

At 1744, a determination is made as to whether any video presenting network target has a video present target mode pinned on it. If so, the process proceeds to 1748, where a pinned video present target mode is unpinned, and then back to 1738. Otherwise, the process proceeds to 1750. The video present target mode unpinning at 1748 can be ordered according to video presenting network target importance (e.g., the target modes can be prioritized from most to least important).

At 1750, a determination is made as to whether there is at least one other video present target mode available for a video presenting network target. If so, the process returns to 1752, where a video present target mode is pinned on at least one video presenting network target (e.g., for all targets), and then to 1754. Otherwise, the process terminates at 1790. The video present target mode pinning at 1752 can be ordered according to video presenting network target importance (e.g., the target modes can be prioritized from most to least important).

At 1754, it is determined whether there are any more video presenting network targets on which a video present target mode is to be pinned. If there is another video presenting network target to be pinned, the process proceeds to 1756. Otherwise, the process proceeds to 1780.

At 1756, it is determined whether any of the previously enumerated video present target modes has been invalidated. If so, the process returns to 1738. If not, the process returns to 1752.

At 1780, a resulting functional video presenting network configuration combination is committed.

FIGS. 18A-C shows a flowchart of a first exemplary detailed method 1800 of traversing a graph of possible functional multiple video output configuration combinations. Such a method can be used by a client (e.g., the client 1410) interacting with a server (e.g., video driver 1420). The example shows a video miniport, but another video driver (e.g., video driver 1420) can be used.

At 1802, an initial video presenting network topology has been provided.

At 1804, given the initial video presenting network topology, a video miniport is queried for a video presenting network configuration (e.g., topology) that supports at least one monitor-supported video signal mode (e.g., all modes) on at least one video presenting network target (e.g., all targets).

At 1806, a determination is made as to whether the video presenting network topology specified by the query of 1804 is supported. If the specified video presenting network topology is supported, then the process proceeds to 1808. Otherwise, the process proceeds to 1810.

At 1808, a determination is made as to whether the current video presenting network topology is the most desired video presenting network topology. If it is, then the process proceeds to 1812. Otherwise, the process proceeds to 1814.

At 1810, a determination is made as to whether at least one other initial video presenting network topology exists. If so, then the process returns to 1804. Otherwise, the process terminates at 1890 because there is no convergence to a functional configuration combination with the desired search parameters.

At 1812, the sets of available video present source modes on at least one video presenting network source (e.g., all sources) in the obtained video presenting network configuration are enumerated. The process then proceeds to 1822.

At 1814, the video presenting network topology is adjusted to a new valid video presenting network topology by the addition or removal of a video presenting path (e.g., multi-path). The process then proceeds to 1816, where a determination is made as to whether the new valid video presenting network topology is supported. If so, then the process returns to 1808. Otherwise, the process proceeds to 1818.

At 1818, a determination is made as to whether there is at least one other desired video presenting network topology that can be obtained by incremental changes through valid video presenting network topologies. If so, the process proceeds to 1820. Otherwise, the process terminates at 1890.

At 1820, a determination is made as to whether another desired video presenting network topology is obtainable only by the null topology (e.g., the topology cannot be further adjusted). If so, the process returns to 1804. Otherwise, the process returns to 1814.

At 1822, a determination is made as to whether any of the enumerated video present source modes are missing a mode desired for the respective video presenting network source. If so, the process proceeds to 1824. Otherwise, the process proceeds to 1832.

At 1824, a determination is made as to whether any video presenting network sources have a video present source mode pinned. If so, the process proceeds to 1828, where a pinned video present source mode is unpinned, and then back to 1812. Otherwise, the process proceeds to 1830. The video present source mode unpinning at 1828 can be ordered according to video presenting network source importance (e.g., the source modes can be prioritized from most to least important).

At 1830, a determination is made as to whether there is at least one other video present source mode available for a video presenting network source. If so, the process returns to 1832, where a video present source mode is pinned on at least one video presenting network source (e.g., for all sources), and then to 1834. Otherwise, the process proceeds to 1831. The video present source mode pinning at 1832 can be ordered according to video presenting network source importance (e.g., the source modes can be prioritized from most to least important).

At 1831, a determination is made as to whether there is at least one other video present source mode available for a video presenting network source given any other desired video presenting network topology. If so, the process returns to 1818. Otherwise, the process terminates at 1890.

At 1834, it is determined whether there are any more video presenting network sources on which a video present source mode is to be pinned. If there is another video presenting network source to be pinned, the process proceeds to 1836. Otherwise, the process proceeds to 1838.

At 1836, it is determined whether any of the previously enumerated video present source modes has been invalidated. If so, the process returns to 1812. If not, the process returns to 1832.

At 1838, the sets of available video present target modes on at least one video presenting network target (e.g., all targets) in the obtained video presenting network configuration are enumerated.

At 1842, a determination is made as to whether any of the enumerated video present targets modes are missing a mode desired for the respective video presenting network target. If so, the process proceeds to 1844. Otherwise, the process proceeds to 1852.

At 1844, a determination is made as to whether any video presenting network target has a video present target mode pinned on it. If so, the process proceeds to 1848, where a pinned video present target mode is unpinned, and then back to 1838. Otherwise, the process proceeds to 1850. The video present target mode unpinning at 1848 can be ordered according to video presenting network target importance (e.g., the target modes can be prioritized from most to least important).

At 1850, a determination is made as to whether there is at least one other video present target mode available for a video presenting network target given the current video presenting network topology and video present source modes pinned on video presenting network sources. If so, the process returns to 1852, where a video present target mode is pinned on at least one video presenting network target (e.g., for all targets), and then to 1854. Otherwise, the process proceeds to 1856. The video present target mode pinning at 1852 can be ordered according to video presenting network target importance (e.g., the target modes can be prioritized from most to least important).

At 1854, it is determined whether there are any more video presenting network targets on which a video present target mode is to be pinned. If there is another video presenting network target to be pinned, the process proceeds to 1868. Otherwise, the process proceeds to 1880.

At 1856, a determination is made as to what is considered to be more important: the current video presenting network topology or the video present source modes currently pinned on video presenting network sources. If the video present source modes currently pinned on video presenting network sources are considered to be more important, the process proceeds to 1862. If the current video presenting network topology is considered to be more important, the process proceeds to 1864.

At 1862, it is determined whether there is at least one other desired video presenting network topology. If so, the process returns to 1818. If not, the process proceeds to 1866.

At 1864, a determination is made as to whether there is at least one other desired video present source mode given the current video presenting network topology. If so, the process returns to 1828. Otherwise, the process proceeds to 1862.

At 1866, a determination is made as to whether there is at least one other desirable video present source mode available on at least one video presenting network source. If so, the process proceeds to 1864. Otherwise, the process terminates at 1890.

At 1868, it is determined whether any of the previously enumerated video present target modes has been invalidated. If so, the process returns to 1838. If not, the process returns to 1852.

At 1880, a resulting functional video presenting network configuration combination is committed.

FIG. 19 shows a flowchart showing an exemplary method 1900 of determining a topology for a video presenting network in light of a goal (e.g., stated in terms of video modes supported by monitors).

At 1902, the process starts with an initial topology. At 1906, the initial topology is modified to better meet the goal (e.g., by generating a provisional functional configuration better meeting the goal). Such modifications can take into account interdependencies among resources of the video presenting network.

Possible goals can relate to video modes or other configuration options. For example, a goal can be the best way to route video presenting network targets to video presenting network sources in a video presenting network through the available video output codecs to maximize supported graphics video presenting network source mode sets on its video presenting network sources, given that video mode sets on the video presenting network targets must support preferred modes on all the monitors connected to them. Or, if such a goal cannot be attained, the goal can be the best way to route video presenting network targets to video presenting network sources in a video presenting network through the available video output codecs to maximize supported graphics video presenting network source mode sets on its video presenting network sources, given that video mode sets on the video presenting network targets must support preferred modes on the monitors connected to them in a specified prioritization ordering. Or, if such a goal cannot be attained, the goal can be the best way to route video presenting network targets to video presenting network sources in a video presenting network through the available video output codecs to maximize supported graphics video presenting network source mode sets on its video presenting network sources, given that video mode sets on the video presenting network targets must support at least one of the video modes supported by the monitors connected to them.

If desired, a first goal can be attempted. Then, if the first goal cannot be met, a second goal can be attempted, and so forth. A goal is sometimes described as an “optimal” configuration.

In addition to the goals described above, other configuration goals may be desired and can be facilitated by the technologies described herein. For example, it might be of interest to achieve the following, separately or in some combination:

1. Maximize the special resolution on the render targets

2. Maximize the color resolution on the render targets

3. Maximize both spatial and color resolutions on one of the render targets (e.g., for medical imaging applications, computer assisted design, and the like).

4. Match refresh rates on the monitors displaying a view which contains a real-time television broadcast presentation to avoid video stream synchronization issues. Such synchronization issues can manifest themselves as artifacts, dropped frames (e.g., glitches), or both.

5. Conserve the video memory bandwidth as much as possible by driving views at lowest rendering modes acceptable to boost 3D performance, assuming one or more GPUs are competing for the same video memory bus.

Because such goals are beyond the scope of a simple video driver, such goals can be achieved by placing decision-making ability outside of the video driver (e.g., in the upper layers of the operating system, such as in the shell, graphics subsystem, DX runtime, and the like).

Due to the sheer amount of possible rendering modes, a driver can not simply enumerate them. A query or a traversal approach (e.g., such as described in the examples herein) can be used to achieve configuration goals.

Still other goals can be classified as follows:

1. In a mode optimized for image quality, one cares most about displaying the image to the best degree possible.

2. In a mode optimized for performance, one cares most about not overloading the video memory bus (e.g., each codec has to read from the video memory, and thus consumes video memory bandwidth).

3. In a mode optimized for power consumption, one may want to choose the codec which consumes the least power, even if it can not drive preferred modes on either of two monitors, turning all other codecs off.

Typically, an implicit goal in any configuration is that the video outputs support at least one mode supported by the respective monitor. Unless overridden by performance or power management considerations, it is typically a further goal that video outputs try to support preferred modes of their respective monitors, where the monitor\'s importance is prioritized by the client (e.g., operating system) as part of the configuration request.

For example, the present the same render target on multiple views (e.g., clone view), the video driver should attempt to have as many monitors to run in their preferred modes, only sharing codecs when doing otherwise means one of the requested outputs can not be driven.