Hey Everyone,
I just wanted to thank once again, all the folks who were able to attend and participate at the Android+Graphics discussion at Plumbers. For those who could not attend, A free-link to my summary on LWN is here: http://lwn.net/SubscriberLink/569704/a20145dcfbaf70f1/
Hopefully there aren't too many inaccuracies in my summary.
I also wanted to start a thread to try to continue some of the discussions that went on, and try to make sure we have a sense of the next steps, now that folks have had some time to think about what all was said.
Sync:
* Maarten has already started looking at integrating the Android sync interface on top of his dmabuf-fences. http://www.spinics.net/lists/dri-devel/msg46180.html
* Hopefully he and Erik can continue to collaborate to better understand each others concerns, and we'll be able to get the Android explicit sync interface upstreamed and out of staging, and integrated into the various DRM apis needed.
ADF:
* Rob has reposted his atomic modesetting patches, which helps adress part of some of the issues Greg tried to resolve with ADF, although there still is the delta vs full update issue. http://www.spinics.net/lists/dri-devel/msg46413.html
* Also didn't see any details in the atomic modesetting patches about if or how explicit syncpoints might be used w/ it.
Rob: is that something you have any plans for at this point? Or are you looking to someone to try to integrate sync points with your patches?
Greg: Don't know if you saw the thread above, but having your feedback and thoughts on Rob's patches would be valuable here.
* The need for KMS helpers to reudce boilerplate seemed to be widely agreed upon, but I'm not sure if anyone is actually planning to put any effort.
Other KMS extentions:
* I'll let Laurent pipe in with any other next steps he has.
ION: * Hoping to merge ion into staging after Colin's fixes to make it less arm32 specific land in AOSP
Colin: Those patches seem stalled in Gerrit. Are you planning a next iteration of the patchset?
* I'm in talks w/ Sumit about making a first pass on using the ion heaps implementation to back the dmabuf exporter allocation logic.
Any other thoughts, questions or plans here?
thanks -john
On Thu, Oct 10, 2013 at 01:07:58PM -0700, John Stultz wrote:
ADF:
- Rob has reposted his atomic modesetting patches, which helps adress
part of some of the issues Greg tried to resolve with ADF, although there still is the delta vs full update issue. http://www.spinics.net/lists/dri-devel/msg46413.html
I've read up your excellent lwn write-up and tbh I don't understand why this is an issue - userspace can always opt to emit the full state if it wants to. And drm already keeps all the properties around somewhere (afaik at least) so I don't think drivers have to keep track of that much stuff.
So a simple "just write the entire hw state" model should be doable with not that much work.
- The need for KMS helpers to reudce boilerplate seemed to be widely
agreed upon, but I'm not sure if anyone is actually planning to put any effort.
Imo this is simply ongoing stuff done on a as-needed basis. Personally I have some plans to extract more helpers for handling the dp aux transactions and sink detection.
I have a bit the impression that part of this due to the helper code in drm_crtc_helper.c which has a lot of driver callbacks and is written with the usual bread of hw found on desktop gpus in mind. I guess for a lot of hardware this is simply the wrong abstraction level and interfacing a bit higher up (e.g. at the level of drm_crtc_helper_set_mode) could be much more appropriate.
And of course there's always the option of just rolling your own infrastructure like i915.ko now does. -Daniel
On Thu, Oct 10, 2013 at 5:09 PM, Daniel Vetter daniel@ffwll.ch wrote:
- Rob has reposted his atomic modesetting patches, which helps adress
part of some of the issues Greg tried to resolve with ADF, although there still is the delta vs full update issue. http://www.spinics.net/lists/dri-devel/msg46413.html
I've read up your excellent lwn write-up and tbh I don't understand why this is an issue - userspace can always opt to emit the full state if it wants to. And drm already keeps all the properties around somewhere (afaik at least) so I don't think drivers have to keep track of that much stuff.
it isn't actually an issue..
Or rather, it would simplify the kernel part to only support the "full state update" model.. but in a post-x11 linux userspace world, that isn't really an option for us, since we are moving away from hw specfic userspace component talking to KMS and "full state" includes things which are hw specific.
But if you support delta-update then you can support a userspace which either does full updates or delta updates. The direction I'm going w/ atomic ioctl... well, it is not as simple as ADF but most of the hard work is done by the atomic helpers rather than each driver.
BR, -R
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
John Stultz -
Rob Clark