SUMMARY:
-----------------

Graphics and Display:
~~~~~~~~~~~~~~~~~
- Open source graphics drivers are gaining speed, but there's still
some time before they become very useable in the real world. Not many
Open CL drivers too.
- Splitting DRM/KMS into separate device nodes (render nodes) is a
very good idea, which will be available soon, and be very valuable in
the GPGPU space specially.
- CDF will quite likely 'morph' into changes in drm framework itself -
the DRM bridge + encoder, generic drm-entity, which can use
Media-controller idea of topology discovery.

Android and Display:
~~~~~~~~~~~~~~~~~
- Sync
  - explicit sync is needed for android, even though atm it's still
used only for buffers - needed because of consolidated sync contract
requirements;
  - dma-buf fences are still the 'fence of priority' for upstream;
though there is keen intention to see how syncpoints can fit 'on top
of' dma-fences as a special case
    -- sync might be made optional as well

- ADF:
  - Android's 'answer to issues with using DRM/KMS in hwcomposer'
  - certainly not welcome in the open source community - so pretty
hard to upstream (and, as many things android, it might not be their
intention too)
  - KMS extensions that will help in providing things that ADF needs:
    - atomic modeset + nuclear pageflip
    -- maybe provide complete frame info rather than incremental state
    - bunch up CRTCs
    - split planes out of CRTCs

- KMS extensions:
   - memory writeback - use V4L
   - chained composers - make camera more like gpu, sequence building
in userland;


- ION:
  - Discussions on centralized vs per-driver allocators?
    - could be an available framework for centralized; you choose it
based on your use cases - if you need. (like Android)
  - Prototype constraint solving w/ dma_parms
    - Try to share some of the lower layers - maybe use heap pointers
/ heap cookies in struct device in the kernel to establish constraints
  - Android developers had performance concerns about post-attach allocation
    - Of course, post-attach allocation could be non-deterministic
  - Addressing performance optimization made
      - First, attempt to have it upstream, then try to optimize
userspace interface
  - Think of enumerating different types of 'generic' heaps useable in
the system:
     - chunk heap, system heap, CMA heap, secure heap, Device-specific heap
     - could use DT to populate those.

  - Move ion to staging for transition?


************************************************************************
DETAILED NOTES:

Graphics and Display:

===========================
Session: State of the Art Debugging and Tuning Graphics Applications:
Ian Rominick, Intel
* Debugging
- Windows:
  - Multiple closed source tools on Windows: AMD / NVIDIA / Intel;
  - driver-assisted debugging
- Linux:
  - Some open source tools on Linux: apitrace, (Not maintained) BuGLe;
  - some closed source ones - NVIDIA;
  - Driver assisted debugging
  - uniquely on linux, gdb can be used for in-code debugging!

* Performance tuning:
- Win:
  - same vendor tools; GPUView etc
  - driver assisted performance monitoring
- Linux
  - NVIDIA, intel_xxx_top

* Universal problems:
- vendor specific tools; many directx specific: some need to be,
because of sensitive information.

* Possible solutions:
- something that Android does is worth looking; traceview;
======================
Session: Open Source Graphics on ARM (Rob Clark)
* Quick update:
- Etnaviv (Vivante):
  - very fast progress
  - unified shader
  - very PC-like generic infra; gallium w/ fbdev backend only; no dri/drm or ddx
- Grate (tegra)
  - early research state
  - separate fragment and vertex shaders
- Lima (Mali)
  - Mostly for Mali 200/400; mesa classic/ dri drivers are beginning to work
  - prelim investigation on T6xx)
  - 200/400:
   - separate vertex and fragment shaders
   - OpenGLES 2.0
  - T6xx:
   - exynos 5
   - OGLES 3.0
   - Unified Shader
- Freedreno (Adreno)
  - initial MSM drm/kms driver upstream
  - working gallium driver
  - xf86-video-freedreno
  - Wayland / weston support
  - Adreno 2xx
   - OpenGLES 2.0, Unified Shader ISA,
  - Adreno 3xx
   - OpenGLES 3.0, OpenCL 1.1
   - Unified Shader
