AFAIK, yes, full DRI3 with rendernodes should let us use the offloading without a separate xorg driver. I was mostly curious/grasping at straws. The "GPUDevice" log message was something I noticed when I was trying a fbdev/modesetting driver combo (in the hopes modesetting would load the mesa drivers but not grab a screen, then use PRIME to offload from fbdev to modesetting...)
Anyways, this was also when I noticed gk20a related commits in xf86-video-nouveau. I'm not sure if a modesetting/glamor setup versus a direct exa setup would be better, but I think with the kepler chip we'll have the option.
Hmm, I don't have any hetereogeneous setups to test PRIME on... I'm not sure if this is just the intel driver lacking the necessary features or what...
Yeah, for the chromebook we'd need "reverse prime" but this [ideally] should also work "out of box" with DRI3 IIRC.
I have not made any progress on EMEM related work... I actually found out the hard way that even using a plain un-encrypted external drive over USB will start throwing "EMEM decode error" after transferring ~700 MB and will eventually lock up my entire system.
I was scouring the device-tree and tegra-mc drivers trying to find differences between the downstream and upstream kernel, but I can't tell if the driver has been refactored heavily, or is missing portions of behavior. I definitely need to start asking around in #tegra, but just need to find the time to do so.