Hi James, On 11 May 2016 at 21:43, James Jones <jajo...@nvidia.com> wrote: > On 05/04/2016 08:56 AM, Daniel Stone wrote: >> Right - but as with the point I was making below, GBM _right now_ is >> more capable than Streams _right now_. GBM right now would require API >> additions to match EGLStreams + EGLSwitch + Streams/KMS-interop, but >> the last two aren't written either, so. (More below.) > > The current behavior that enables this, where basically all Wayland buffers > must be allocated as scanout-capable, isn't reasonable on NVIDIA hardware. > The requirements for scanout are too onerous.
I think we're talking past each other, so I'd like to pare the discussion down to these two sentences, and my two resultant points, for now: I posit that the Streams proposal you (plural) have put forward is, at best, no better at meeting these criteria: - there is currently no support for direct scanout from client buffers in Streams, so it must always pessimise towards GPU composition - GBM stacks can obviously do the same: implement a no-op gbm_bo_import, and have your client always allocate non-scanout buffers - presto, you've matched Streams I posit that GBM _can_ match the capability of a hypothetical EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM cannot, but I posit that it is not a limitation of the API it exposes, and unlike Streams, the capability can be plumbed in with no new external API required. These seem pretty fundamental, so ... am I missing something? :\ If so, can you please outline fairly specifically how you think non-Streams implementations are not capable of meeting the criteria in your two sentences? Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel