According to the docs for PIPE_CAP_MAX_TEXTURE_2D_SIZE, it's the limit
both for 2D *and* 1D textures. So let's take the min of the two vulkan
features here instead of assuming they're the same.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19780>
These features are no longer required.
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19750>
The mesa state-tracker can now emulate all formats indicated by this
feature-flag, so we don't require this for OpenGL 4.2 any more.
It's however a good idea to support for power-usage and performance
reasons, saving on memory bandwidth. So let's move it to the
gl46_optimal block instead.
Fixes: e4ff42684b ("mesa/st: enable bptc extension with fallback")
Fixes: 2ea481b2f0 ("Zink: add Zink profiles file")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19779>
It makes little sense to document the gallium envvars in multiple
places. Let's merge them all into the root envvar document.
This also moves GALLIUM_OVERRIDE_CPU_CAPS to toe root envvars doc, as
it's more generic than just LLVMpipe.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19593>
When declaring an envvar, we should use the envvar directive, not the
envvar role. The latter is meant to reference the declaration, not the
other way around.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19593>
The custom envvar directive is strange. It overloads the global
namespace, where there's already a well-known envvar directive, but the
envvar role won't resolve to envvars defined using the custom directive.
It's not really critical to declare the type and default value here, and
many descriptions already include this. Let's just use the plain one,
and let the description take care of the details where needed.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19593>
We only support lazy descriptors these days, so having the
infrastructure around to support automatic selection of that one mode is
kinda silly.
And it's not like setting an environment variable that is never read is
going to cause any issues, so we don't even need this to avoid breaking
existing setups.
Let's just rip it out. We can reintroduce it again on the off-chance
that someone has a new clever descriptor mode they want to experiment
with.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19670>
The use of a hash symbol in a URI is an anchor, not to indicate an IRC
channel name. This confuses the Sphinx linkchecker.
Dropping the hash here still makes the link work fine, so let's just do
that.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
Here's a few redirects that we should apply, in case the redirects
gets removed in the future.
These are mostly of the 301 (moved permanently) kind, but also a
few where the site probably *should* have used the permanent
error-code.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
While it would be possible to dig this one up through web.archive.org,
there's a much better article written by Fabian Giesen on the subject,
so let's just link that one instead.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
There's no point in linking to a copy of this article on a defunct site.
So let's just remove it, the original source works just fine.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
We're in 2022 now, and HTTPS is available in a lot more places in the
past. Let's upgrade some links, to protect the privacy of our readers.
The links that are left either don't support HTTPS, or are simply dead
and needs to be updated anyway. That's besides the scope of this
merge-request, so I'm leaving that for someone else.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19492>
Anonymous links has some benefits in that it reduces the chance of
warnings when similar identifiers are used. So let's use them instead
when we can.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19492>
This new section didn't use the correct RST syntax, and ended up
with a broken section in the rendered docs.
Fix the syntax, and clean things up a bit to avoid overly long lines.
Fixes: be235edfe2 ("zink: add profile documentation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19481>
A single backtick escaped string in Sphinx refers to the "default role"
which is vague, and in practice ends up producing the HTML cite-element.
That's almost certainly not what these uses wanted.
A bunch of these would probably be better served using appropriate roles
instead of inline-code markup, but this is almost certainly what was
meant here instead. Let's not let perfect be the enemy of good here, and
just do what was intended. Using the right roles everywhere is a big
task.
I usually don't do changes like these to the relnotes, but in this case
there were a *single* article that had these mistakes. I assume that was
an early bug in the script that generateg the relnotes. Let's patch it,
so we don't get misrendering if we change the default-role.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19494>
