Introduction and updates from NVIDIA
daniel at fooishbar.org
Wed May 11 21:31:21 UTC 2016
On 11 May 2016 at 21:43, James Jones <jajones at 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,
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
- 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?
More information about the wayland-devel