OpenGL 3.0 requires ARB_texture_float, which technically speaking
requires linear-filtering support for FP32 textures. However, because a
lot of early implementations just ignore this and does nearest filtering
instead due to lack of hardware features for this, this functionality
was never added to the OpenGL CTS.
The result is that FP32 is a feature that is required on paper, but
is unreliable to be used by applications in practice. This is mostly
fine; for most filterable use-cases (e.g colors), FP16 is fine and saves
a bunch of bandwidth, and for cases where you really need the extra bits
(depth-reads etc), filtering is usually not what's wanted.
To save drivers that doesn't support filtering of FP32 filtering from
having to manually whack the state, and get needless CSOs in the CSO
caches, let's force this in early, where we already do the same for
integer textures.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18292>
There's no need to re-check the DRI-config setting here; we either
already got nearest filtering already, or the we applied a work-around
to avoid incomplete textures. In either case, these should be nearest,
no need to check for it again.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18292>
From the Vulkan spec says:
"VUID-VkGraphicsPipelineCreateInfo-pStages-00738
If the pipeline is being created with pre-rasterization shader
state and pStages includes a geometry shader stage, and does not
include any tessellation shader stages, its shader code must
contain an OpExecutionMode instruction specifying an input
primitive type that is compatible with the primitive topology
specified in pInputAssembly"
In other words, the GS input primitive and the topology must match, so
it's possible to get this information directly from the GS instead of
from the pipeline key. Main benefit is that the driver can compile all
pre-rasterization stages without knowing the primitive topology.
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/18282>
Take this real-world (trimmed) shader:
precision highp float;
in lowp vec4 var_varVertexColor;
layout(location = 0) out vec4 out_FragColor0;
void main() {
vec4 textureColor0 = vec4(1.000000e+00, 0.000000e+00, 0.000000e+00, 1.000000e+00);
vec3 color = vec3(1.000000e+00, 1.000000e+00, 1.000000e+00);
vec4 outColor = vec4(vec3((color).rgb), 1.000000e+00);
(outColor *= vec4(var_varVertexColor));
(out_FragColor0 = outColor);
}
After opts, it's just a store from input to output. If we decide to lower
the input to 16-bit, then as long as the driver can handle 16-bit outputs,
it would be a good idea to demote the output and save the conversions.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18003>
Instead of not reporting support for the pixel format at all, just
disable swapchain creation.
Some apps want to create off-screen contexts targeting these formats,
but since WGL doesn't really have "off-screen," the pixel format
enumeration should return support for these.
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18326>
Instead of this fragile use_primitive_replication bit which we set
differently depending on whether or not we pulled the shader out of the
cache, compute and use the information up-front during the compile and
then always fetch it from the vue_map after that. This way, regardless
of whether the shader comes from the cache or not, we have the same flow
and there are no inconsistencies.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17602>
Now that we're using nir_intrinsic_load_layer_id for ViewIndex, we can
use primitive replication even when the FS uses ViewIndex. Also, only
check that active_stages doesn't contain anything other than VS and FS,
not that it's exactly VS | FS. This both decouples things more and
allows primitive rplication in the depth-only case where we have no
fragment shader at all.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17602>
Failing to create staging resources isn't necessarily a critical error,
and we probably don't want to be printing out XXX messages. I mostly
had this here when bringing up iris and resource creation was failing
because I'd done something wrong when writing the code. Then it got
copied over to crocus.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18311>
Failing to create staging resources isn't necessarily a critical error,
and we probably don't want to be printing out XXX messages. I mostly
had this here when bringing up the driver and resource creation was
failing because I'd done something wrong when writing the code.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Mark Janes markjanes@swizzler.org
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18311>
ac_nir_translate can fail now so forward the translation result to
si_llvm_compile_shader. If it's a failure, it'll print something like:
radeonsi: can't compile a main shader part
And the shader won't be used.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18147>
I am not entirely convinced that contexts can't mess up the state of other
contexts, but with this we at least turn down the amount of races on the
CPU side.
If we hit bugs later we can always look into it then and figure out what
to fix how.
I think we might need a better solution for it in the future as state
tracking might need to become more involved, but for now this should be
good enough.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10752>
nouveau_fence_work already checks the state, so we can just call it
directly.
Strictly speaking, this isn't functional equivalent, but practically it
doesn't matter when we get the callback called.
Main reason for doing this is, that this makes locking way easier as we
can simply lock within nouveau_fence_* functions and callers don't have to
take locks themselves.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10752>
Erik Faye-Lund