... and print if a format is advertised.
We now use the same style of message and use the term "advertise" for
formats that will be available via GdkDisplay::dmabuf-formats and
"supports" for formats the backend pretends it can handle but don't
want to advertise them.
Instead of only printing the advertised dmabuf formats, print all
supported ones. This is now useful information because we will try to
use them when downloading.
Fixes me looking like I don't know what I'm talking about on IRC when
claiming that llvmpipe can't do dmabufs, because it only supports linear
ones and we didn't print those.
We don't need our own mechanism for device selection; mesa has a
Vulkan layer that works perfectly fine for this purpose; just set
MESA_VK_DEVICE_SELECT.
If that flag is set, we keep the bounds of the original node when
rendering the modified node.
Gets around the replay test having to draw a transparent color node to
ensure the same bounds.
This reverts commit fd02afa2e4.
We don't want to remove the GL renderer from our tools yet, because we
use those tools for manual testing and having it available is useful.
In particular, reinstate the GL renderer for rendernode-tool benchmark.
Treat external as the normal case, and only try importing dmabufs
as non-external images if their format is on the internal formats
list.
Also add internal linear formats to the internal formats list.
This fixes an issue where AR24:0 dmabufs were imported as external
textures, causing some of the compare tests to fail.
Make this function return whether it was successful, and only emit
a debug message if we succeeded. In particular, make it return FALSE
if the dmabuf format is not linear.
The current context might be the last reference to the context, which
would make it go away when the renderer calls make_current().
See commit 0fa2ae48d4 for a similar case.
When we use download in the middle of an upload operation (or the
other way around), we may end up making a different GL context
current. The downloader code is reponsible for reestablishing
the previous context when it is done. The old GL renderer was
doing that, NGL wasn't, until now.
For dmabufs, the format is not an exact description of the data, it only
gives the closest memory format for a given fourcc.
This of course means that multiple different fourccs may report the same
format.
So when deciding if we need to copy the image to get the right data to
download, we need to check if the fourcc is correct, not if the format
is.
Related: #7046
When we want to download a dmabuf, we want to download the actual
dmabuf.
If we just grab the cached image and use that, we might get the
(reuploaded) copy of the dmabuf. This happens when this renderer
doesn't support downloading this dmabuf but has used it before.
Worse, this is a reentrancy issue, where this renderer is trying to
render the dmabuf and has already scheduled the upload but the upload
has not finished. We will then download from an empty image, which is
very wrong.
The way to check that we have the actual dmabuf is a bit brittle, but it
should work.
Fixes#7046
