On Wed, May 16, 2012 at 3:12 AM, Dave Airlie <[email protected]> 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. > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
