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)