LCA14 Graphics Working Group Wrap-up

Posted: March 17, 2014 in Uncategorized

The last session has pasted. As I write this, it’s sort of situation out of the twilight zone. I’ve managed to break my glasses. I’m fairly near sited but my vision isn’t good enough for my screen to be in focus at an average distance.

The last day of Connect we had two sessions. Friday is a tough day to run a session both on account of  people being tired. Numbers suffer and it seems like we are all subject a -20 IQ modifier to the technical discussion at times.

Friday Sessions

The ION session covered the current work in progress with John Stultz from the Android team and Sumit Semwal tag team presenting.  Since Plumbers there’s been a good amount of activity.  Colin Cross updated this code a fair amount as it was reviewed. He created a number of tests which John Stultz ported outside of Android, a dummy driver has been put together for testing on non ION enabled graphics stacks and the 115+ patch set was pushed up into staging. As of right now these patches build and run on ARM, x86_64 and ARM64. There’s more to do, the team is working to get the tests running in LAVA. There are a number of design issues yet to be worked out on the dma-buf side of things. The needs to be a constraint aware dma-buf allocation helper functions. Dma-buf needs to try and reuse some of the ION code so they are both reusing the same heaps. Then there needs to be a set of functions within dma-buf that will examine heap flags and allocate memory from the correct ION heap. It all boils down to having a more common infrastructure between dma-buf and ION such that the ION and dma-buf interfaces will rest nicely on what is there instead of being two separate and divergent things.

Benjamin Gaignard presented on Wayland / Weston. He reviewed the current status of the future replacement of X,  it’s status on ARM and how people can use it today. He covered current efforts to address some of the design failings of Wayland/Weston that assume all systems have graphics architectures like Intel. The use of hardware compositors over GPUs on ARM shows a disjoint view of the world as compared to intel that just assumes everyone has a GPU and will want to use things like EGLImage. This is a common theme which we must introduce time and time again to various developer communities who have limited ARM experience. At this point the focus Benjamin has been more to try and introduce into Wayland/Weston the ability to take advantage of dma-buf to promote the sharing of buffers over copying. It’s a slow go especially without the user space dma-buf helps which was from the session yesterday. Wayland/Weston is viable for use on ARM. It’s not perfect and we anticipate more work in this space first with dma-buf and then to take advantage of compositing hardware often found on ARM SoCs.

Summary for the week

Media & Lib Team

I’m pleased that the media team was able to get a list formulated of the next media libraries to port and optimize for AARCH64.  We synced with the ARM team which is also working in the area of optimization. This is vital so that we don’t replicated efforts accidentally.

Display Team

Bibhuti and I were able to sit down and discuss the hwcomposer project. We’ve set the milestones and we’ll set the schedule. I think it’s more than fair to say we’ll be showing code at the next Connect. The next step for Mali driver support on the graphics LSK branch includes further boards depending on their kernel status as well as some discussion about the potential to try and formally upstream the Mali kernel driver even in the face of likely community opposition.  We had great discussions with the LHG and no doubts we’ll be working together to support LHG like we do with other groups.

UMM

As discussed above the UMM team is heads down on creating their initial PoC for connecting the heap allocators to provide map-time post attach allocation. This is code in progress and a very important step in knitting the ION and dma-buf worlds closer together.

GPGPU

This was more of a quiet connect for GPGPU since projects are mid stream. GPGPU is more is a “sprint” like mode than a “connect” like mode. We did release the GPGPU whitepaper to the Friends of OCTO.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s