randr provider object

[Alex Deucher]

On Wed, May 16, 2012 at 3:12 AM, Dave Airlie <airlied at gmail.com> wrote:
>>>
>>> I'm not sure I can really fix that with this though, thats a whole
>>> project by itself, and if fixing the crappy history of X decisions
>>> before we try and move on, we'll never get anywhere.
>>>
>>> The reason for exclusive_master is just GPU switching, since it needs
>>> to be an atomic operation, we don't want to keep both GPUs running,
>>> maybe I can add a separate protocol request for GPU switch, but I
>>> don't think it makes a huge amount of sense either.
>>
>>
>> My concern is how you're going to build this programmatically if you keep
>> with a poke-one-thing model, I just envision intermediate states that don't
>> make a ton of sense on their own but that we'd end up needing to allow.
>>  What do you imagine the sequence of requests looking like?
>
> I forsee the client side being smart like it is now,
>
> So user plugs in a new output device:
> client gets told something changed, rescans resources/providers.
> notices new provider with output slave support and a crtc (and
> outputs) - I think this is why I wanted to provide crtc/output lists,
> since the crtc/outputs aren't bound to the screen yet.
> client bind provider as a client slave, new crtc/output appears in
> resource list.
> client sets mode on new crtcs that appear, or offers them to user in gui app.
>
> User wants to offload rendering:
> launcher app notices an offload provider on the screen, sets env var,
> launches DRI2 app.
>
> User wants to switch GPUs to discrete:
> Notices an offload slave that can be master,
> requests it becomes master, and the current master becomes an output
> slave (thanks optimus).
>
> User wants to switch GPUs back to Integrated
> Notices an output slave that can be master,
> requests it becomse master: and current master becomes an offload
> slave (thanks optimus)
>
> plugs in an external monitor requiring a GPU switch to use (thanks optimus):
> not sure how best to deal with this, since I've no idea what the
> standard wiring is. On the my sample size of one laptop, the EDID is
> wired to the Intel GPU as well, so in theory we could poll via the
> Intel GPU to see if an external monitor appears on the powereed off
> GPU. There may also be some way to power up the DGPU on HPD irqs, but
> I've no idea.
> Assuming we can notice this, power up the DGPU, we probably need some
> sort of event to send to the client saying switch required for current
> HW configuration. Then the client sends the switch command as per the
> user doing it.

I can dig up the finer details on our PowerXpress configurations and
operations, but I think generally we have the following:

- igpu and dgpu with hw mux, all displays attached to both gpus
- igpu and dgpu with hw mux, panel attached to igpu, panel and
external connectors attached to dgpu
- no hw mux, igpu attached to all connectors, dgpu attached to no connectors
- no hw mux, igpu attached to panel, dgpu attached to external connectors

There is a fair amount of acpi magic involved to tell you how things
are wired up and to provide events when things change IIRC.  There's
also various crossfire configurations, but I think that's beyond the
scope of this.

Alex

>
> Dave.
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel