D18570: EGLStream DRM Backend Initial Implementation

ekurzinger added a comment.


  In D18570#408853 <https://phabricator.kde.org/D18570#408853>, @romangg wrote:
  
  > First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard?
  >
  > I'm really not happy, that the `DrmOutput::present` is not run and we have to export these internals from DrmOutput to the EglStreamBackend, which replaces the flip with an EGL function call. Why does the Nvidia driver not integrate with the libdrm API in regards to page flipping? It should be possible to at least offer a wrapper around it or not?
  
  
  Well, our DRM-KMS driver technically does support atomic modesetting, however currently we only allow the presentation of GPU-accessible buffers through the EGLDevice / EGLOutput extensions. In fact, these use atomic modesetting capabilities in their implementation. As far as I know this will remain the case until work on the Unix device memory allocation library is complete and while this is still on the table it's a ways off yet. The new backend really just uses DrmOutputs to track whether a page flip is pending. If we don't want to expose these internals, an alternative might be to track this separately from DrmOutput::m_pageFlipPending and maybe install a different page flip handler when using EGL streams that would just clear this flag (and re-start the compositor). I'll see if I can get something like that thrown together, it might be a bit cleaner, actually.
  
  > Why are there multiple texture copies necessary in EglStreamTexture and does this not have a performance impact?
  
  When a texture is bound as the consumer of an EGL stream, it needs to be a GL_TEXTURE_EXTERNAL_OES. However, most of the core compositing code assumes window contents are in a regular GL_TEXTURE_2D. These two types of textures require different types of samplers in shaders, ect., so I think modifying KWin to composite directly from the stream-bound texture would make the change quite a bit more invasive. From some measurements I've taken, the overhead from the additional blit is in the neighbourhood of 0.15 ms (although I suppose this will depend on hardware), so I don't think it involves hugely significant performance hit. It's a vidmem -> vidmem transfer so at least it can take advantage of hardware acceleration. Having said that, I'm not too happy about it either. It's definitely a compromise.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D18570

To: ekurzinger, davidedmundson, graesslin, #kwin, romangg
Cc: wchilders, ognarb, abrahams, schernikov, guilhermesi, fredrik, cfeck, rapiteanu, romangg, hein, nicolasfella, zzag, kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart