Instead of linking directly to openswr.org, let's link to the driver
docs, and have the driver-docs link to the project-webiste.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11109>
This driver was removed in 435de835cd ("swrast: Remove the classic
swrast DRI driver"), but we forgot to update the documentation to
reflect that.
Better late than never!
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11109>
No other drivers use the vendor in the title or path, so it seems better
to not do this for the vmware-guest driver as well. So let's rename it
to SVGA instead. The actual text itself makes it clear enough what it is
about.
This makes it stand out less in the toctree.
I chose the name "WMware SVGA3D", because that's less ambigious than the
"SVGA"-alternative, and was requested by VMware people.t
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11109>
This adds a few missing APIs (like Vulkan), and reorders the list to
match the order we're listing them on the frontpage of mesa3d.org.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11109>
We support all versions of OpenGL ES, no need to point out each version.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11109>
It seems something went wrong during conversion of this article (or
maybe even before in the HTML version), where every header after the
"Gallium environment variables" header was nested below it.
That's clearly not what's meant here, so let's fix that.
This makes the toctree make a bit more sense for this article.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11106>
This provides most of the implementation, but there are some
things we cannot enable until we improve of kernel submit
interface, namely:
We don't expose capacity to export SYNC_FD, although we do
have the implementation in place. This requires that we
improve our kernel interface and event wait implementation
first so we can cover the corner case where the application
submits a command buffer that includes a VkCmdWaitForEvents
and tries to export a SYNC_FD from its signal semaphores or
fence before it the event is signaled and the command buffer
is sent to the kernel for execution in full.
Likewise, we can't currently import semaphores. This is because
our current kernel submit interface can only take one syncobj.
We have been working around this so far by waiting on the last
syncobj produced from the device whenever we had to wait on any
semaphores (which is obviously suboptimal already), but this
won't work as soon as we allow importing external semaphores,
as those could (and would typically) be produced from a
different device.
Once we address the kernel bits, we should come back and enable
SYNC_FD exports as well as semaphore imports.
Relevant CTS tests:
dEQP-VK.api.external.fence.*
dEQP-VK.api.external.semaphore.*
dEQP-VK.synchronization.cross_instance.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11105>
So we don't need to provision aarch64 servers, which are these days
rarer than x8_64.
In the switch to the new runner tags, switch to one which contains the
device type, so we can dimension the runner jobs taking into account the
number of DUTs available.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11108>
In the last round of IRC link updates, #freedesktop hadn't moved yet. Now
it has, so let's update the reference.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10975>
I didn't initially update this one because craftguy hadn't moved to OFTC
when I wrote the last patch. But now he has, so let's also update this
reference.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10975>
DFSM has never been enabled by default because it was slower.
RadeonSI is also dropping support for this because they discovered
that's actually not efficient in practice.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10968>
We don't have any special restrictions associated with the number
of descriptors in a set other than maybe not exceeding what we can
put in a single memory allocation, so in practice, applications will
be limited by the per-stage contraints defined by other Vulkan limits.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10970>
We don't do anything for input attachment aspects read by a subpass
since it doesn't have performance implications for us.
We also ignore the the new depth stencil layouts because they don't
have practical implications for our implementation.
We also ignore the new usage info for views since we are not currently
making decisions about views based on their usage.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10951>
Similar to the other channels, #lima is also moving to OFTC, so let's
update the links as appropriate.
While we're at it, fix the URI scheme to use a slash as a host/channel
separator, and drop the hash for maximum compatibility.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10917>
Panfrost has already moved their IRC-channel to OFTC, so let's update
the docs as well.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10917>
We have decided to follow what's happening with #dri-devel for #zink as
well, so let's update our link there as well.
While we're at it, let's switch the link to an anonymous link, because
we're not referring to it anywhere, so it doesn't need to be named.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10917>
Due to the recent changes at Freenode and the recommendation from the
X.Org board of moving to OFTC[1], many mesa-developers have moved over
to the #dri-devel channel on OFTC by now.
So let's promote that channel rather than the Freenode channel.
While we're at it, let's correct[2] the URI to use a slash to separate
between the host and channel. And omit the # from the channel name for
maximum compatibility.
[1]: https://lists.freedesktop.org/archives/mesa-dev/2021-May/225271.html
[2]: https://en.wikipedia.org/wiki/Internet_Relay_Chat#URI_scheme
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10917>
It seems this gives 2-3% improvements most of the time. This also
enables DCC for concurrent images.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10454>
We support this extension on Zink even if we don't support ES 3.2,
because the compatibility extension doesn't require advanced blending.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10861>
Since 70813c1c13 ("meson: Remove kmsro from gallium-drivers"), it is no
longer necessary to include kmsro in the gallium-drivers list; kmsro
will be automatically enabled if it may be required. Simplify the docs
for lima and panfrost accordingly to reflect the change.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10727>
