XDC: randr extension for full display state setup (full set of outputs and crtcs in one shot)

[Aaron Plattner]

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