(slides: http://people.freedesktop.org/~robclark/soc-graphics-update.pdf)


======================
Session: Media Decode and Composition: Bridging the Gap (Daniel Stone)

======================
Session: Splitting DRM/KMS Device Nodes (David Herrmann)
Intention: allow GPGPU processing via DRM/KMS.

Currently a single device node on the system offers both rendering and
mode setting APIs.
=> Not optimal for applications wanting to do either one.

DRM master is required to access mode setting API.  Big issue there is
authentication.
Traditionally handled by the X server, but moving forward, this will
not always be available (non-graphics uses, other display managers,
etc.).

Problems around "hand-off" of DRM master, as there is a window of
opportunity where a bad process can try to acquire the DRM master just
as it is dropped by the original master (rather than the intended new
master).

Render node minor devices offer render-only interface to the DRM device.
Next step might be modesetting nodes...

gbm example: https://github.com/robclark/kmscube

Are changes needed in libdrm?  Hopefully Not.

======================
Session: Common Display Framework (Laurent Pinchart)

Direction:
Work to make changes in DRM first - Combine DRM bridge and encoder
into one entity. Still need to preserve existing user space API using
those objects. Then, CDF ideas of generic entities might be foldable
into "drm-entity"

Details:
KMS is alright for now,  but might be too limited for imminent
graphics/media/display pipelines.
Initial implementation reflects "linear" pipeline model.  Meant to
represent current display hardware pipelines.

CDF entities - atomic-level objects with get/set operations.  These
are used to negotiate configuration of the pipeline.

get/set operations act on a "configuration store". to allow testing
potential pipeline configuration without committing it.

DT bindings: default bindings borrowed from V4L.

CDFv3 uses media controller API to preserve the topology of the
bindings, and make that available to other kernel APIs (KMS, v4l2); no
new user-space API.

Not "mandatory".  Device drivers that do not need the functionality
are not obligated to use it (probably many "desktop" platforms).
However, many SoC-based platforms are likely to be able to take great
advantage of this.

robclark's concern: "too sweeping" rather than incremental.  Also,
should be more integrated with 'modern display frameworks' like KMS.

pinchartl : there are separate video and display pipelines
(potentially on the same SoC) that use the same exact blocks, thus
duplicating the driver.

The big question: how many commercial platforms have IP block
duplication? Is it enough to warrant a common solution, or is it
really just a couple of platforms worth (Exynos, Xilinx came up during
the discussion).


*************************************************************************************
Android and Graphics:

Sync/dmabuf-fences/dmabuf-sync:
- Enumerate semantic differences
    - Questions on Need for wound/wait in Android sync?
    - Costs for some checking is cheap on big desktop cpus where mesa
is usually used
- Why explicit sync is required for Android?
    - consolidates sync contract
    - Not used for anything other then buffers so far (and nothing yet planned)
- How can we share infrastructure?
     - Rob not opposed to adding sync objects to various calls, but
wants i tto be optional
     - Erik: -1 sync objects means the buffer is ready, so that seems ok
     - Rob: issues with unwinding hardware fences and other error conditions
             - Erik: shoot the gpu?
     - Tom: Sorting out why things didn't happen on time or out of
order, sorting bugs very hard
             - Sync's debugging tools make it easier
    - Maarten: lockdep support is there for implicit uses
            - don't hold things across system calls
            - Rob: We're mixing things
- Is there a way to have a hybrid explicit/implicit fence?
- What are next steps? Who’s doing what?
    - See how to make syncpoints fit on top of dma-fence
        - Too intrusive to plumb explicit sync through non-android stacks
        - make it optional
    - Android sync fences independent of ion - Rob: we want to have it
part of dma bufs

- Links:
sync:
    http://lists.linaro.org/pipermail/linaro-mm-sig/2013-February/003078.html
dma-buf fences:
    http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=c9453d5f549a4067af1c1a7dcfd990a08b6662af

Atomic Display Framework (ADF):
- What is ADF?
- Issues creating KMS based HWComposer
- How can KMS be extended to provide needed functionality?
   - Wayland is similar to surface flinger
   - Need similar features: atomic update, ganged crtcs, split out planes
       - hard to epress genericly: badwidth constraints, etc


- What are next steps? Who’s doing what?
- Links:
    Discusion thread: http://thread.gmane.org/gmane.comp.video.dri.devel/90761
KMS HWComposer talk: http://www.youtube.com/watch?v=AuoFABKS_Dk


KMS Extensions:
- ADF Cont.
- Non-memory-backed pipeline sources
- Memory write-back
    - drm helpers needed if v4l interface is the way to go to help
driver writers
    - userland wants v4l (at least desktop - likely android too)
    - please don't reinvent wheels, use v4l
- Chained composers
   - changing configs/params while streaming
      - make the camera more like a gpu
      - sequence building in userland, handling cmd in kernel or hdw
- Non-linear pipelines (multiple encoders, …)
    - hook two crtcs up to one encoder, but sort of handwavy. Needs
more discussion later
- Root plane that doesn’t span the whole display
  - handling backwards compatability is important
  - try to include this in atomic mode set
- ADF vs atomic mode set
    - ADF provides a complete frame
    - atomic mode set: provides full set or incremental, not required to be full
    - composer has fully specified set
          - having to diff against previous state to push to kms for
atomic is a pain
          - resetting entire config every time could be expensive

- What are next steps? Who’s doing what?
- Links:
 - atomic modeset / nuclear pageflip:
http://www.x.org/wiki/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf


ION:
- Centralized vs per-driver allocators?
- How to prototyping constraint solving w/ dma_parms?
- Android dev concerns about post-attach allocation
- Addressing performance optimization made.
- How do android developers plan to deal with non 32bit arm systems?
- What are next steps? Who’s doing what?
    - Try to share some of the lower layers for constraint solving
        - Device -> heap pointers in the kernel to establish constraints
    - Address userspace interface last
    - Move ion to staging for transition
- Other dma-buf issues?
- Links:
    https://lwn.net/Articles/565469/

Phasing out FBDEV:
- How would this affect Android’s future directions?
   - not a problem, adf already covers this
   - need the viable alternative upstream

- What are next steps?

WorkingGroups/Middleware/Graphics/Plumbers/Sumit-2013 (last modified 2013-09-30 14:30:04)