On Mon, Oct 05, 2009 at 07:52:37PM -0700, Keith Packard wrote: > Excerpts from Dave Airlie's message of Mon Oct 05 17:18:30 -0700 2009: > > > On Mon, 2009-10-05 at 20:12 -0400, Alex Deucher wrote: > > > > > > You may have two or more huge monitors connected to a > > > low-end card that can't drive both at full res due to bandwidth > > > limitations.
> It seems to me that the actual requirement here is that the client > needs to know which configurations are possible, and that doing the > mode set atomically isn't actually relevant. As long as the client can > discover the set of possible mode combinations, setting the selected > configuration can use existing RandR protocol. I suppose as long as the path from the current configuration to the desired configuration doesn't go through a configuration that's not possible, atomicity doesn't really matter, but quicker modesets and reducing flicker might. > Adding protocol to expose the possible combinations of modes seems > fairly easy to me; getting applications to use that may be more of a > challenge. That seems like a fairly simple N-dimensional boolean > array. If you have four outputs with 20 modes each, that's 160000 > bits. Alternatively, you could set up some way to query the system for > a subset of this array. > > I have to say that I'm a little surprised that graphics hardware has > these kinds of limits nowadays; a 2560x1600 display only consumes > about 1GB/sec of memory bandwidth. Don't modern GPUs have around > 100GB/s of memory bandwidth available? In our case, there isn't just a single "memory bandwidth" number that you can send to clients. There are a number of internal chip components that have various bandwidth limitations, and it's not just the mode's raster timings that affect it but also whether the mode is scaled, how much scaling is applied, what filtering is applied, whether various display features are enabled, etc. It's just not feasible to send the complete equation to the client and hope they'll figure it out. The only reliable way to tell whether a given configuration is going to work is to ask the driver, which is why NV-CONTROL has mode validation and mode switches as two separate steps. Also, like Adam said, it's mostly ultra-low-end parts that have the nasty constraints. > > I'm just not sure how failing the modeset is going to help no > > matter what you do, how is the client expected to know what was > > wrong with what he asked for? you need to enable intelligent > > client behaviour much more than fail. > > Which is why RandR just bails today; the driver is allowed to say 'no' > to any configuration request. This is what I didn't like about RandR: if the target configuration isn't possible, the client doesn't find out until partway through some complicated set of steps required to get there, and now the client is left holding the bag trying to figure out how to undo the parts that did succeed. Separating queries from actually setting the mode would be helpful. -- Aaron _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
